Conntrack, wenn Health Checks bestehen und der Verkehr stoppt

Die Entscheidung fällt einmal

Connection Tracking existiert, damit eine Firewall die Policy einmal pro Flow auswertet statt einmal pro Paket. Das erste Paket wird gegen die Regeln geprüft, das Forwarding- und NAT-Ergebnis in die State-Tabelle geschrieben, und jedes spätere Paket dieses Flows ist ein Hash-Lookup. netfilter conntrack, die pf-State-Tabelle in OPNsense und die Connection Table in Cisco Firepower arbeiten alle so. Der Eintrag lebt, bis der Flow schließt oder sein Idle-Timeout abläuft, und für eine etablierte TCP-Verbindung wird dieses Timeout in Tagen gemessen.

Die Konsequenz übersieht man leicht: Eine Änderung am Routing, an einer NAT-Regel oder an einem Interface wirkt auf den nächsten Flow, nicht auf die Flows, die bereits in der Tabelle stehen.

Zwei Wege, auf denen das leise Verkehr verwirft

Der veraltete Pfad. Eine Route ändert sich, ein Interface wandert, ein NAT-Pool wird bearbeitet. Neue Verbindungen nehmen den neuen Pfad. Ein langlebiger Stream behält sein ursprüngliches Egress-Interface oder NAT-Binding, also verlassen seine Pakete das System auf dem alten Weg, in Richtung eines Next Hop, der sie nicht mehr weiterleitet, oder ohne die Übersetzung, die die Gegenseite jetzt erwartet. Der TCP-Stack des Absenders sendet geduldig erneut auf einer Verbindung, die er weiterhin für etabliert hält, der Empfänger sieht nichts, und auf keiner der beiden Seiten ist ein Prozess ausgefallen.

Die volle Tabelle. nf_conntrack_max wird erreicht, meist wegen eines Scanners, eines Clients hinter NAT mit Tausenden kurzer Flows oder langer Timeouts auf einer stark belasteten Maschine. Der Kernel protokolliert eine Zeile und beginnt, das erste Paket neuer Verbindungen zu verwerfen, während bestehende Flows weiterlaufen. Ein Health Check, der eine offene Verbindung wiederverwendet, besteht weiterhin. Nutzer, die neue öffnen, bekommen Timeouts.

Keines von beiden zeigt sich im Prozess-Monitoring. Der Daemon läuft, der Listener ist gebunden, die Regel ist vorhanden.

Warum die Health Checks bestehen

Ein Ping, ein TCP-Connect-Probe und der Pfadsimulator einer Firewall erzeugen jeweils einen neuen Flow oder werten die Policy frisch aus, also erhält jeder die aktuelle, korrekte Entscheidung. Die grüne Anzeige ist wahr, aber für das falsche Objekt. Die Frage an die Firewall lautet nicht, was sie mit einem neuen Paket täte, sondern was sie mit den Flows tut, die sie bereits hält.

# 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'

Ein Flow, der älter ist als die letzte Routing-Änderung und einen Egress oder eine Übersetzung zeigt, die keine aktuelle Regel erzeugen würde, ist der Eintrag, den Sie sich ansehen müssen.

Was zu überwachen ist

Ankunft, nicht Lebenszeichen. Zeilen pro Minute, die in der Datenbank des Collectors landen, Nachrichten pro Minute am Syslog-Empfänger, eine Replikationsposition, die voranschreitet. Eine flache Linie ist der Alarm, was auch immer der Prozessstatus sagt.

Zähler gegen Erwartung. Der Byte-Zähler auf der Regel, die einen Stream trägt, wächst ungefähr mit der Rate des Streams. Eine Regel, die beschäftigt sein sollte und nahezu flach ist, bedeutet, dass die Pakete auf eine andere Regel treffen oder gar nicht ankommen.

Belegung der State-Tabelle. Alarmieren Sie auf nf_conntrack_count als Anteil von nf_conntrack_max lange bevor sie voll ist, und auf die Table-full-Meldung des Kernels, die sonst ungelesen im Log sitzt.

Synthetische Prüfungen in der Form des echten Verkehrs. Ein Probe, der eine langlebige Verbindung hält und in Abständen einen Datensatz hindurchschiebt, verifiziert am anderen Ende, prüft das, was kaputtgeht. Ein frischer Ping prüft das, was nicht kaputtgeht.

Listen Sie nach jeder Routing- oder NAT-Änderung die Flows auf, die älter sind als die Änderung, und entscheiden Sie bewusst, ob Sie sie leeren.

Die Korrektur ist ein Skalpell

Löschen Sie den State für die betroffene Quelle. Das nächste Paket erzeugt einen frischen Eintrag mit der aktuellen Entscheidung, und der Stream läuft weiter.

conntrack -D -s <source>

Ein Neustart oder ein vollständiger Flush funktioniert auch, und reißt jede andere lebende Verbindung mit. Bei einer vollen Tabelle besteht die Korrektur darin, nf_conntrack_max zusammen mit der Hash-Größe zu erhöhen, das Established-Timeout zu verkürzen, wo keine Tage nötig sind, und den Client zu finden, der die Flows erzeugt.