Gjennomsiktig proxy-DNAT: hvorfor returruten betyr noe
Forstå hvorfor DNAT kan levere en forespørsel til en separat proxy mens svaret omgår gatewayen og bryter forbindelsen.
Et omdirigert SYN kan nå Squid mens klienten fortsatt får tidsavbrudd. I et DNAT-oppsett må returpakken også nå gatewayen som eier oversettelsestilstanden.
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 koblet opprinnelig til en nettstedsadresse. Etter DNAT ser proxyen klientens kilde og kan bruke ruten til det lokale subnettet for å svare direkte. Det svaret går glipp av gatewayens omvendte oversettelse og kan nå klienten fra proxyadressen i stedet for den forventede nettstedsadressen. Gatewayen kan ikke reparere pakker den aldri mottar.
| Fremgangsmåte | Konsekvens |
|---|---|
| Føre proxyens svar gjennom gatewayen som oversetter | Den innkommende proxyforbindelsen kan beholde klientens kildeadresse |
| Bruke passende kildeoversettelse også | Proxyen svarer gatewayen som sin peer, men ser nå den oversatte kilden i stedet for den opprinnelige klienten |
Ikke fjern SNAT for penere logger uten å verifisere returruten. Bred bruk endrer også kilde-ACL-er og tilskrivning; godta den konsekvensen som en del av designet.
Et klarert HTTP-hopp kan formidle klientmetadata i en videresendingsheader, men NAT lager ikke den headeren eller gjør den til en TCP-peer-identitet. Å bevare en kilde på forbindelsen til Squid bevarer den heller ikke på Squids separate nettstedsforbindelse.
Til slutt må avlyttingsdesignet fortsatt levere destinasjonsinformasjonen Squid krever. Symmetrisk returruting løser denne tidsavbruddsmekanismen, ikke hele den gjennomsiktige proxy-konfigurasjonen.