OpenVPN attraverso un proxy HTTP: leggete prima la risposta CONNECT
Un proxy CONNECT inoltra byte, quindi entrambe le estremità necessitano di TCP. Leggete 407, 403 e 503 prima di incolpare i certificati, e lasciate attiva la verifica del server.
Puntate un client VPN a un proxy HTTP aziendale, e il primo fatto utile è che il proxy non parla il protocollo della VPN. Apre una connessione TCP ordinaria verso l’indirizzo che avete indicato e poi si fa da parte, lasciando che il client e il server facciano il proprio scambio attraverso quel flusso. Tutto ciò che serve al client, dal tipo di trasporto all’ascoltatore del server, deve corrispondere a questa disposizione. Due disallineamenti spiegano la maggior parte degli errori: un profilo UDP indirizzato a un proxy CONNECT e una risposta del proxy scambiata per un errore della VPN.
Che cosa trasporta il proxy e che cosa no
Il proxy è solo un salto di trasporto. Non diventa il proxy del browser, non memorizza nella cache i siti che visitate attraverso il tunnel e non vede il traffico interno a meno che qualcuno non abbia configurato deliberatamente l’ispezione. Il tunnel che apre è opaco per lui per progettazione.
Ciò significa anche che il proxy non può riparare un server che non ha un ascoltatore corrispondente. Il permesso di raggiungere una destinazione e un servizio in ascolto su quella destinazione sono due fatti distinti, e solo il primo appartiene all’amministratore del proxy.
Il vettore deve essere TCP a entrambe le estremità
Un proxy CONNECT convenzionale inoltra solo un flusso di byte , quindi il client deve usare un trasporto a flusso. Un frammento di client per quel caso appare così:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Il lato server necessita di un vero ascoltatore TCP sulla porta indicata nella riga remote. Cambiare proto udp in proto tcp-client in un profilo crea un client che attende un flusso; non crea il flusso dall’altra parte. Se lo stesso server risponde anche su UDP su quella porta, è un altro ascoltatore, non una seconda modalità dello stesso.
Dove esiste un’istanza TCP separata, il suo dispositivo di tunnel, il pool di indirizzi e l’instradamento sono risorse proprie. Copiare una configurazione funzionante e modificare la parola del trasporto lascia quelle risorse puntate all’istanza originale, il che produce una connessione che si autentica e poi non instrada nulla.
Leggete la risposta del proxy prima del risultato della VPN
Il primo scambio del client è una riga di richiesta che nomina l’host e la porta di destinazione. La risposta a quella riga vi dice se esiste un flusso di byte, e arriva prima che venga controllato qualsiasi certificato o credenziale:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
Una risposta di classe 200 a CONNECT significa che il flusso esiste. Non dice nulla sul fatto che il certificato del gateway sia attendibile, che la chiave condivisa corrisponda o che l’account utente sia valido. Quei controlli avvengono dopo, dentro il flusso, e falliscono con i messaggi del client stesso invece che con una riga di stato HTTP. Cercate nel registro del client il primo OpenVPN evento dopo la stretta di mano con il proxy, non l’ultima riga prima che la finestra si chiudesse.
Le credenziali del proxy e quelle della VPN sono spesso identità diverse in mano a team diversi. Un 407 non è una password sbagliata dell’account VPN, e un certificato rifiutato non è un problema di permessi del proxy.
Che cosa non espone CONNECT
Un tunnel CONNECT esplicito non è intercettazione. Il proxy inoltra byte e non termina la sessione TLS della VPN, quindi la verifica del certificato del server da parte del client resta significativa e dovrebbe rimanere attiva. Disattivare la verifica per superare un proxy risolve un problema diverso dal vostro.
Esistono disposizioni separate in cui un’organizzazione termina e ispeziona TLS deliberatamente. Queste richiedono una propria configurazione di fiducia e una propria decisione di policy, e non sono ciò che chiede una riga http-proxy ordinaria.
Il costo del TCP dentro il TCP
Portare il tunnel su TCP mantiene il flusso esterno ordinato e ritrasmesso, e il traffico interno è di solito anch’esso TCP. I due meccanismi di recupero non si coordinano, quindi un solo segmento perso può bloccare tutto ciò che condivide quel flusso esterno finché non viene ritrasmesso. È un vero compromesso per la compatibilità, non un aggiornamento gratuito.
Usate il percorso tramite proxy quando la rete non vi lascia alternative, e preferite un percorso UDP diretto dove la policy lo consente. In ogni caso, dopo una modifica confermate che lo stesso proxy, la stessa destinazione e lo stesso profilo raggiungano la fase successiva; un browser che carica una pagina a quell’indirizzo esercita un altro protocollo e non dimostra nulla sul tunnel.