Transparent proxy-DNAT: varför returvägen spelar roll
Förstå varför DNAT kan leverera en begäran till en separat proxy medan svaret kringgår gatewayen och bryter anslutningen.
Ett omdirigerat SYN kan nå Squid medan klienten fortfarande får tidsgräns. I en DNAT-uppsättning måste även returpaketet nå gatewayen som äger översättningstillståndet.
Tänk dig detta hypotetiska 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 anslöt ursprungligen till en webbplatsadress. Efter DNAT ser proxyn klientens källa och kan använda det lokala subnätets rutt för att svara direkt. Det svaret missar gatewayens omvända översättning och kan nå klienten från proxyadressen i stället för den förväntade webbplatsadressen. Gatewayen kan inte reparera paket den aldrig tar emot.
| Tillvägagångssätt | Konsekvens |
|---|---|
| Leda proxyns svar genom gatewayen som översätter | Den inkommande proxyanslutningen kan behålla klientens källadress |
| Använda lämplig källöversättning också | Proxyn svarar gatewayen som sin peer, men ser nu den översatta källan i stället för den ursprungliga klienten |
Ta inte bort SNAT för snyggare loggar utan att verifiera returvägen. Bred tillämpning ändrar också käll-ACL:er och tillskrivning; acceptera den konsekvensen som en del av designen.
Ett betrott HTTP-hopp kan förmedla klientmetadata i ett vidarebefordranhuvud, men NAT skapar inte det huvudet eller gör det till en TCP-peer-identitet. Att bevara en källa på anslutningen till Squid bevarar den inte heller på Squids separata webbplatsanslutning.
Slutligen måste avlyssningsdesignen fortfarande tillhandahålla den destinationsinformation som Squid kräver. Symmetrisk returrouting löser denna tidsgränsmekanism, inte hela den transparenta proxykonfigurationen.