Tcpdump zeigt einen anderen Umleitungsport an, nachdem die REDIRECT-Regel in iptables hinzugefügt wurde

Question

Um es klarzustellen: Der Test des OP wird vom System 192.168.1.100 zu sich selbst durchgeführt, nicht von einem Remote-System, und das ist die Ursache des Problems. Der Port wurde in diesem Fall nicht geändert, da keine NAT-Regel übereinstimmte, während er gepasst hätte, wenn er von einem Remote-System ausgeführt worden wäre.

Das folgende Schema zeigt, in welcher Reihenfolge die Operationen an einem Paket ausgeführt werden:

Der Grund liegt in der Funktionsweise von NAT unter Linux:iptablessieht ein Paket in der natTabelle nur für das erste Paket eines neuen Conntrack-Flows (das sich somit im Status NEU befindet).

Diese Regel funktioniert einwandfrei, wenn sie von einem Remote-System aus erfolgt. In diesem Fall ist das erste angezeigte Paket ein eingehendes Paket:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Bei allen folgenden Paketen im gleichen Fluss wird conntrack die Portänderung (oder Portumkehr für Antworten) direkt handhaben und alle iptables-Regeln in der natTabelle überspringen (wie im Schema geschrieben: natTabelle wird nur für NEWVerbindungen konsultiert). Daher (unter Überspringen des Antwortpaketteils) wird das nächste eingehende Paket stattdessen folgendes durchlaufen:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack: to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Bei einem Test des Systems selbst ist das erste Paket kein eingehendes Paket, sondern ein ausgehendes Paket. Dies geschieht stattdessen über die ausgehende loSchnittstelle:

local process client curl --> routing decision --> conntrack --> nat/OUTPUT (no rule here)
--> reroute check --> AF_PACKET (tcpdump) --> to port 8000

Und jetzt wird dieses Paket auf der Schnittstelle zurückgeschleift lo, es erscheint erneut als Paket, das nicht mehr das erste Paket in einer Verbindung ist, also folgt der zweite Fall wie oben: conntrack allein kümmert sich um das NAT und ruft nicht auf nat/PREROUTING. Außer dass es im Schritt davor nicht angewiesen wurde, NAT durchzuführen:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack
--> routing decision --> ... -->nolocal process receiving on port8000

Da auf Port 8000 nichts lauscht, sendet das Betriebssystem ein TCP RST zurück.

Damit dies auf dem lokalen System funktioniert, REDIRECTmuss zusätzlich eine Regel in die Kette eingefügt werden nat/OUTPUT:

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

Zusätzliche Bemerkungen

Wenn der Fall für die Fernverwendung vorgesehen ist, testen Sie nicht vom lokalen System aus: Die vom Test durchlaufenen Regeln sind nicht dieselben. Dadurch spiegelt der Test nicht die Realität wider.

Verwenden Sie einfach einen Netzwerk-Namespace, um ein Pocket-Remote-System zu erstellen, falls kein anderes System verfügbar ist. Beispiel, das mit einem System funktionieren sollte, das nur die nat/PREROUTINGRegel des OP hat und Folgendes tut curl http://192.168.1.100/(wofür kein DNS erforderlich ist):
```
ip netns add remotesystem
ip link add name vethremote up type veth peer netns remotesystem name eth0
ip address add 192.0.2.1/24 dev vethremote
ip -n remotesystem address add 192.0.2.2/24 dev eth0
ip -n remotesystem link set eth0 up
ip -n remotesystem route add 192.168.1.100 via 192.0.2.1
ip netns exec remotesystem curl http://192.168.1.100:8000/
```
tcpdumpund NAT

tcpdumpgeschieht in den AF_PACKETSchritten im obigen Schema: sehr früh für den Eingang und sehr spät für den Ausgang. Das bedeutet, dass im Fall eines Remote-Systems Port 30000 niemals erfasst wird, selbst wenn es funktioniert. Im Fall eines lokalen Systems nat/OUTPUTwird Port 30000 erfasst, sobald die Regel hinzugefügt wurde.

Vertrauen Sie einfach nicht blind der beim tcpdumpNAT angezeigten Adresse/dem angezeigten Port: Es hängt vom Einzelfall ab und davon, wo die Erfassung stattfindet.

Answer 1