DNAT pentru proxy transparent: de ce contează ruta de retur
Înțelegeți de ce DNAT poate livra o cerere unui proxy separat în timp ce răspunsul ocolește gateway-ul și rupe conexiunea.
Un SYN redirecționat poate ajunge la Squid în timp ce clientul încă expiră. Într-o configurație DNAT, pachetul de retur trebuie să ajungă și la gateway-ul care deține starea de traducere.
Luați în considerare acest LAN ipotetic:
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 directlyClientul s-a conectat inițial la o adresă de site web. După DNAT, proxy-ul vede sursa clientului și poate folosi ruta subrețelei locale pentru a răspunde direct. Acel răspuns ratează traducerea inversă a gateway-ului și poate ajunge la client de la adresa proxy-ului în loc de adresa de site așteptată. Gateway-ul nu poate repara pachete pe care nu le primește niciodată.
| Abordare | Consecință |
|---|---|
| Trimiterea răspunsurilor proxy-ului prin gateway-ul care traduce | Conexiunea de intrare către proxy poate păstra adresa de sursă a clientului |
| Aplicarea și a unei traduceri de sursă adecvate | Proxy-ul răspunde gateway-ului ca partener, dar acum vede acea sursă tradusă în locul clientului original |
Nu eliminați SNAT pentru jurnale mai frumoase fără a verifica ruta de retur. Aplicarea pe scară largă schimbă și ACL-urile de sursă și atribuirea; acceptați această consecință ca parte a designului.
Un salt HTTP de încredere poate transporta metadate ale clientului într-un antet de redirecționare, dar NAT nu creează acel antet și nu îl transformă în identitate de partener TCP. Păstrarea unei surse pe conexiunea către Squid nu o păstrează nici pe conexiunea separată a Squid către site.
În final, proiectul de interceptare trebuie încă să furnizeze informațiile de destinație cerute de Squid. Rutarea simetrică de retur rezolvă acest mecanism de expirare, nu întreaga configurație de proxy transparent.