Conntrack : quand les health checks passent et que le trafic s'arrête

La décision est prise une seule fois

Le suivi de connexion existe pour qu'un firewall évalue la politique une fois par flux au lieu d'une fois par paquet. Le premier paquet est confronté aux règles, le résultat de forwarding et de NAT est écrit dans la table d'états, et chaque paquet suivant de ce flux n'est plus qu'une recherche dans une table de hachage. Le conntrack de netfilter, la table d'états de pf dans OPNsense et la table de connexions de Cisco Firepower fonctionnent tous ainsi. L'entrée vit jusqu'à la fermeture du flux ou l'expiration de son délai d'inactivité, et pour une connexion TCP établie ce délai se mesure en jours.

La conséquence est facile à manquer : un changement de routage, de règle NAT ou d'interface affecte le flux suivant, pas les flux déjà dans la table.

Deux façons de perdre du trafic en silence

Le chemin périmé. Une route change, une interface bouge, un pool NAT est modifié. Les nouvelles connexions prennent le nouveau chemin. Un flux de longue durée conserve son interface de sortie ou sa liaison NAT d'origine, donc ses paquets partent par l'ancienne voie, vers un prochain saut qui ne les transmet plus ou sans la traduction que l'autre extrémité attend désormais. La pile TCP de l'émetteur retransmet patiemment sur une connexion qu'elle considère toujours établie, le récepteur ne voit rien, et aucun processus d'un côté comme de l'autre n'a échoué.

La table pleine. nf_conntrack_max est atteint, généralement à cause d'un scanner, d'un client derrière NAT avec des milliers de flux courts, ou de délais longs sur une machine chargée. Le noyau journalise une ligne et commence à rejeter le premier paquet des nouvelles connexions pendant que les flux existants continuent. Un health check qui réutilise une connexion ouverte continue de passer ; les utilisateurs qui en ouvrent de nouvelles obtiennent des timeouts.

Ni l'un ni l'autre n'apparaît dans la supervision des processus. Le démon est up, le listener est lié, la règle est présente.

Pourquoi les health checks passent

Un ping, une sonde TCP connect et le simulateur de chemin d'un firewall créent chacun un nouveau flux ou évaluent la politique à neuf, donc chacun reçoit la décision actuelle et correcte. La lecture verte est vraie, mais sur le mauvais objet. La question à poser au firewall n'est pas ce qu'il ferait d'un nouveau paquet, mais ce qu'il fait des flux qu'il détient déjà.

# the live flows from one source, with their state and NAT binding
conntrack -L -s <source>

# how full the table is
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

# the kernel's own report of a full table
journalctl -k | grep -i 'nf_conntrack: table full'

Un flux antérieur au dernier changement de routage et qui montre une sortie ou une traduction qu'aucune règle actuelle ne produirait est l'entrée à examiner.

Quoi surveiller

L'arrivée, pas la vivacité. Les lignes par minute qui atterrissent dans la base du collecteur, les messages par minute au récepteur syslog, une position de réplication qui avance. Une ligne plate est l'alarme, quoi que dise l'état du processus.

Les compteurs face à l'attendu. Le compteur d'octets de la règle qui porte un flux croît à peu près au rythme du flux. Une règle qui devrait être occupée et qui est presque plate signifie que les paquets correspondent à une autre règle ou n'arrivent pas du tout.

L'occupation de la table d'états. Alertez sur nf_conntrack_count en fraction de nf_conntrack_max bien avant qu'elle ne se remplisse, et sur le message « table full » du noyau, qui sinon reste dans le journal sans être lu.

Des vérifications synthétiques à la forme du vrai trafic. Une sonde qui tient une connexion de longue durée et y pousse un enregistrement à intervalles réguliers, vérifié à l'autre extrémité, teste la chose qui casse. Un ping frais teste celle qui ne casse pas.

Après chaque changement de routage ou de NAT, listez les flux plus anciens que le changement et décidez délibérément de les vider ou non.

Le correctif est un scalpel

Supprimez l'état de la source concernée. Le paquet suivant crée une entrée fraîche avec la décision actuelle et le flux reprend.

conntrack -D -s <source>

Un redémarrage ou une vidange complète fonctionne aussi, et emporte toutes les autres connexions actives avec lui. Pour une table pleine, le correctif consiste à augmenter nf_conntrack_max en même temps que la taille du hachage, à raccourcir le délai des connexions établies là où des jours ne sont pas nécessaires, et à trouver le client qui crée les flux.