DNAT proxy transparent : pourquoi la route de retour compte
Comprenez pourquoi DNAT peut livrer une requête à un proxy distinct tandis que la réponse contourne la passerelle et coupe la connexion.
Un SYN redirigé peut atteindre Squid alors que le client expire toujours. Dans un montage DNAT, le paquet de retour doit aussi atteindre la passerelle qui détient l'état de traduction.
Considérez ce LAN hypothétique :
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 directlyLe client s'est d'abord connecté à une adresse de site web. Après DNAT, le proxy voit la source du client et peut utiliser la route du sous-réseau local pour répondre directement. Cette réponse manque la traduction inverse de la passerelle et peut atteindre le client depuis l'adresse du proxy au lieu de l'adresse du site attendue. La passerelle ne peut pas réparer des paquets qu'elle ne reçoit jamais.
| Approche | Conséquence |
|---|---|
| Faire passer les réponses du proxy par la passerelle qui traduit | La connexion entrante vers le proxy peut conserver l'adresse source du client |
| Appliquer aussi une traduction de source appropriée | Le proxy répond à la passerelle comme à son pair, mais voit désormais cette source traduite au lieu du client d'origine |
Ne retirez pas SNAT pour des journaux plus jolis sans vérifier la route de retour. L'appliquer largement change aussi les ACL de source et l'attribution ; acceptez cette conséquence comme partie du design.
Un saut HTTP de confiance peut transporter des métadonnées client dans un en-tête de transfert, mais NAT ne crée pas cet en-tête et ne le transforme pas en identité de pair TCP. Conserver une source sur la connexion vers Squid ne la conserve pas non plus sur la connexion séparée de Squid vers le site.
Enfin, la conception de l'interception doit encore fournir les informations de destination exigées par Squid. Le routage de retour symétrique résout ce mécanisme d'expiration, pas toute la configuration du proxy transparent.