OpenVPN non si connette al Wi-Fi dell'hotel? Prova TCP 443

Apri il client, premi Connetti e leggi la riga di stato invece della finestra che segue. Un profilo che dopo una rete alberghiera, universitaria o mobile resta fermo su Connessione o In attesa del server di solito ha perso il trasporto da qualche parte lungo il percorso, non le credenziali. Il passo successivo utile è capire cosa trasporta quella rete prima di toccare il server. Non cambiare nulla finché lo stesso profilo non ha funzionato altrove.

Prova prima da un hotspot del telefono. Se il tunnel sale lì, server, certificato e account vanno tutti bene, e l'unica variabile rimasta è la rete davanti a te.

Parti dal client: leggi la riga di stato

La riga di stato dice quale fase è fallita. Un client bloccato su Connessione sta ancora risolvendo l'host o aprendo il socket esterno; uno che arriva a In attesa del server ha un percorso ma nessuna risposta; uno che si autentica e poi cade ha un problema del tutto diverso. Il registro del client e i campi remote e proto del profilo mostrano cosa sta tentando di fare il client, e --verb 4 su un client da riga di comando stampa lo stesso dettaglio. Confrontare tutto ciò con la rete davanti a te è ciò che trasforma 'la VPN è bloccata' in un'affermazione precisa.

Poi sonda la rete con gli strumenti che hai già. nc -vzu 203.0.113.10 1194 invia un datagramma UDP, curl -v telnet://203.0.113.10:443 riporta se la stretta di mano TCP si completa, e un browser che carica una pagina HTTPS dimostra solo che l'uscita 443 raggiunge quell'unico host. Le sonde piccole rispondono a ciò che il client VPN non può: quali porte e protocolli escono davvero da questa rete.

Tre comportamenti di rete sembrano uguali dal client e richiedono risposte diverse. L'uscita 443 può essere aperta, può essere consentito solo un proxy, oppure 443 può essere inoltrato in modo trasparente a un apparecchio di ispezione che non riesce a leggere ciò che trasporta. Il primo si risolve con la modifica del profilo qui sotto, il secondo con le impostazioni del proxy, e il terzo può completare la stretta di mano per poi bloccarsi quando l'ispettore decide che il flusso non gli piace. Sapere quale dei tre hai davanti è la differenza tra una modifica di dieci minuti e un pomeriggio passato a reinstallare client.

Sposta insieme il listener e il profilo

Lato server, imposta il listener su ciò che la rete consente: port 443 e proto tcp nella configurazione del server, poi riavvia il servizio e verifica il socket con ss -lntp. Lato client, il profilo deve concordare, perché trasporto e porta stanno fuori dal tunnel: proto tcp e port 443 nel .ovpn, o i campi corrispondenti nella schermata delle impostazioni dell'app. Un profilo ancora puntato su UDP 1194 fallisce esattamente come prima, e la tentazione è dare la colpa a un firewall già corretto. Se lo stesso host risponde anche in HTTPS sulla 443, i due listener non possono condividere quell'indirizzo e protocollo; assegna alla VPN un secondo indirizzo o metti davanti un demultiplexer.

Segui la prima connessione con tcpdump -ni any port 443 su entrambi i lati. I pacchetti che lasciano il client e non arrivano mai significano che la rete filtra dopo tutto, oppure che l'indirizzo nel profilo non è quello che supponi. I pacchetti che arrivano senza risposta ti riportano al registro del server, dove un disallineamento di protocollo si manifesta subito come pacchetto scartato.

Quando solo un proxy esce dalla rete

Alcune reti per ospiti non consentono altro che un proxy HTTP, un vincolo diverso da una porta chiusa che esclude più di OpenVPN. I client che parlano solo PPTP, L2TP/IPsec o IPsec nudo non hanno modo di attraversarlo, perché quei progetti si aspettano che il loro protocollo esterno arrivi direttamente al server. OpenVPN può, con http-proxy proxy.example.net 8080 nel profilo del client, a condizione che il proxy consenta il metodo CONNECT verso la tua porta. Un proxy SOCKS è ancora più semplice, perché inoltra il flusso senza interessarsi di ciò che contiene.

Dove il client non ha supporto per i proxy, di solito resta un tunnel SSH sulla 443. Aggiunge un secondo strato, e il gestore della rete potrebbe avere un'opinione al riguardo, quindi trattalo come un ponte per un singolo viaggio invece che come un'architettura.

Valuta il costo del ripiego prima di tenerlo

TCP dentro TCP ha un costo noto. Quando la connessione esterna è TCP e il payload è anch'esso TCP, un segmento perso provoca ritrasmissione a entrambi i livelli, e la connessione interna arretra davanti a una perdita che non può vedere. La navigazione lo sopporta; le sessioni interattive e le chiamate lo sentono. Tieni il listener TCP 443 come ripiego per le reti che lo esigono, e lascia UDP come predefinito per tutto ciò che ancora lo lascia passare.

Registra la scelta nel nome del profilo e nelle note di assistenza: quale porta, quale protocollo e quale rete l'ha determinata. Poi chiedi all'amministratore della rete se quella porta resterà aperta dopo il prossimo rinnovo delle apparecchiature, perché un ripiego che sparisce in silenzio è peggio di nessun ripiego.