DNAT de proxy transparent: per què importa la ruta de tornada
Enteneu per què DNAT pot lliurar una petició a un proxy separat mentre la resposta evita la passarel·la i trenca la connexió.
Un SYN redirigit pot arribar a Squid mentre el client encara fa temps d'espera. En una configuració DNAT, el paquet de tornada també ha d'arribar a la passarel·la que posseeix l'estat de traducció.
Considereu aquesta LAN hipotètica:
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 directlyEl client es va connectar originalment a una adreça de lloc web. Després del DNAT, el proxy veu l'origen del client i pot utilitzar la ruta de la subxarxa local per respondre directament. Aquesta resposta no passa per la traducció inversa de la passarel·la i pot arribar al client des de l'adreça del proxy en lloc de l'adreça esperada del lloc web. La passarel·la no pot reparar paquets que mai rep.
| Enfocament | Conseqüència |
|---|---|
| Fer passar les respostes del proxy per la passarel·la que tradueix | La connexió entrant al proxy pot conservar l'adreça d'origen del client |
| Aplicar també la traducció d'origen adequada | El proxy respon a la passarel·la com a parell seu, però ara veu aquest origen traduït en lloc del client original |
No elimineu SNAT per tenir registres més bonics sense verificar la ruta de tornada. Aplicar-lo àmpliament també canvia les ACL d'origen i l'atribució; accepteu aquesta conseqüència com a part del disseny.
Un salt HTTP de confiança pot transmetre metadades del client en una capçalera de reenviament, però NAT no crea aquesta capçalera ni la converteix en una identitat de parell TCP. Conservar un origen a la connexió cap a Squid tampoc el conserva a la connexió separada de Squid al lloc web.
Finalment, el disseny d'intercepció encara ha de proporcionar la informació de destinació que Squid requereix. L'encaminament simètric de tornada resol aquest mecanisme de temps d'espera, no tota la configuració del proxy transparent.