🛡️ Pare-feu natif avant votre serveur GPU

Flux de trafic

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

Le trafic UDP est bloqué par défaut, mais cela 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 du pare-feu Trooper.AI fournit un pare-feu natif positionné directement devant votre serveur GPUCeci vous 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 est accessible via Actions > “Règles du pare-feu”.

L’interface fonctionne comme suit :

• (1) Tableau 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) Routes par défaut – Définit le comportement par défaut pour le trafic qui ne correspond à aucune règle.
• (3) Éditeur de Règles – Ajouter de nouvelles règles basées sur plages de ports, plages d'IP et action (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 pouvez pas accéder à vos services sur votre serveur GPU après avoir effectué une opération sur le Pare-feu ou la Pile Réseau. Si vous ne pouvez toujours pas accéder à votre machine, veuillez d'abord vérifier vos paramètres de pare-feu, puis contactez-nous : Contacts Support

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

Si un pare-feu local tel que UFW a été activé sur le serveur et cause 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.

Le la première règle qui correspond 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 des 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 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 le tableau de bord de gestion de votre Blib. Si le mauvais port est autorisé dans le pare-feu, le trafic n'atteindra 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

est bloqué dans le pare-feu, l' 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 L'adresse IP doit se trouver dans la plage CIDR autorisée.
3. Le La règle d'autorisation avec le port SSH public (tel que 14511 - et non 22, qui est le port interne) doit apparaître au-dessus de toute règle de refus.

Vérifiez également 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 à aucune règle suivra les Routes par défaut définis dans les paramètres du pare-feu.

Si une règle ne correspond pas exactement (plage IP incorrecte, port incorrect ou ordre incorrect), le trafic peut passer à travers 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 supérieure qui ne correspond pas correctement.