Proxy SOCKS5 per OpenVPN: tunnel TCP o proxy per le applicazioni?

Le reti che consentono solo l'uscita tramite proxy sono il luogo in cui un profilo che funzionava muore all'improvviso. L'indirizzo del proxy è la variabile meno interessante di quel fallimento. Tutto dipende dalla forma del traffico che il proxy inoltrerà, perché questi proxy trasportano un flusso di byte e un tunnel UDP non lo è. Restano due architetture, e si rompono in punti diversi.

Un solo vincolo decide il progetto

SOCKS5 specifica davvero una modalità di associazione UDP. Il supporto proxy del client OpenVPN è comunque costruito attorno ai flussi: socks-proxy è documentato per i profili TCP, e un proxy HTTP CONNECT non ha alcun percorso per i datagrammi. Una riga di documentazione risolve l'architettura prima che tocchiate un file di configurazione.

La domanda quindi non è quale proxy scegliere. È se il tunnel diventa un flusso, oppure resta un datagramma e lascia che qualcos'altro assorba il proxying.

Opzione A: trasformare il tunnel in un flusso

Serve un server con un listener TCP e un profilo client che nomini il proxy. Entrambi i pezzi sono necessari, e il lato server è quello che si dimentica:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Sostituite l'ultima riga con http-proxy proxy.internal 8080 quando il proxy parla HTTP, e aggiungete un file di credenziali se lo richiede. Il proxy deve accettare di eseguire CONNECT verso la vostra porta VPN, e il server deve rispondere in TCP; un listener solo UDP ignora il tentativo. Scegliere 443 è una mossa pratica, perché molte reti restrittive consentono quella e poco altro.

Il costo è TCP impilato su TCP. Un segmento esterno perso blocca ogni flusso interno che condivide quella connessione, così un ripristino che normalmente sarebbe indipendente diventa condiviso. Anche la configurazione richiede più tempo, e un percorso esterno instabile diventa un tunnel instabile invece che lento.

Opzione B: lasciare in pace il tunnel

Quando il tunnel deve restare su UDP, non è il tunnel il posto dove si configura qualcosa. Invece il TCP in uscita dalle applicazioni viene reindirizzato a un listener SOCKS locale, e le applicazioni non scoprono mai che esiste un proxy. Su Linux di solito è redsocks più una regola NAT REDIRECT nella tabella nat.

Ancora solo TCP. Un proxy solo HTTP come privoxy non può inoltrare protocolli arbitrari, e questo progetto non aggiunge alcun supporto per i datagrammi nemmeno alle applicazioni.

Dire a ogni applicazione del proxy direttamente è di solito meglio quando il software lo supporta. È più facile da verificare, e fallisce in un punto che potete davvero vedere.

Dove fallisce ciascuna opzione

L'opzione A fallisce quando al server manca un listener TCP, quando il proxy rifiuta la destinazione CONNECT o quando il flusso esterno è limitato sotto ciò che serve al tunnel. I primi due lasciano una voce nel log del proxy; il terzo lascia una connessione che si stabilisce e poi sembra sbagliata. Leggete quel log prima di modificare il profilo, perché separa un problema di autorizzazione da un problema di capacità. Un CONNECT completato sposta l'indagine dentro il tunnel.

L'opzione B fallisce per tutto ciò che richiede datagrammi, per i protocolli che il proxy non comprende, e in silenzio sugli host dove la regola di reindirizzamento esiste ma il routing manda il traffico oltre.

Nessuna delle due opzioni cambia il requisito del dispositivo. I pacchetti hanno ancora bisogno di un nodo TUN o TAP prima che il kernel li instradi, quindi il processo ha ancora bisogno di permessi su /dev/net/tun. Un wrapper cambia ciò che accade dopo che quel nodo è aperto, non se ne avete bisogno.

Dimostrare quale percorso avete costruito

Guardate i socket invece dell'icona nella barra delle applicazioni. Il processo VPN dovrebbe mantenere una connessione stabilita verso l'indirizzo del proxy, e il proxy dovrebbe aver registrato la destinazione che gli è stato chiesto di raggiungere:

ss -tnp | grep openvpn

Poi cercate una destinazione che solo il tunnel può servire, e un nome a cui solo il resolver del tunnel può rispondere. Una connessione proxy completata con un tunnel morto di solito significa che l'estremità remota non ha mai offerto il trasporto indicato nel vostro profilo.

Annotate il trasporto e il proxy che accetta in un posto duraturo. Quando lo stesso profilo fallisce su un'altra rete, quella nota esclude o conferma il proxy in pochi secondi.