> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/fr/networking/firewall-connection-tracking-state.md). # État du suivi des connexions dans les règles de pare-feu Comment utiliser le champ État du suivi des connexions dans les règles de pare-feu VergeOS pour bloquer les nouvelles connexions entrantes sans interrompre le trafic de retour des connexions sortantes. ## Vue d'ensemble {% hint style="info" %} **Points clés** * Les règles de pare-feu VergeOS sont avec état ; le **État de suivi de connexion** champ fait correspondre les paquets selon l'état conntrack. * Définissez la portée d'une **règle de rejet** sur l'état `nouveau` pour bloquer les connexions entrantes non sollicitées sans rejeter le trafic de retour. * N'ajoutez pas votre propre règle d'acceptation pour le trafic de retour — la chaîne générée accepte déjà `établi`/`connexe` le trafic. {% endhint %} Les règles de pare-feu VergeOS sont avec état. Le **État de suivi de connexion** champ d'une règle réseau ne correspond qu'aux états conntrack sélectionnés. Son utilisation la plus courante est de faire en sorte qu'une **règle de rejet** règle bloque *nouveau* les connexions entrantes sans rejeter également le *trafic de retour* des connexions que l'hôte protégé initie lui-même. ## Prérequis * Familiarité avec [les règles réseau VergeOS](/run-the-platform/fr/reseau/network-rules.md). * Un utilisateur autorisé à modifier les règles réseau. ## Le champ d'état de suivi de connexion Le champ est disponible dans le formulaire d'édition de la règle réseau. Laissez-le vide pour correspondre à n'importe quel état. **Valeurs autorisées :** `nouveau`, `établi`, `connexe`, `non suivi`. | État | Signification | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `nouveau` | Le premier paquet d'une connexion — une tentative de connexion non sollicitée. | | `établi` | Les paquets qui appartiennent à une connexion déjà vue dans les deux sens. | | `connexe` | Une nouvelle connexion que conntrack relie à une connexion existante (par exemple, les canaux de données FTP et les erreurs ICMP). | | `non suivi` | Les paquets explicitement exclus du suivi de connexion. | Le champ accepte plusieurs états séparés par des virgules (`établi,connexe`) et la négation avec un préfixe `!=` (`!= nouveau`). {% hint style="info" %} Il n'existe pas de `invalide` option. VergeOS rejette déjà les paquets invalides avec une règle de base du système (`ct state invalid drop`) près du début de chaque chaîne générée, donc vous n'en ajoutez pas vous-même. {% endhint %} ## Le problème : une règle de rejet qui casse le trafic sortant Une seule adresse IP publique est souvent utilisée à la fois pour les services entrants et comme adresse SNAT sortante pour un locataire ou une VM derrière elle. Une règle globale **règle de rejet** sur cette adresse IP de destination bloque le trafic entrant non sollicité comme prévu — mais elle rejette aussi les réponses au trafic sortant du locataire, car ces réponses arrivent sur la même adresse IP publique dans l'état `établi`. Le symptôme : le locataire ne peut pas accéder à Internet, et la suppression de la règle de refus corrige le problème. Supprimer la règle de rejet laisse passer les réponses établies, mais rouvre aussi l'accès entrant non sollicité — exactement ce que la règle avait pour but de bloquer. Ne supprimez pas la règle ; définissez sa portée. ## La solution : limitez la règle de rejet aux nouvelles connexions 1. Depuis le tableau de bord du réseau, cliquez sur **Règles** dans le menu de gauche. 2. Sélectionnez la **règle de rejet** règle puis cliquez sur **Modifier** dans le menu de gauche. 3. Dans le **État de suivi de connexion** champ, saisissez `nouveau`. 4. Cliquez sur **Soumettre**. 5. Cliquez sur **Appliquer les règles** dans le menu de gauche pour appliquer la modification. Le rejet ne correspond désormais qu'aux nouvelles connexions entrantes non sollicitées. Le trafic de retour des connexions sortantes est dans l'état `établi`, ne correspond plus au rejet et passe à la chaîne finale `ct state established,related accept`. ## Pourquoi aucune règle d'acceptation du trafic de retour n'est nécessaire VergeOS génère pour chaque réseau ses `entrée` et `de transfert` chaînes avec une `politique de rejet` et une ligne finale `ct state established,related accept` comme dernière ligne. nftables évalue les règles de haut en bas, et `politique de rejet` et `accept` sont terminaux : un rejet non limité placé au-dessus de cet accept final intercepte le trafic de retour avant qu'il n'atteigne l'accept. Limiter la portée du rejet à `nouveau` permet au trafic établi et connexe de passer jusqu'à l'accept final — vous n'ajoutez pas votre propre règle d'acceptation. > **Modèle mental :** Bloquer `nouveau` pour bloquer les entrées non sollicitées. Laissez `établi` et `connexe` le trafic circuler afin que tout ce que l'hôte protégé a initié puisse se terminer. ## Bon à savoir * L'ordre des règles compte. L' `established,related accept` est la dernière ligne de la chaîne générée ; un rejet global placé au-dessus, sans état défini, engloutit le trafic de retour. * Le même principe de limitation s'applique à toute règle, pas seulement aux rejets. Par exemple, limitez une règle entrante **Accept** à `nouveau` pour contrôler quel côté peut initier les connexions. * L' `connexe` état compte pour les protocoles avec des flux secondaires suivis par un helper (FTP, certains VoIP, erreurs ICMP) ; l'accept système final les couvre. ## Ressources supplémentaires * [Règles réseau](/run-the-platform/fr/reseau/network-rules.md) {% hint style="info" %} **Besoin d'aide ?** Si vous avez des questions ou des problèmes avec cette procédure, contactez l'équipe d'assistance VergeOS. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/knowledge-base/fr/networking/firewall-connection-tracking-state.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.