Deursigtige proxy DNAT: waarom die terugroete saak maak
Verstaan waarom DNAT 'n versoek by 'n aparte proxy kan aflewer terwyl die antwoord die poort oorslaan en die verbinding breek.
'n Herleide SYN kan by Squid aankom terwyl die kliënt steeds 'n tydsverloop kry. In 'n DNAT-opstelling moet die terugpakket ook die poort bereik wat die vertaalingtoestand besit.
Oorweeg hierdie hipotetiese 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 directlyDie kliënt het oorspronklik aan 'n webwerfadres gekoppel. Ná DNAT sien die proxy die kliënt se bron en kan sy plaaslike subnetroete gebruik om direk te antwoord. Daardie antwoord mis die poort se omgekeerde vertaling en kan die kliënt van die proxy-adres bereik in plaas van die verwagte webwerfadres. Die poort kan nie pakkette herstel wat hy nooit ontvang nie.
| Benadering | Gevolg |
|---|---|
| Lei die proxy se antwoorde deur die vertalende poort | Die inkomende proxyverbinding kan die kliënt se bronadres behou |
| Pas ook toepaslike bronvertaling toe | Die proxy antwoord die poort as sy eweknie, maar sien nou daardie vertaalde bron eerder as die oorspronklike kliënt |
Moenie SNAT verwyder vir mooier logs sonder om die terugroete te verifieer nie. Om dit breed toe te pas verander ook bron-ACL's en toeskrywing; aanvaar daardie gevolg as deel van die ontwerp.
'n Vertroude HTTP-hop kan kliëntmetadata in 'n deurstuurkop oordra, maar NAT skep nie daardie kop nie en maak dit nie 'n TCP-eweknie-identiteit nie. Om 'n bron op die verbinding na Squid te bewaar, bewaar dit ook nie op Squid se aparte webwerfverbinding nie.
Laastens moet die onderskeppingsontwerp nog Squid se vereiste bestemmingsinligting verskaf. Simmetriese terugroetering los hierdie tydsverloopmeganisme op, nie die hele deursigtige-proxy-konfigurasie nie.