Gjennomsiktig proxy-DNAT: kvifor returruta tel
Forstå kvifor DNAT kan levere ei førespurnad til ein separat proxy medan svaret omgår gatewayen og bryt sambandet.
Eit omdirigert SYN kan nå Squid medan klienten framleis får tidsavbrot. I eit DNAT-oppsett må returpakken òg nå gatewayen som eig omsetjingstilstanden.
Tenk deg dette hypotetiske LAN-et:
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 directlyKlienten kopla opphavleg til ei nettsideadresse. Etter DNAT ser proxyen kjelda til klienten og kan bruke ruta til det lokale subnettet for å svare direkte. Det svaret går glipp av den omvende omsetjinga til gatewayen og kan nå klienten frå proxyadressa i staden for den venta nettsideadressa. Gatewayen kan ikkje reparere pakkar han aldri mottek.
| Framgangsmåte | Konsekvens |
|---|---|
| Leie svara til proxyen gjennom gatewayen som omset | Den innkomande proxyforbindinga kan halde på kjeldeadressa til klienten |
| Bruke høveleg kjeldeomsetjing òg | Proxyen svarar gatewayen som jamlike sin, men ser no den omsette kjelda i staden for den opphavlege klienten |
Ikkje fjern SNAT for penare loggar utan å stadfeste returruta. Å bruke det breitt endrar òg kjelde-ACL-ar og tilskriving; godta den konsekvensen som ein del av designet.
Eit klarert HTTP-hopp kan formidle klientmetadata i ein vidaresendingsheader, men NAT lagar ikkje den headeren eller gjer han til ein TCP-peer-identitet. Å ta vare på ei kjelde på sambandet til Squid tek ho heller ikkje vare på i det separate nettsidesambandet til Squid.
Til slutt må avlyttingsdesignet framleis levere destinasjonsinformasjonen Squid krev. Symmetrisk returrutting løyser denne tidsavbrotsmekanismen, ikkje heile den gjennomsiktige proxy-konfigurasjonen.