É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
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.
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).
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
Depuis le tableau de bord du réseau, cliquez sur Règles dans le menu de gauche.
Sélectionnez la règle de rejet règle puis cliquez sur Modifier dans le menu de gauche.
Dans le État de suivi de connexion champ, saisissez
nouveau.Cliquez sur Soumettre.
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
nouveaupour bloquer les entrées non sollicitées. Laissezétablietconnexele 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 acceptest 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 à
nouveaupour 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
Mis à jour
Ce contenu vous a-t-il été utile ?