DNAT con proxy trasparente: perché conta la rotta di ritorno
Capite perché DNAT può consegnare una richiesta a un proxy separato mentre la risposta aggira il gateway e interrompe la connessione.
Un SYN reindirizzato può arrivare a Squid mentre il client va ancora in timeout. In una configurazione DNAT anche il pacchetto di ritorno deve raggiungere il gateway che possiede lo stato di traduzione.
Considerate questa LAN ipotetica:
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 directlyIl client si era collegato in origine a un indirizzo di sito web. Dopo DNAT il proxy vede l'origine del client e può usare la rotta della sottorete locale per rispondere direttamente. Quella risposta manca la traduzione inversa del gateway e può raggiungere il client dall'indirizzo del proxy invece che dall'indirizzo del sito atteso. Il gateway non può riparare pacchetti che non riceve mai.
| Approccio | Conseguenza |
|---|---|
| Far passare le risposte del proxy dal gateway che traduce | La connessione in ingresso al proxy può conservare l'indirizzo di origine del client |
| Applicare anche una traduzione di origine adeguata | Il proxy risponde al gateway come suo pari, ma ora vede quella origine tradotta invece del client originale |
Non rimuovete SNAT per avere log più belli senza verificare la rotta di ritorno. Applicarlo in modo ampio cambia anche le ACL di origine e l'attribuzione; accettate questa conseguenza come parte del progetto.
Un salto HTTP fidato può trasportare metadati del client in un'intestazione di inoltro, ma NAT non crea quell'intestazione né la trasforma in identità di peer TCP. Conservare un'origine sulla connessione verso Squid non la conserva nemmeno sulla connessione separata di Squid al sito.
Infine, il progetto di intercettazione deve comunque fornire le informazioni di destinazione richieste da Squid. L'instradamento simmetrico di ritorno risolve questo meccanismo di timeout, non l'intera configurazione del proxy trasparente.