VPN bloccata su una rete solo web? Lavora i livelli

Una rete di campus o di hotel in cui il browser funziona e ogni tunnel muore non è un problema, sono quattro impilati. Il percorso può consentire solo TCP 443, richiedere un proxy autenticato, ispezionare la stretta di mano o semplicemente vietare l’accesso remoto per politica. Affrontarli in ordine evita di comprare un nuovo client per correggere una regola di rete. La guida qui sotto richiede una decina di minuti e termina con una risposta scritta su quale livello ti ha rifiutato.

Dimostra quale livello rifiuta la connessione

Non iniziare dal client VPN. Inizia con una richiesta HTTPS semplice allo stesso host e leggi le fasi di tempo, perché la fase che fallisce dice quale dispositivo è responsabile:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Nessuna risposta e nessun tempo connect significa che TCP non si è mai completato, quindi c’è un firewall, un requisito di proxy o una destinazione sbagliata. Un tempo connect senza tempo tls significa che qualcosa nel mezzo ha accettato la connessione e poi bloccato la stretta di mano, ed è esattamente l’aspetto di un proxy ispettore dal lato client.

Ora ispeziona il certificato che ricevi davvero. È il modo più rapido per capire se parli con il server o con una scatola intermedia che ha ri-firmato la sessione:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Leggi la riga dell’emittente. La tua CA significa che hai raggiunto il servizio; un emittente aziendale o di dispositivo significa che un filtro ha terminato la connessione e decide cosa succede dopo. Registra entrambi gli output con un timestamp, perché la stessa prova un’ora dopo sulla rete degli ospiti può dare un’altra risposta.

Un client consapevole del proxy cambia il primo pacchetto, non la politica

Se la rete richiede CONNECT tramite un proxy autenticato, bisogna dirlo al client VPN, altrimenti proverà ad aprire un socket verso un indirizzo che non può instradare. Prova il proxy separatamente dal client, così un guasto ha una sola spiegazione:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Il primo comando dimostra che il proxy porterà la destinazione. Il secondo chiede al client di usare TCP sul 443, l’unico trasporto che la maggior parte dei percorsi solo web inoltrerà. Se il primo comando riesce e il secondo fallisce ancora, il proxy non è l’ostacolo.

Alcuni client leggono il proxy del sistema operativo invece di un override, e alcuni non leggono nessuno dei due. Controlla la documentazione dell’applicazione prima di supporre che un’impostazione globale si applichi. Un client che risolve l’endpoint tramite un resolver che il proxy non serve fallirà anche qui, ed è per questo che un cambio di DNS può sembrare una soluzione quando è solo un aggiramento.

Osserva anche lo schema di pilotaggio. Una rete filtrata può rispondere al nome host di rilevamento di un fornitore con qualcosa di proprio, il che cambia quale profilo proxy sceglie il client. Non costruire un processo intorno a quella stranezza. Varia per sito, cambia senza preavviso e non è qualcosa che puoi supportare per altri.

La porta 443 è raggiungibile, non consentita

Avvolgere un tunnel in TLS sul 443 risolve la raggiungibilità e nulla più. Un filtro che controlla la porta lo lascerà passare; un filtro che prende l’impronta della stretta di mano no, e il client hello cifrato nasconde il nome del server solo quando entrambe le estremità lo supportano. Esegui la prova e scopri dietro quale tipo di filtro sei invece di sperare.

C’è anche un costo di prestazioni che la gente scopre dopo. Un trasporto affidabile dentro un trasporto affidabile amplifica la perdita, perché lo stack interno ritrasmette segmenti che lo stack esterno ha già ritrasmesso. Su un collegamento pulito nessuno se ne accorge. Su una rete wireless di campus congestionata il tunnel diventa inutilizzabile proprio quando ti serve, e il grafico sembra perdita di pacchetti anche se nulla viene scartato di proposito.

UDP è di solito la prima vittima, e vale la pena confermarlo invece di dedurlo. Se WireGuard o OpenVPN predefinito non completa mai una stretta di mano mentre TCP 443 funziona, la rete sta scartando UDP, e nessuna rigenerazione di chiavi lo cambierà:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Un timestamp di stretta di mano vuoto accanto a un peer che ieri funzionava è la risposta UDP. Le due query DNS rispondono a un’altra domanda: se il resolver locale e uno pubblico non concordano sull’indirizzo dell’endpoint, sei pilotato e l’argomento del trasporto è quello sbagliato.

Verifica cosa ha realmente lasciato la macchina

I log del client descrivono ciò che il client crede. Una cattura descrive ciò che la rete ha visto, e la differenza tra le due è dove si risolve la maggior parte di questi casi:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Se vedi pacchetti SYN e nessun SYN-ACK, il blocco è a monte e il client è innocente. Se vedi una stretta di mano completata verso un indirizzo che non è quello del server, stai parlando con un proxy o un intercettatore. Se non vedi nulla, controlla di aver catturato sull’interfaccia giusta prima di concludere qualcosa.

L’elenco dei socket coglie un caso più sottile: un secondo tunnel che detiene già la rotta predefinita. Due client che litigano per la tabella di routing producono guasti intermittenti che sembrano esattamente una rete bloccata, e la cattura mostrerà traffico che esce da un’interfaccia che non ti aspettavi.

Il ritorno indietro, e la nota che vale la pena tenere

Annulla le modifiche nell’ordine inverso a quello in cui le hai fatte. Rimuovi le variabili del proxy, ferma il client avviato a mano e togli ogni override di rotta o resolver che hai aggiunto:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Lasciare in esecuzione un client avviato a mano è il modo in cui un portatile finisce con la rete rotta alla prossima visita in ufficio. Le variabili del proxy lasciate in un profilo della shell rompono strumenti non correlati settimane dopo, e chi le depura non collegherà i due eventi.

Poi scrivi quattro righe: la rete, il timestamp, la fase che ha fallito e l’emittente che hai visto. Un percorso che funziona su un campus e fallisce sul successivo è normale, e la persona successiva deve sapere se la differenza era il proxy, il resolver o il filtro. Se la risposta è che la rete vieta l’accesso remoto, fermati lì e chiedi all’amministratore la rotta supportata invece di portare un aggiramento in una politica che non hai letto.