La VPN si connette a casa ma va in timeout sul Wi-Fi dell'hotel

Il portatile si unisce al Wi-Fi di casa, il client si connette in tre secondi, e lo stesso profilo fallisce in hotel un'ora dopo. Nel frattempo non è stato aggiornato nulla. Passare in rassegna questo con un cliente davanti riguarda soprattutto sapere quale errore appartiene a quale fase, perché l'informazione utile è nel codice che il client stampa, non nel fatto che abbia fallito. Segui i quattro passi qui sotto in ordine e saprai se ti ha rifiutato un nome, un pacchetto, una porta o una regola.

Leggi il codice di errore come una fase, non come un verdetto

Il client raggiunge tre traguardi separati prima che esista un tunnel. Risolve il nome del server, ottiene una risposta da qualcosa sulla rete, e negozia un'associazione di sicurezza. Ogni traguardo ha il proprio messaggio di errore, e Windows in particolare è generoso con codici distinti una volta che sai a quale fase appartengono.

Due di quei codici significano che la rete è innocente. Un 789 significa che i pacchetti scorrevano e i due estremi non erano d'accordo sulla crittografia, che è un problema di configurazione che puoi risolvere a casa. Un 868 significa che nessun pacchetto doveva mai uscire, quindi il progetto del tunnel è irrilevante finché il nome non viene risolto. Classificare il codice nella fase giusta fa risparmiare più tempo di qualsiasi cattura, perché ti dice quale dei tre passi successivi saltare.

Sii prudentemente sfumato se il client non è Windows. I client di terze parti riducono la maggior parte di questo a "connessione non riuscita", e per questo i due passi successivi non si affidano affatto al messaggio.

Controlla il nome prima di incolpare il tunnel

Le reti di hotel e aeroporti intercettano il DNS di continuo, e un resolver che risponde con un indirizzo di portale produce un errore che sembra esattamente un server morto. Confronta ciò che dice il resolver locale con ciò che dice uno pubblico:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Se le due risposte differiscono, sei sotto dirottamento e il resto della diagnosi è sprecato finché non si risolve. Un indirizzo di portale in particolare accetterà volentieri la connessione TCP e poi si bloccherà, e per questo può sembrare un blocco del firewall quando provi con un browser.

Ora conferma che l'indirizzo che vuoi raggiungere sia quello in uso. Alcuni client mettono in cache la risoluzione precedente per tutta la vita del profilo, quindi una riconnessione dopo il cambio di DNS va ancora all'indirizzo vecchio. Chiudi completamente il client prima di riprovare, invece di premere disconnetti e connetti nella stessa finestra.

Scopri quale pacchetto esterno scompare

Il tunnel ha un flusso esterno che appartiene interamente al percorso tra te e il server, ed è quel flusso che i dispositivi intermedi classificano e scartano. Catturalo sul client, poi confronta una rete che funziona con quella che fallisce. Su Windows la cattura integrata basta per un primo sguardo:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Quello che vuoi vedere è se i tuoi pacchetti escono del tutto, e se qualcosa torna. Pacchetti in uscita senza nulla in ritorno significano che il percorso o l'estremo remoto li scarta; se non esce nulla, il client non è mai arrivato a inviare, il che riporta alla risoluzione dei nomi o a una regola locale del firewall.

Ripeti la stessa prova su un hotspot del telefono. È il confronto più informativo a tua disposizione, perché toglie dal percorso ogni scatola dell'hotel mantenendo identici portatile, client e credenziali. Se il tunnel si alza sull'hotspot, smetti di guardare il server. Se fallisce anche lì, hai un problema di client o di account che la rete non stava affatto causando.

Cambia un trasporto e riprova

Una volta che sai che il flusso esterno viene scartato, la domanda pratica è quale flusso la rete permette. La maggior parte delle reti ristrette permette TCP 443 in uscita perché altrimenti non potrebbe funzionare, quindi spostare l'ascoltatore lì è la risposta abituale. Su OpenVPN è un interruttore lato client finché il server non viene cambiato:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

I client IPsec hanno un controllo equivalente nei propri pannelli di impostazioni, di solito descritto come IPsec su TCP o attraversamento NAT. Cambiarlo è anche una diagnosi: se il tunnel si alza su TCP e muore su UDP, hai dimostrato che la rete filtra UDP, e hai anche trovato l'impostazione che ti servirà ogni volta che visiti quel sito.

Resisti alla tentazione di disattivare funzioni del router al primo tentativo. Spegnere l'ispezione con stato o la protezione dalle inondazioni su una rete d'hotel non ti è comunque possibile, e sul tuo hardware scambia una protezione reale con un solo portatile. Annota quale impostazione ha cambiato l'esito, poi rimettila e cerca un trasporto che la rete permetta già.

Verifica lo stesso profilo sulla seconda rete

Prima di chiudere il ticket, dimostra che la modifica è sopravvissuta all'uscita dall'edificio. Riconnettiti sulla rete originale con le impostazioni originali, cattura i primi trenta secondi e conferma che il client raggiunge lo stesso stato raggiunto sull'hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

La distinzione che l'ultimo comando mette in luce vale la pena di conservarla: il profilo può segnalare un tunnel connesso mentre l'instradamento al suo interno è sbagliato, e questo produce "la VPN è attiva ma non funziona nulla", che è un altro articolo. Se il tipo di tunnel è cambiato dopo la tua modifica, il profilo non è quello che hai provato.

Poi scrivi il risultato dove guarderà la persona successiva. "Il profilo aziendale richiede TCP 443 su questo sito; l'hotel filtra UDP 500" è una frase su cui un collega può agire. "La VPN è instabile negli hotel" non lo è, e garantisce che la stessa ora venga sprecata di nuovo il mese prossimo.