Transparentní proxy DNAT: proč záleží na zpáteční trase
Pochopte, proč DNAT může doručit požadavek samostatnému proxy, zatímco odpověď obejde bránu a spojení se přeruší.
Přesměrovaný SYN může dorazit do Squidu, zatímco klient stále čeká na vypršení. V nastavení DNAT musí zpětný paket dorazit také do brány, která vlastní stav překladu.
Uvažujme tuto hypotetickou 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 directlyKlient se původně připojil k adrese webu. Po DNAT proxy vidí zdroj klienta a může použít trasu místní podsítě k přímé odpovědi. Tato odpověď obejde zpětný překlad brány a může se ke klientovi dostat z adresy proxy místo očekávané adresy webu. Brána nemůže opravit pakety, které nikdy nedostane.
| Přístup | Důsledek |
|---|---|
| Vést odpovědi proxy přes překládající bránu | Příchozí spojení k proxy si může zachovat zdrojovou adresu klienta |
| Použít i odpovídající překlad zdroje | Proxy odpovídá bráně jako svému protějšku, ale nyní vidí tento přeložený zdroj místo původního klienta |
Neodstraňujte SNAT kvůli hezčím logům, aniž byste ověřili zpětnou trasu. Široké nasazení také mění zdrojové ACL a přiřazení; přijměte tento důsledek jako součást návrhu.
Důvěryhodný HTTP skok může přenést metadata klienta v předávací hlavičce, ale NAT tuto hlavičku nevytváří ani z ní nedělá identitu protějšku TCP. Zachování zdroje na spojení do Squidu jej také nezachová na samostatném spojení Squidu na web.
Nakonec návrh zachycení stále musí poskytnout informace o cíli, které Squid vyžaduje. Symetrické zpětné směrování řeší tento mechanismus vypršení, ne celou konfiguraci transparentního proxy.