Transparenter Proxy-DNAT: Warum die Rückroute zählt
Verstehen Sie, warum DNAT eine Anfrage an einen separaten Proxy zustellen kann, während die Antwort das Gateway umgeht und die Verbindung bricht.
Ein umgeleitetes SYN kann bei Squid ankommen, während der Client noch in die Zeitüberschreitung läuft. In einem DNAT-Aufbau muss das Rücksendepaket auch das Gateway erreichen, das den Übersetzungszustand hält.
Betrachten Sie dieses hypothetische LAN:
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyDer Client verband sich ursprünglich mit einer Website-Adresse. Nach DNAT sieht der Proxy die Quelle des Clients und kann die Route des lokalen Subnetzes nutzen, um direkt zu antworten. Diese Antwort verfehlt die Rückübersetzung des Gateways und kann den Client von der Proxy-Adresse statt von der erwarteten Website-Adresse erreichen. Das Gateway kann Pakete nicht reparieren, die es nie erhält.
| Ansatz | Folge |
|---|---|
| Antworten des Proxys über das übersetzende Gateway führen | Die eingehende Proxy-Verbindung kann die Quelladresse des Clients behalten |
| Auch eine passende Quellübersetzung anwenden | Der Proxy antwortet dem Gateway als seinem Peer, sieht nun aber diese übersetzte Quelle statt des ursprünglichen Clients |
Entfernen Sie SNAT nicht für schönere Protokolle, ohne die Rückroute zu prüfen. Eine breite Anwendung ändert auch Quell-ACLs und die Zuordnung; akzeptieren Sie diese Folge als Teil des Designs.
Ein vertrauenswürdiger HTTP-Hop kann Client-Metadaten in einem Forwarding-Header übertragen, aber NAT erzeugt diesen Header nicht und macht ihn nicht zu einer TCP-Peer-Identität. Eine Quelle auf der Verbindung zu Squid zu bewahren, bewahrt sie auch nicht auf Squids separater Website-Verbindung.
Schließlich muss das Interception-Design weiterhin die von Squid benötigten Zielinformationen bereitstellen. Symmetrisches Rück-Routing löst diesen Timeout-Mechanismus, nicht die gesamte Transparent-Proxy-Konfiguration.