Transparante proxy-DNAT: waarom de retourroute telt
Begrijp waarom DNAT een verzoek aan een aparte proxy kan afleveren terwijl het antwoord de gateway omzeilt en de verbinding breekt.
Een omgeleid SYN kan Squid bereiken terwijl de client nog steeds in een time-out loopt. In een DNAT-opstelling moet het retourpakket ook de gateway bereiken die de vertaalstatus bezit.
Beschouw dit 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 directlyDe client maakte oorspronkelijk verbinding met een websiteadres. Na DNAT ziet de proxy de bron van de client en kan de route van het lokale subnet gebruiken om direct te antwoorden. Dat antwoord mist de omgekeerde vertaling van de gateway en kan de client bereiken vanaf het proxyadres in plaats van het verwachte websiteadres. De gateway kan pakketten die hij nooit ontvangt niet repareren.
| Aanpak | Gevolg |
|---|---|
| Antwoorden van de proxy via de vertalende gateway leiden | De inkomende proxyverbinding kan het bronadres van de client behouden |
| Ook passende bronvertaling toepassen | De proxy antwoordt de gateway als zijn peer, maar ziet nu die vertaalde bron in plaats van de oorspronkelijke client |
Verwijder SNAT niet voor mooiere logbestanden zonder de retourroute te verifiëren. Brede toepassing verandert ook bron-ACL's en toewijzing; accepteer dat gevolg als onderdeel van het ontwerp.
Een vertrouwde HTTP-hop kan clientmetadata in een doorstuurheader vervoeren, maar NAT maakt die header niet en verandert hem niet in een TCP-peer-identiteit. Een bron behouden op de verbinding naar Squid behoudt die ook niet op Squids aparte websiteverbinding.
Ten slotte moet het onderscheppingsontwerp nog steeds de door Squid vereiste bestemmingsinformatie leveren. Symmetrische retourroutering lost dit time-outmechanisme op, niet de hele transparante-proxyconfiguratie.