OpenVPN sulla 443 ancora bloccato? Guarda cosa ispeziona la rete

Il tunnel si connette da una linea domestica e si blocca su una rete d’albergo o d’ufficio, e spostare il server sulla porta 443 non ha cambiato nulla. Quel risultato è abbastanza comune da avere una forma: la porta era la parte facile, e il resto della decisione appartiene a tutto ciò che sta tra il client e il server. Due domande risolvono la maggior parte dei casi, e nessuna delle due riguarda i cifrari. La rete accetta un handshake TLS verso quell’indirizzo, e il client mantiene una rotta verso il proprio wrapper mentre il tunnel è attivo?

L’handshake rivela più del numero

Un listener VPN nativo su TCP 443 parla il proprio protocollo fin dal primo pacchetto. Un ClientHello ha un campo di versione, un valore casuale e un elenco di estensioni, e un dispositivo che legge qualche centinaio di byte nota la differenza senza decifrare nulla. I numeri di porta sono economici da soddisfare, ed è la forma del protocollo che il filtro controlla davvero. Le regole di solito si scrivono anche per protocollo, quindi una politica che ispeziona TLS non dice nulla su UDP.

Un proxy trasparente che pretende una sessione TLS valida interrompe la connessione durante la configurazione, spesso dopo che l’handshake TCP è completato. Quel dettaglio conta più avanti, perché significa che il registro del client si ferma dopo che il socket è stabilito.

Incapsulare il flusso crea due punti di guasto

Un wrapper TLS come stunnel ripristina la forma attesa: il client si connette a un listener locale, il wrapper apre una sessione TLS reale verso il server sulla 443, e un secondo wrapper sul server inoltra i byte decifrati al demone VPN. La sessione esterna ora sembra qualsiasi altra connessione HTTPS. Il demone VPN sul server dovrebbe ascoltare solo su loopback, perché nulla fuori dal wrapper deve raggiungerlo.

Tre cose distinte devono allinearsi per quel progetto. Il profilo del client punta al listener locale, il certificato del server corrisponde al nome che il client verifica, e l’inoltro lato server punta alla porta che il demone usa davvero. Sbaglia una sola di queste e la connessione muore prima di raggiungere il livello VPN. Una discrepanza di certificato appare allora come errore del wrapper e non come errore VPN, ed è per questo che vale la pena leggere entrambi i registri fianco a fianco.

La rotta verso il wrapper è la trappola

Quando il tunnel sale, la rotta predefinita punta dentro, e la sessione TLS esterna ha bisogno di un percorso che non entri nel tunnel che trasporta. Un client VPN normale protegge l’indirizzo che chiama; un client incapsulato chiama il proprio loopback, quindi l’indirizzo di destinazione del wrapper è invisibile a quella protezione.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Gli indirizzi esatti li compili tu, e la rotta deve esistere per tutta la vita della connessione, non solo all’avvio. Un piccolo script wrapper che aggiunge la rotta prima del client e la rimuove dopo è più affidabile di un comando ricordato.

Su Android, l’equivalente di quell’eccezione è un’impostazione per app: escludi l’applicazione wrapper dal tunnel così che il suo traffico esca dalla connessione mobile. Senza l’esclusione il wrapper viene instradato nel tunnel che sta cercando di costruire, e il ciclo di riconnessione sembra un problema del server.

Leggi i tempi prima di cambiare qualcosa

Una sessione che muore dopo lo stesso intervallo ogni volta è una firma di politica e non un guasto crittografico, e i limiti di flusso di lunga durata producono esattamente quel modello. Una connessione che si resetta subito dopo l’handshake suggerisce un proxy a cui non è piaciuta la catena di certificati.

Confronta l’emittente del certificato di un normale sito HTTPS dalle due reti. Se l’emittente differisce sulla rete limitata, qualcosa sta terminando TLS nel mezzo, e nessun wrapper sopravviverà a quell’intercettazione senza modifiche. Lo stesso confronto ti dice se il blocco punta al nome del tuo server o a ogni sessione TLS su quell’indirizzo.

Annota il comportamento osservato: quanto è durata la sessione, se il socket si è aperto, se il wrapper ha registrato un handshake. Ognuno di questi elementi restringe il test successivo.

Prova una variabile alla volta

Controlla prima UDP, perché alcune reti lo scartano del tutto e un guasto UDP non dice nulla sulla 443. Poi prova TCP 443 senza il wrapper, quindi il wrapper sulla 443. Leggi il registro del client a ogni passo e fermati appena il comportamento cambia.

Cambia un elemento per tentativo. Una porta nuova, un wrapper nuovo e un cifrario nuovo nella stessa prova non ti lasciano dire quale dei tre contasse.