Gennemsigtig proxy-DNAT: hvorfor returruten betyder noget
Forstå hvorfor DNAT kan levere en anmodning til en separat proxy, mens svaret omgår gatewayen og bryder forbindelsen.
Et omdirigeret SYN kan nå Squid, mens klienten stadig får timeout. I en DNAT-opsætning skal returpakken også nå den gateway, der ejer oversættelsestilstanden.
Overvej dette hypotetiske 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 directlyKlienten oprettede oprindeligt forbindelse til en webstedsadresse. Efter DNAT ser proxyen klientens kilde og kan bruge den lokale undernetsrute til at svare direkte. Det svar omgår gatewayens omvendte oversættelse og kan nå klienten fra proxyadressen i stedet for den forventede webstedsadresse. Gatewayen kan ikke reparere pakker, den aldrig modtager.
| Fremgangsmåde | Konsekvens |
|---|---|
| Led proxyens svar gennem den oversættende gateway | Den indgående proxyforbindelse kan bevare klientens kildeadresse |
| Anvend også passende kildeoversættelse | Proxyen svarer gatewayen som sin peer, men ser nu den oversatte kilde i stedet for den oprindelige klient |
Fjern ikke SNAT for pænere logfiler uden at bekræfte returruten. Anvendes det bredt, ændres også kilde-ACL'er og tilskrivning; accepter den konsekvens som en del af designet.
Et betroet HTTP-hop kan videregive klientmetadata i en videresendelsesheader, men NAT opretter ikke den header eller gør den til en TCP-peer-identitet. At bevare en kilde på forbindelsen til Squid bevarer den heller ikke på Squids separate webstedsforbindelse.
Endelig skal aflytningsdesignet stadig levere den destinationsinformation, Squid kræver. Symmetrisk returrouting løser denne timeout-mekanisme, ikke hele den gennemsigtige proxy-konfiguration.