Einem TPROXY-Paket bis zum Socket folgen
Prüfen Sie empfangenden Socket, Paket-Mark und lokale Policy-Route als einen Zustellpfad des transparenten Proxys.
Ein TPROXY-Zähler kann steigen, während die Anwendung nichts empfängt. Die Regel hat gepasst, doch die lokale Zustellung hängt weiterhin von Policy-Routing und einem passenden empfangenden Socket ab.
Linux TPROXY kann Verkehr abfangen, ohne das Ziel umzuschreiben, wie es DNAT tut. Pakete an ein nicht-lokales Ziel müssen daher einen geeigneten lokalen Socket erreichen.
Dem Zustellpfad folgen
- Der Verkehr erreicht den Abfang-Host über die vorgesehene Schnittstelle und Adressfamilie.
- Abfangregel und Paket-Mark bestimmen die Policy für die lokale Zustellung.
- Eine passende Policy-Regel wählt eine Route, die die Pakete lokal zustellt.
- Der Proxy nutzt einen unterstützten transparenten Listener mit der nötigen Socket-Option.
Das IPv4-Beispiel des Kernels setzt Anwendungsunterstützung für IP_TRANSPARENT voraus. Ein normaler Listener auf demselben Port oder eine globale Nicht-Lokal-Bindung belegt diese Unterstützung nicht.
| Beobachtung | Nächste Prüfung |
|---|---|
| Keine relevanten eingehenden Pakete | Verkehrsweg und Eingangsschnittstelle |
| Pakete kommen an; Abfangzähler bleibt stehen | Adressfamilie, Kette und Trefferbedingungen |
| Regel trifft; lokale Zustellung scheitert | Mark und Auswahl der Policy-Route |
| Socket lauscht; Anwendung sieht nichts | Transparente Socket-Fähigkeit und Eigentümer des Listeners |
| Anfrage beginnt; spätere Antworten scheitern | Treffer für bestehende Sockets und Rückrouten |
Halten Sie die geladene Konfiguration und den Netzwerk-Namespace zu jeder Beobachtung fest. Eine spätere Regel kann ein Mark überschreiben oder eine andere Route wählen. Erfolgt das Abfangen auf dem Host, während der Listener in einem Container läuft, stellt eine gültige hostlokale Route nicht automatisch in diesen Container zu.
Spätere Pakete einkalkulieren
Das Kernel-Beispiel enthält Socket-Treffer und einen DIVERT-Pfad, der Pakete transparenter Sockets markiert. Lässt man ihn weg, kann späterer Verkehr auf einem anderen Pfad bleiben, selbst wenn das erste Abfangen gelingt.
Nutzen Sie den unterstützten transparenten Modus der Anwendung und die passende Kernel-Dokumentation je Adressfamilie. Ein IPv4-Befehl für die lokale Route konfiguriert kein IPv6, und Unterstützung in einer Familie belegt nicht das Socket-Verhalten der anderen.
TPROXY erzeugt auch keine SOCKS-Aushandlung. Eine Komponente von transparent zu SOCKS muss weiterhin das Ziel ermitteln und mit ihrem Upstream verhandeln.
Umstieg von REDIRECT
Halten Sie fest, wie die bestehende Anwendung das ursprüngliche Ziel ermittelt. REDIRECT ändert das Ziel und stützt sich auf den passenden Wiederherstellungsmechanismus; TPROXY braucht seinen transparenten Socket und die Routing-Einrichtung. Wählen Sie nach Anwendung und Quelladress-Policy.
Bringen Sie Zähler mit der gewählten Route, der Socket-Fähigkeit und dem Anwendungslog zusammen, bevor Sie den Abfangmodus wechseln. Auf einer Distribution mit den nötigen Mitteln ist ein fehlender Zustellschritt ein besserer Ausgangspunkt als eine Neukompilierung des Kernels.