For the complete documentation index, see llms.txt. This page is also available as Markdown.

État du suivi des connexions dans les règles de pare-feu

Comment utiliser le champ État du suivi des connexions sur 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

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.

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.

  • 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).

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.

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

Besoin d'aide ?

Si vous avez des questions ou des problèmes avec cette procédure, contactez l'équipe d'assistance VergeOS.

Mis à jour

Ce contenu vous a-t-il été utile ?