Ce chapitre aborde et explique en détail la machine d'état. Après avoir lu ceci, vous devriez avoir pleinement compris son fonctionnement. Vous parcourerez un nombre important d'exemples sur la façon dont les états sont traités par la machine d'état elle-même. Ces cas concrets devraient vous éclairer parfaitement.
La machine d'état correspond à une partie spéciale à l'intérieur d'iptables. En fait, elle porte très mal son nom puisqu'il s'agit en réalité d'une machine de traçage de connexion. Cependant, la plupart des gens la connaissent sous la première appellation. Au cours de ce chapitre, les deux noms sont utilisés indistinctement comme ils sont synonymes. Ceci ne devrait pas trop vous perturber. Le traçage de connexion est effectué afin que l'architecture de Netfilter puisse connaître l'état d'une connexion spécifique. Les pare-feux qui implémentent ceci sont habituellement appelés pare-feux à état. Un pare-feu à état est généralement bien plus sûr qu'un pare-feu sans état, puisqu'il impose une plus grande rigueur sur l'écriture des livres de règles.
Dans iptables, les paquets peuvent être reliés aux connexions tracées dans quatre états différents, qui sont connus sous les noms de NEW, ESTABLISHED, RELATED et INVALID. Chacun de ces états sera approfondi plus loin. Avec la correspondance --state, il est facile de contrôler qui, ou ce qui, est autorisé à démarrer de nouvelles sessions.
L'intégralité du traçage de connexion est effectué par une
structure particulière à l'intérieur du noyau appelée conntrack. La
structure conntrack peut soit être chargée comme un module, soit
être interne au noyau. La plupart du temps, on a besoin de
fonctions supplémentaires de traçage de connexion autres que celles
proposées par défaut dans le moteur conntrack. De ce fait, des
parties spécifiques de conntrack prennent en charge les protocoles
TCP
, UDP
et ICMP
.
Ces modules capturent des informations spécifiques et uniques sur
les paquets, afin de pouvoir tracer chaque flux de données.
L'information récupérée par conntrack lui permet de connaître
l'état dans lequel se trouve chaque flux actuellement. Par exemple,
un flux UDP
est, en général,
identifié uniquement par son adresse IP
destination
, son adresse IP
source
, son port destination
et son port source
.
Dans les noyaux précédents, il était possible d'activer ou désactiver la défragmentation. Cependant, depuis qu'iptables et Netfilter ont été incorporés avec, en particulier, le traçage de connexion, cette option a disparu. La raison en est simple, le traçage de connexion ne peut pas fonctionner correctement sans défragmenter les paquets, par conséquent la défragmentation a été intégrée dans conntrack, et elle est réalisée automatiquement. Elle ne peut donc plus être désactivée, sauf en désactivant le traçage de connexion. En définitive, la défragmentation a toujours cours si le traçage de connexion est actif.
Le traçage de connexion est entièrement pris en charge dans la
chaîne PREROUTING
, sauf pour les
paquets générés en local, qui sont pris en charge dans la chaîne
OUTPUT
. Ceci signifie qu'iptable
effectue tous les calculs d'état dans la chaîne PREROUTING
. Si on envoie le premier paquet d'un
flux, l'état est défini comme NEW dans la chaîne OUTPUT
, et quand on reçoit un paquet de
réponse, l'état passe à ESTABLISHED, et ainsi de suite.
Si le premier paquet n'est pas envoyé par nous-mêmes, l'état
NEW est naturellemt
défini dans la chaîne PREROUTING
.
Ainsi, tous les changements d'état et calculs sont réalisés dans
les chaînes PREROUTING
et
OUTPUT
de la table nat.