Wann verfolgt das Conntrack-Modul von iptable den Status von Paketen?
Es muss zuerst Zustände speichern. Bei einer alten BSD-Firewall, die ich verwendet habe, wurde sie vermutlich IPFW genannt. Ich habe eine Regel aufgestellt, die "den Status des verlassenen Pakets verfolgen" lautete, und diese wurde in die ausgehende Richtung der Schnittstellen gestellt. Dann eine andere Regel für die eingehende Richtung, die sie mit den Zuständen verglichen hat, die durch die Regel für die ausgehende Richtung erstellt wurden. Früher gab es also zwei Regeln: (1) zum Auffüllen der Statustabelle, dies war in der Ausgangsrichtung, und (2) zum Nachschlagen der Statustabelle, dies war in der Eingangsrichtung.
Aber mit connntrack sehe ich, dass es auf die INPUT-Kette angewendet wird, wie diese Regel:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Ich frage mich, was diese Aussage eigentlich macht.
- Sagt es, dass es beginnt, Pakete zu verfolgen, die dieser Regel entsprechen, indem ihre Informationen in die Statustabelle aufgenommen werden?
- Oder heißt es, dass es bereits die Statusinformationen enthält und auf dieser Grundlage gegen eingehende Nachrichten vorgehen wird? (zB akzeptieren, wenn sie zu einer zuvor akzeptierten Verbindung gehörten?). Aber wo wurde in diesem Fall die Statustabelle ausgefüllt? Welche Regel gilt das? Oder ist es regellos und implizit?
Antworten
Einführungspräsentation von Netfilter und conntrack
Zunächst das obligatorische Schema zum Paketfluss in Netfilter und General Networking:
Netfilter ist das Paketfilter-Framework, das sich über den Rest des Netzwerkstapels einfügt (dargestellt durch "Routing-Entscheidung" und andere weiße, rundkantige Box-Teile). Netfilter bietet Hooks und APIs für andere Subsysteme und "Clients". Zu diesen Teilen gehören conntrack (der Verbindungs-Tracker) und iptables (oder nftables ). Die Trennung zwischen Netfilter und Conntrack ist ziemlich unscharf. Sie können conntrack einfach als integrierten Bestandteil von Netfilter betrachten.
In dem Schema, das die verschiedenen Schritte beschreibt, die ein Paket durchläuft, können Sie sehen, dass das Paket irgendwann (zwischen Raw / PREROUTING und Mangle / PREROUTING oder zwischen Raw / OUTPUT und Mangle / OUTPUT) Conntrack durchläuft .
Zu diesem Zeitpunkt sucht conntrack in seinen eigenen Nachschlagetabellen (einer Mini-Nachschlagedatenbank, die im Kernelspeicher gespeichert ist):
- Wenn dieses Paket charateristics nicht gefunden werden (und wenn nicht untracked in der rohen Tabelle deklariert), ein neue conntrack bidirektionalen Tupel Eintrag (Protokoll, dann spezifische Familie und Protokollinformationen: Ausgangsquelle und Port, anfängliches Ziel und Port, antworten Quelle und Hafen, Antwortziel und -port (diese beiden letzten sind normalerweise umgekehrt, es sei denn, NAT oder einige seltsame Protokolle sind beteiligt, z. B. Echoantwort-Matching-Echo-Anforderung für ICMP)), die den Fluss beschreiben, werden mit dem Status NEW erstellt.
- Wenn es (in eine beliebige Richtung) mit einem vorherigen Eintrag übereinstimmt und mit dem Status dieses Flusses kompatibel ist, kann der Flussstatus geändert werden (z. B. Wechsel von NEU zu ESTABLISHED, wenn dies zuvor nicht der Fall war).
- Wenn das Paket aus einem bestimmten Grund trotz seiner Eigenschaften nicht mit einem vorhandenen Datenfluss übereinstimmen kann (z. B. ein spätes TCP-Paket, das empfangen wurde, nachdem eine erneute Übertragung bereits erfolgreich gestartet wurde, sodass hinsichtlich der Sequenz und der SACK-Werte kein Fenster mehr vorhanden ist) Paket wird als UNGÜLTIG markiert.
- Es gibt einige andere Fälle wie RELATED: Hierbei handelt es sich um Pakete, die nicht Teil des Flusses selbst sind, sondern sich auf einen neuen Fluss beziehen, der einem anderen vorhandenen Fluss (dh in der Datenbank) zugeordnet werden kann. Zwei Beispiele sind ein ICMP-Fehler, der durch den Empfang eines Pakets entsteht (z. B. UDP-Port nicht erreichbar) oder wenn ein spezieller Protokollhelfer wie das Kernelmodul
nf_conntrack_ftp, das ein Plugin für das Conntrack- Subsystem ist, feststellt, dass ein Paket Teil des zugeordneten separaten Datenflusses ist mit den FTP-Befehlen PASV / EPSV oder PORT / EPRT im Befehlsfluss (an Port 21).
Die Frage beantworten
Nach alledem sind hier die Antworten auf Ihre beiden Kugeln:
Im Hauptnetzwerk-Namespace beginnt conntrack mit der Verfolgung von Verbindungen, sobald seine Module (einschließlich möglicher relevanter protokollspezifischer Untermodule) geladen sind. Für nicht initiale Netzwerk-Namespaces (Container ...) erfordert dies auch, dass ein anderes Subsystem darauf verweist (z. B. das Conntrack-Modul von iptables von OP oder die einmalige Verwendung des
conntrackspäter beschriebenen Befehls ). Dies ist die Standardeinstellung, und ein Paket muss speziell als UNTRACKED markiert werden, bevor das Conntrack- Subsystem erkennt , dass dieses Paket nicht verfolgt wird. Unter Linux gibt es nur wenige Fälle, in denen kein Tracking erforderlich wäre, aber dann sind Stateful Firewalling und Stateful / Dynamic NAT natürlich nicht mehr verfügbar (steless NAT, für das möglicherweise sogar die Verwendung von UNTRACKED erforderlich ist, kann es immer noch sein erledigt, aber nicht mit iptables . tc oder nftables können). Um zu vermeiden, dass Conntrack einige Pakete verarbeitet, kann diese Art von iptables- Regel verwendet werden (z. B. 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 --notrackWenn das Paket Filter / INPUT durchläuft und diese Regel erreicht:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTDas spezifische Kernelmodul der iptables
xt_conntrackfragt das Conntrack- Subsystem (das von den verschiedenen relevanten Kernelmodulen verwaltet wirdnf_conntrack*) ab und fragt in seiner Suchdatenbank nach dem Status dieses Pakets. Wenn die Antwort lautetRELATEDoderESTABLISHEDdas Paket übereinstimmt und mit dem ACCEPT-Urteil fortfährt. Tatsächlich wird das Ergebnis bereits bei der ersten Suche (normalerweise per Conntrack ) im Paket zwischengespeichert, sodass dies eine billige "Suche" ist. Dies ist daher eine generische Regel für die Verarbeitung von Flüssen, die bereits zuvor akzeptiert wurden. Diese Flows können anfänglich in Regeln akzeptiert werden, die dies explizit erwähnen,-m conntrack --ctstate NEWoder einfach in Regeln, die sie nicht erwähnen, sondern nach dieser generischen Regel stehen ( beachten Sie jedoch den UNGÜLTIGEN Status, der normalerweise vorher TROPFEN sollte).die Bearbeitung der eingehenden Pakete und ausgehende Pakete ganz symmetrisch ist zwischen PREROUTING und OUTPUT (auch wenn diese nicht aussehen symmetrisch): eine Kugel Hinzufügen conntrack Schnittstellen in PREROUTING sowie in OUTPUT (und in einigen anderen Orten, wenn man bedenkt NAT ist Arbeiten mit conntrack , mit Ausnahme des ersten Pakets im Status NEW (Durchqueren der Nat-Tabelle von iptables ). Dies kann geringfügig von der Beschreibung abweichen, die Sie über IPFW geschrieben haben. Wenn ein Server, auf dem Anwendungen ausgeführt werden, auch ausgehende Datenflüsse einschränkt, benötigt er höchstwahrscheinlich dieselbe generische iptables- Regel sowohl in filter / OUTPUT als auch in filter / INPUT, damit ausgehende Antwortpakete mit bereits akzeptiertem eingehendem Datenverkehr weitergeleitet werden können.
Weitere Informationen
Es gibt spezielle Tools für die Interaktion mit den Nachschlagetabellen des Conntrack- Subsystems von Conntrack-Tools .
conntrack: um den Inhalt der von conntrack verarbeiteten Nachschlagetabellen abzufragen, zu löschen oder zu aktualisieren .
Einige Beispiele.
Sie können alle nachverfolgten Einträge (die ohne zusätzlichen Filter groß sein können) auflisten mit:
conntrack -LWenn Ihr System NAT tut (zB ein Router vor einem privaten LAN oder Lauf VMs und Container) können Sie verwenden
--any-nat,--src-natoder--dst-natnur diejenigen anzuzeigen , resp. alle NAT, alle Quell-NAT (Maskerade) oder alle Ziel-NAT (normalerweise für weitergeleitete Ports):Echtzeitüberwachung von Conntrack- Ereignissen:
conntrack -Econntrackd: Ein Daemon, dessen zwei Hauptzwecke die Flussabrechnung und -statistik (Conntrack) oder die Stateful Firewall-Cluster- Statussynchronisation mit hoher Verfügbarkeit sind .
Die Verbindungsverfolgung ist eine separate Funktion von Netfilter und nicht mit IPTables konfiguriert.
In der Abbildung gibt es zwei conntrackSchritte im INPUT-Pfad und einen im OUTPUT-Pfad. Diese Schritte ordnen einzelne Pakete vorhandenen Verbindungen zu, die in der Verbindungsverfolgungstabelle verfolgt werden, oder erstellen neue Verbindungsverfolgungseinträge in der Tabelle.
Die Conntrack-Funktionalität ist ein Linux-Kernelmodul und wird in der Standardkonfiguration häufig im Kernel enthalten.
Der Conntrack-Betrieb kann durch Anpassen der net.netfilter.nf_conntrackSysctl-Werte eingestellt werden.
Ihre zweite Alternative ist, was passiert. Die Statusinformationen werden von der Conntrack-Funktion aufgezeichnet, und die IPTables-Regel konsultiert einfach die Conntrack-Tabelle zur Information.