🛡️ Pare-feu réseau personnalisable de Trooper.AI

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 de pare-feu Trooper.AI propose un pare-feu natif positionné directement devant votre serveur GPU. Cela vous permet de contrôler le trafic réseau avant que les paquets n’atteignent le système d’exploitation du serveur GPU. Vous pouvez également limiter le trafic sortant si nécessaire pour des raisons de sécurité ou de performances.

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.

Pare-feu sortant

Le pare-feu réseau de niveau Trooper.AI applique un contrôle granulaire sur le trafic sortant du réseau provenant de votre serveur GPU Blib. Cette fonctionnalité permet aux organisations d'appliquer des mesures strictes de conformité réglementaire, d'optimiser l'utilisation de la bande passante et d'améliorer la sécurité opérationnelle.

Remarque : Les règles sortantes peuvent bloquer ou limiter les téléchargements de paquets et de modèles (apt, pip, Hugging Face). En cas de problèmes de connexion, vérifiez d'abord vos règles pare-feu.

L’interface fonctionne comme suit :

• (1) Table des règles – Affiche toutes les règles de pare-feu sortantes configurées. Les règles peuvent être triées, modifiées ou supprimées.
• (2) Itinéraires par défaut – Le trafic sortant est toujours autorisé par défaut.
• (3) Éditeur de règles – Ajouter des nouvelles règles basées sur les plages de ports, plages d’IP et l’action (Autoriser / Refuser). Pour une règle d’autorisation, vous pouvez définir une limite de débit jusqu’à un maximum de 50 Mbit/s.

L'implémentation du pare-feu maintient une séparation totale entre l'application des règles de politique et les environnements d'exécution du serveur :

• Tout filtrage s'effectue au niveau de la couche d'infrastructure réseau avant l'émission des paquets
• Les processus applicatifs n'ont ni visibilité ni capacité de modification des configurations du pare-feu
• Protection contre une compromission potentielle des composants côté serveur tentant de contourner les restrictions

Paramètres de pare-feu recommandés

Pour simplifier la sécurité sortante, Trooper.AI propose deux préréglages prêts à l'emploi que nous recommandons pour un usage général. Vous pouvez en appliquer un automatiquement lors de la commande d’un nouveau serveur GPU Blib — il suffit de le sélectionner dans le dialogue de commande et il est configuré dès le démarrage du serveur, sans nécessiter de création manuelle de règles. Préférez-vous décider plus tard ? Commandez avec « Aucun préréglage » et vous pourrez ensuite recréer n’importe lequel des préréglages par vous-même à tout moment depuis le tableau de bord.

Les deux préconfigurations ne modifient que le trafic sortant (votre serveur → Internet). Votre plage de ports publics entrants et votre accès SSH restent ouverts par défaut, et les règles sont évaluées de haut en bas – la première règle correspondante s’applique.

• 🟢 Équilibré — notre recommandation par défaut pour presque tout le monde : reste entièrement ouvert pour un travail d’IA classique tout en bloquant discrètement les spams, vers et abus de botnets connus.
• 🔴 Strict — une liste blanche sécurisée pour les boîtiers d’inférence qui n’ont besoin que des essentiels.

Appliquer lors de la commande ou le reconstruire plus tard vous-même : choisissez un modèle prédéfini dans l’interface de commande pour qu’il soit appliqué automatiquement, ou recréez-le à tout moment sous Gérer → votre serveur → 🛡️ Pare-feu → Sortant en utilisant les tableaux ci-dessous.

Protection toujours active (tous les préréglages, y compris « Aucun préréglage ») : atténuation multicouche des attaques par déni de service distribué (DDoS), limites de connexions/débits par IP, isolement des locataires et protection de sortie pour réseaux privés (RFC1918) sont appliqués automatiquement et ne peuvent pas être désactivés.

🟢 Équilibré (recommandé)

Tout reste ouvert pour un travail normal avec l'IA — apt, pip/uv, Hugging Face, Docker, les bases de données et vos propres API — tandis qu'un ensemble de blocages conformes aux meilleures pratiques industrielles empêche le spam, les vers et les abus liés aux botnets. L'UDP sortant est désactivé par défaut, sauf pour le DNS et la synchronisation horaire.

Effet net : tout le trafic sortant en TCP reste ouvert sauf pour les ports d'abus listés ; le trafic sortant en UDP est limité au DNS (53) et au NTP (123). Le QUIC/HTTP-3 bascule automatiquement vers le TCP 443, de sorte que les téléchargements ne sont pas affectés. L'ICMP (ping/découverte de MTU du chemin) reste autorisé.

🔴 Restrictif (Avancé)

Seuls les essentiels sortent — idéal pour des boîtiers dédiés à l'inférence/IA. Tout ce qui n'est pas dans la liste blanche est bloqué (refus par défaut).

Effet net : apt, pip/uv, git (HTTPS et SSH), les téléchargements depuis Hugging Face ainsi que les commandes pull de Docker fonctionnent tous ; tout ce qui utilise un port non standard est bloqué. L’ICMP reste autorisé(e). Idéal lorsque vos applications n’utilisent que des ports standards.

🔒 Verrouillage d’IP pour SSH (optionnel)

Si activé au moment de la commande, deux règles entrantes sont ajoutées afin que uniquement votre adresse IP puisse accéder à SSH, tandis que vos ports publics d'applications restent ouverts pour tous :

Si votre adresse IP change, mettez simplement à jour la source dans Gérer → Pare-feu → Entrant.

Comment vérifier ou reconstruire

• Vérification : ouvrez Gérer → votre serveur → 🛡️ Pare-feu → Sortant. Le badge de compte sur l’onglet indique le nombre de règles actives ; comparez-les avec le tableau ci-dessus.
• Reconstruire sur une machine existante : dans l’onglet Sortant, ajoutez une règle par ligne dans le même ordre (en haut = priorité la plus élevée), puis cliquez sur Appliquer maintenant.
• À faire plus tard : vous pouvez commencer avec Aucune configuration prédéfinie et ajouter ces règles quand bon vous semble – les modifications prennent effet après Appliquer maintenant

Les règles sont évaluées de haut en bas : la première correspondance est appliquée. Placez les deux règles Autoriser pour le DNS/NTP au-dessus de toute règle générale Refuser, sinon la résolution de noms et la synchronisation horaire seront perturbées.

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 à accéder à votre machine, vérifiez d’abord les paramètres du pare-feu puis contactez-nous : Support Contacts

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 : Comprendre le contrôle du trafic sortant ou Pourquoi une connexion sortante fonctionne-t-elle toujours ?

Le trafic sortant dans le pare-feu de Trooper.AI concerne exclusivement les connexions réseau activement initiées par votre serveur GPU Blib. Cette distinction précise que :

• « Sortant » = Connexions où votre serveur agit en tant que client (initiant la communication).
• « Trafic de retour » = Réponses aux connexions entrantes établies précédemment (où les systèmes externes agissent en tant que clients).
• Vous pouvez restreindre le trafic SSH sortant tout en maintenant l'accès SSH entrant pour les connexions distantes.
• Les restrictions de trafic sortant s'appliquent uniformément à tous les protocoles – y compris HTTP. Même si vous configurez DÉNEGATION pour tous les ports sortants, les services basés sur HTTP comme WebProxy, Jupyter et OpenWebUI continueront de fonctionner car leurs connexions proviennent de l'extérieur, ce qui signifie qu'ils dépendent du trafic entrant

Note importante : Une connexion entrante explicitement autorisée peut générer un trafic de retour légitime afin de maintenir la continuité de la session – cela reste inchangé par les règles sortantes sauf restriction explicite.

Toutes les politiques de sortie s'appliquent uniquement aux connexions initiées en interne par votre instance GPU Server.

Dépannage : Pourquoi les tâches système comme APT/PIP ne fonctionnent plus ?

🚨 Vérifiez que vos règles de pare-feu sortantes autorisent l’accès réseau nécessaire aux gestionnaires de paquets (pip, apt-get) et aux mises à jour système pour récupérer en toute sécurité les correctifs critiques et les mises à jour du système d’exploitation. Confirmez que les dépôts standards ainsi que les serveurs de mise à jour sont ajoutés à la liste blanche afin d’assurer une résolution fluide des dépendances et des opérations de maintenance.

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

Le pare-feu Trooper.AI contrôle tous les ports entrants et sortants, 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.