Quand le module conntrack d'iptable suit-il l'état des paquets ?

Solution 1 :

Présentation d'introduction de Netfilter et conntrack

Tout d'abord, le schéma obligatoire sur le flux de paquets dans Netfilter et le réseau général :

Netfilter est le cadre de filtrage de paquets qui s'insère sur le reste de la pile réseau (représenté par la "décision de routage" et d'autres parties blanches de la boîte aux bords arrondis). Netfilter fournit des crochets et des API pour d'autres sous-systèmes et "clients". Parmi ces parties se trouvent conntrack (le traqueur de connexion) et iptables (ou nftables ). La séparation entre Netfilter et conntrack est assez flou. Vous pouvez simplement envisager conntrack en tant que partie intégrante de Netfilter.

Dans le schéma décrivant les différentes étapes traversées par un paquet, vous pouvez voir qu'à un moment donné (entre raw/PREROUTING et mangle/PREROUTING, ou entre raw/OUTPUT et mangle/OUTPUT) le paquet traverse conntrack .

À ce stade, conntrack recherchera dans ses propres tables de recherche (une mini base de données de recherche conservée dans la mémoire du noyau) :

si les caractéristiques de ce paquet ne sont pas trouvées (et s'il n'est pas déclaré UNTRACKED dans la table brute), un nouveau tuple bidirectionnel conntrack entrée (protocole, puis informations spécifiques sur la famille et le protocole :source et port initiaux, destination et port initiaux, source et port de réponse, destination et port de réponse (ces deux derniers sont généralement l'inverse, sauf si NAT ou certains protocoles étranges sont impliqués, comme echo réponse correspondant à la demande d'écho pour ICMP)) décrivant le flux est créé avec l'état NEW.
s'il correspond (dans n'importe quelle direction) à une entrée précédente et est compatible avec l'état de ce flux, l'état du flux peut être modifié (par exemple :passer de NOUVEAU à ÉTABLI si ce n'était pas le cas auparavant).
si, pour une raison spécifique, le paquet ne peut pas correspondre à un flux existant malgré ses caractéristiques (par exemple :un paquet TCP en retard reçu après qu'une retransmission a déjà été lancée avec succès, donc hors fenêtre en ce qui concerne la séquence et SACK valeurs) le paquet sera étiqueté INVALID.
il existe quelques autres cas comme RELATED :il s'agit de paquets ne faisant pas partie du flux lui-même mais liés à un nouveau flux qui peut être associé à un autre flux existant (c'est-à-dire dans la base de données). Deux exemples sont une erreur ICMP créée à partir de la réception d'un paquet (par exemple :port UDP inaccessible) ou lorsqu'un assistant de protocole spécial comme le module de noyau nf_conntrack_ftp , qui est un plugin pour le conntrack sous-système, détecte qu'un paquet fait partie du flux de données séparé associé aux commandes FTP PASV/EPSV ou PORT/EPRT effectuées sur le flux de commande (sur le port 21).

Répondre à la question

Tout cela étant dit, voici les réponses à vos deux points :

dans l'espace de noms de réseau principal conntrack commence à suivre les connexions dès que ses modules (y compris les éventuels sous-modules spécifiques au protocole pertinents) sont chargés. Pour les espaces de noms de réseau non initiaux (conteneurs...), cela nécessite également qu'un autre sous-système le référence (comme les iptables d'OP le module conntrack ou en utilisant une fois la commande conntrack décrit plus loin). Il s'agit de la valeur par défaut et un paquet doit être spécifiquement marqué comme UNTRACKED avant le conntrack le sous-système le voit pour que ce paquet ne soit pas suivi. Sous Linux, il n'y a que quelques cas où le suivi ne serait pas nécessaire, mais bien sûr, le pare-feu avec état et le NAT avec état/dynamique ne seront plus disponibles (le NAT steless qui pourrait même nécessiter l'utilisation de UNTRACKED en premier lieu, peut toujours être fait, mais pas avec iptables . tc ou nftables boîte). Pour éviter conntrack gérer certains paquets, ce genre de iptables règle peut être utilisée (ex :port 80/tcp) :
```
iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
```
Lorsque le paquet traverse filter/INPUT et atteint cette règle :
```
 iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
```
Les iptables module spécifique du noyau xt_conntrack interroge le conntrack sous-système (géré par les différents modules pertinents du noyau nf_conntrack* ) et demande l'état de ce paquet dans sa base de données de recherche. Si la réponse est RELATED ou ESTABLISHED le paquet correspond et passe au verdict ACCEPT. En fait, le résultat est déjà mis en cache dans le paquet la première fois que la recherche a été effectuée (généralement par conntrack ) il s'agit donc d'une "recherche" bon marché. Il s'agit donc d'une règle générique pour gérer les flux déjà acceptés auparavant. Ces flux peuvent être initialement acceptés dans des règles mentionnant explicitement -m conntrack --ctstate NEW ou simplement des règles ne le mentionnant pas mais placées après cette règle générique (mais gardez à l'esprit l'état INVALID, qui doit généralement être abandonné avant de le faire).
ajout d'une puce :la gestion des paquets entrants et des paquets sortants est assez symétrique entre PREROUTING et OUTPUT (même si ceux-ci ne semblent pas symétriques) :conntrack interfaces dans PREROUTING ainsi que dans OUTPUT (et dans quelques autres endroits, en considérant NAT fonctionne avec conntrack , sauf pour son premier paquet dans l'état NEW traversant iptables 's nat table). Cela peut être légèrement différent de la description que vous avez écrite à propos d'IPFW. Si un serveur exécutant des applications restreint également les flux sortants, il a probablement besoin de ces mêmes iptables génériques règle à la fois dans filter/OUTPUT et dans filter/INPUT, pour autoriser le passage des paquets de réponse sortants du trafic entrant déjà accepté.

Informations complémentaires

Il existe des outils dédiés pour interagir avec le conntrack les tables de recherche du sous-système à partir de conntrack-tools.

conntrack :pour interroger, supprimer ou mettre à jour le contenu des tables de recherche gérées par conntrack .

Quelques exemples.

Vous pouvez répertorier toutes les entrées suivies (qui peuvent être volumineuses sans filtre supplémentaire) avec :
```
conntrack -L
```
Si votre système utilise le NAT (par exemple, un routeur devant un réseau local privé ou l'exécution de VM et de conteneurs), vous pouvez utiliser --any-nat , --src-nat ou --dst-nat pour afficher uniquement resp. tous les NAT, tous les NAT sources (mascarades) ou tous les NAT de destination (généralement pour les ports transférés) :

Surveillance en temps réel de conntrack événements :
```
conntrack -E
```
conntrackd :un démon dont les deux objectifs principaux sont la comptabilité et les statistiques de flux (conntrack), ou la synchronisation de l'état du cluster de pare-feu avec état à haute disponibilité.

Solution 2 :

Le suivi des connexions est une fonction distincte de Netfilter et n'est pas configuré avec IPTables.

Sur la photo, il y a deux conntrack étapes dans le chemin INPUT et une dans le chemin OUTPUT. Ces étapes associent des paquets individuels aux connexions existantes suivies dans le tableau de suivi des connexions ou créent de nouvelles entrées de suivi des connexions dans le tableau.

La fonctionnalité Conntrack est un module du noyau Linux, et elle est souvent incluse dans le noyau dans la configuration par défaut.

Le fonctionnement de Conntrack peut être réglé en ajustant net.netfilter.nf_conntrack valeurs sysctl.

Votre deuxième alternative est ce qui se passe. Les informations d'état sont enregistrées par la fonction Conntrack et la règle IPTables consulte simplement la table Conntrack pour obtenir des informations.