Destinazioni originali nell'inoltro trasparente da TCP a SOCKS
Spiega perché l'inoltro trasparente da TCP a SOCKS richiede un traduttore che recuperi la destinazione originale prima di negoziare con il proxy.
Un firewall può cambiare dove arriva una connessione TCP. Non può però, con quel solo cambiamento, insegnare all'applicazione di origine a parlare SOCKS.
Un normale server SOCKS attende una negoziazione che descriva la destinazione richiesta. Un'applicazione che non conosce il proxy invia invece subito i propri byte di protocollo. Reindirizza quei byte direttamente a un listener SOCKS e le due parti saranno in disaccordo sul primo messaggio.
Il componente mancante è un traduttore
Un componente trasparente da TCP a proxy si colloca tra queste interfacce. Scopre la destinazione richiesta in origine dall'applicazione, stabilisce la sessione SOCKS o HTTP CONNECT appropriata e poi inoltra i dati dell'applicazione sul flusso risultante.
Sul suo percorso Linux iptables, il codice sorgente di redsocks recupera la destinazione conservata tramite SO_ORIGINAL_DST. Altri sistemi operativi e metodi di reindirizzamento usano meccanismi diversi. Questa è una proprietà del reindirizzatore e della configurazione di rete, non una funzione di un normale client SOCKS.
L'informazione sulla destinazione originale spiega anche perché spostare una regola di reindirizzamento dall'host del proxy a un gateway non correlato non è sempre equivalente. Il processo ricevente necessita dei metadati richiesti dalla sua modalità di intercettazione. Un indirizzo riscritto altrove potrebbe non fornire più quell'informazione nella forma attesa.
Mantieni esplicito l'ambito del traduttore. Una connessione TCP reindirizzata funzionante non dimostra il supporto per UDP arbitrario, ICMP o per ogni percorso di risoluzione. Il protocollo del proxy a monte e l'implementazione del traduttore definiscono ancora le operazioni supportate.
Quando una configurazione fallisce subito dopo la connessione, controlla il confine del protocollo prima di ampliare le regole di accesso. Un listener SOCKS perfettamente raggiungibile può rifiutare byte che non sono mai stati una richiesta SOCKS.