🛡️ Pare-feu natif avant votre serveur GPU

Flux de trafic

Votre serveur GPU fonctionne derrière notre infrastructure NAT et couche de sécurité réseau, ce qui signifie que tout le trafic passe par le pare-feu réseau Trooper.AI avant d'atteindre le serveur.

Le trafic UDP est bloqué par défaut, mais il peut être activé via les paramètres du pare-feu si nécessaire.

Cette architecture vous permet de gérer la sécurité réseau de manière centralisée tout en vous concentrant entièrement sur la construction et l'exécution de vos charges de travail d'IA.

Comment utiliser le pare-feu de niveau réseau intégré

L’interface pare-feu de Trooper.AI propose un pare-feu natif positionné directement devant votre serveur GPU. Cela permet de contrôler le trafic réseau avant que les paquets n'atteignent le système d'exploitation du serveur GPU.

Cette couche de sécurité est entièrement intégrée à l’infrastructure Trooper.AI et peut être consultée via Actions > « Règles du pare-feu ».

L’interface fonctionne comme suit :

• (1) Table des règles – Affiche toutes les règles de pare-feu configurées. Les règles peuvent être triées, modifiées ou supprimées.
• (2) Itinéraires par défaut – Définit le comportement par défaut pour le trafic ne correspondant à aucune règle.
• (3) Éditeur de règles – Ajouter des nouvelles règles basées sur les plages de ports, plages d’IP et actions (Autoriser / Refuser)

Cette conception vous permet de contrôler l'exposition réseau de votre serveur GPU sans modifier la configuration du système d'exploitation.

Dépannage

Vérifiez ces étapes si vous ne parvenez pas à accéder aux services de votre serveur GPU après avoir modifié le pare-feu ou la pile réseau. Si vous n’arrivez toujours pas à y accéder, vérifiez d’abord les paramètres de votre pare-feu puis contactez-nous : Lien vers les contacts support

IMPORTANT : Désactivation de tout pare-feu local (si activé par erreur)

Si un pare-feu local tel que UFW était activé sur le serveur et provoque des problèmes de connectivité, il peut être désactivé avec :

sudo ufw disable

Sortie :

Firewall stopped and disabled on system startup

Puis désactivez le service :

sudo systemctl disable ufw

Sortie :

Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
Removed /etc/systemd/system/multi-user.target.wants/ufw.service.

Vous devriez complètement supprimer tout pare-feu local sur votre serveur GPU. Cela vous facilitera la vie !

Dépannage : pourquoi mes règles de pare-feu ne fonctionnent-elles pas comme prévu ?

Les règles du pare-feu sont évaluées de haut en bas.

La première règle correspondant au trafic est appliquée, et aucune autre règle n'est vérifiée.

Exemple d'ordre incorrect :

1  Deny  0.0.0.0/0      Port 14141
2  Allow 78.168.0.0/16  Port 14141

Dans ce cas, la règle 1 bloque tout le trafic SSH avant que la règle 2 ne soit atteinte.

Ordre correct :

1  Allow 78.168.0.0/16  Port 14141
2  Deny  0.0.0.0/0      Port 14141

Placez toujours les règles d'autorisation plus spécifiques au-dessus des règles de refus générales.

Dépannage : Pourquoi ma règle de pare-feu ne correspond-elle pas à mon adresse IP ?

Les règles de pare-feu utilisent des plages CIDR pour définir les adresses IP autorisées ou bloquées.

Assurez-vous que la plage inclut bien votre adresse IP.

Exemples :

Si la plage CIDR est incorrecte, la règle de pare-feu ne correspondra jamais à votre connexion.

Dépannage : Pourquoi mon port est-il toujours bloqué ?

Vérifiez que le port correct est autorisé dans le pare-feu. Vous pouvez trouver les ports corrects dans l’onglet Gestion de votre Blib. Si un mauvais port est autorisé dans le pare-feu, le trafic ne parviendra jamais à votre serveur GPU.

Dépannage : Pourquoi mon interface web est-elle bloquée ?

Le pare-feu Trooper.AI contrôle tous les ports entrants, y compris ceux utilisés par les interfaces web.

Si le port utilisé par des services tels que :

• OpenWebUI
• Jupyter Notebook
• tableaux de bord internes
• outils d’IA personnalisés

l’interface web sera également inaccessible

Une configuration sécurisée courante consiste à restreindre l'accès à votre plage d'adresses IP de l'entreprise.

Exemple :

Allow 203.0.113.0/24  Port 14511
Deny  0.0.0.0/0       Port 14511

Cela permet uniquement aux utilisateurs de votre organisation d'accéder à l'interface web sécurisée.

Dépannage : Pourquoi SSH n'est-il pas accessible ?

Si l'accès SSH échoue, vérifiez ce qui suit :

1. N'installez pas un UFW (pare-feu) local qui bloquerait votre port SSH interne 22
2. Votre adresse IP doit être dans la plage CIDR autorisée
3. La règle d'autorisation pour le port SSH public (par exemple 14511 – et non 22, qui est le port interne) doit apparaître avant toute règle de refus.

Vérifiez également le paramètre Autoriser SSH en bas du tableau de configuration du pare-feu.

Si SSH est désactivé en bas des paramètres du pare-feu, le serveur n'acceptera que les connexions SSH provenant des adresses IP autorisées par les règles ci-dessus.

Dépannage : pourquoi le trafic est-il encore bloqué même après avoir ajouté une règle ?

Le trafic qui ne correspond à aucun règle suivra les Routes par défaut définies dans la configuration du pare-feu.

Si une règle ne correspond pas exactement (plage d’IP incorrecte, port erroné ou ordre faux), le trafic peut être redirigé vers la règle de refus par défaut.

Vérifiez toujours :

• ordre des règles - la première correspondance gagne (de haut en bas)
• Plage CIDR - voir les exemples
• numéro de port - visible sur le tableau de bord de gestion
• comportement de la route par défaut

Vérification finale : Essayez de cliquer sur AUTORISER TOUT et vérifiez si cela fonctionne. Si oui, c’est une règle plus haut qui ne correspond pas correctement.