DNAT de proxy transparente: por que importa a ruta de volta
Entenda por que DNAT pode entregar unha solicitude a un proxy separado mentres a resposta evita a pasarela e rompe a conexión.
Un SYN redirixido pode chegar a Squid mentres o cliente aínda expira. Nunha configuración DNAT, o paquete de volta tamén debe chegar á pasarela que posúe o estado de tradución.
Considere esta 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 directlyO cliente conectou orixinalmente a un enderezo de sitio web. Tras DNAT, o proxy ve a orixe do cliente e pode usar a ruta da subrede local para responder directamente. Esa resposta perde a tradución inversa da pasarela e pode chegar ao cliente desde o enderezo do proxy en lugar do enderezo de sitio web esperado. A pasarela non pode reparar paquetes que nunca recibe.
| Enfoque | Consecuencia |
|---|---|
| Encamiñar as respostas do proxy pola pasarela que traduce | A conexión entrante ao proxy pode conservar o enderezo de orixe do cliente |
| Aplicar tamén a tradución de orixe axeitada | O proxy responde á pasarela como o seu par, pero agora ve esa orixe traducida en lugar do cliente orixinal |
Non elimine SNAT para ter rexistros máis bonitos sen verificar a ruta de volta. Aplicarlo amplamente tamén cambia as ACL de orixe e a atribución; acepte esa consecuencia como parte do deseño.
Un salto HTTP de confianza pode transmitir metadatos do cliente nunha cabeceira de reenvío, pero NAT non crea esa cabeceira nin a converte nunha identidade de par TCP. Conservar unha orixe na conexión cara a Squid tampouco a conserva na conexión separada de Squid ao sitio web.
Por último, o deseño de intercepción aínda debe proporcionar a información de destino que Squid require. O encamiñamento simétrico de volta resolve este mecanismo de expiración, non toda a configuración do proxy transparente.