VPN connessa ma senza internet? Controlla i quattro livelli

Il client dice connesso, il browser gira e ogni sito finisce in un timeout. Questa combinazione è comune e non è una contraddizione: connesso significa che il tunnel ha negoziato, e niente di più. Risoluzione dei nomi, instradamento e uscita del server stesso falliscono ciascuno a modo proprio, e ciascuno ha un responsabile diverso. Percorri i livelli in ordine e fermati al primo che fallisce.

Parti dalla rete da cui vieni

Chiudi il tunnel con il comando di disconnessione del client, poi prova due siti HTTPS non correlati se la policy lo consente. Lascia chiuso il lavoro sensibile per la durata del test. Se anche l’accesso normale fallisce, la VPN non è il primo sospetto.

Guarda il collegamento Wi-Fi, il router e qualsiasi pagina di portale che richieda l’accesso prima di toccare il tunnel. Un kill switch può bloccare il traffico da disconnessi per progetto, quindi segui la sua procedura di test documentata invece di concludere che la rete è morta. Un’altra rete fidata è un confronto utile, e una nuova uscita VPN non completerà un accesso hotel scaduto. Se la rete aperta funziona e il tunnel no, la rete è scagionata e il livello successivo è tuo.

Stabilisci se il guasto è la risoluzione dei nomi

Annota il testo dell’errore, perché un guasto di risoluzione, un timeout e un avviso di certificato puntano ciascuno altrove. Lo schema da cogliere presto è un nome host mai visitato che fallisce mentre un’applicazione con sessione aperta continua. Quello schema riguarda le nuove richieste, non se il tunnel trasporta pacchetti. Una singola richiesta mostra cosa restituisce il resolver, e richiede un secondo. Prova anche un secondo nome, così una risposta in cache o un record rotto non decidono la diagnosi.

nslookup example.com

Un IP arbitrario nella barra degli indirizzi HTTPS non è un test DNS, perché certificato e host virtuale di solito dipendono dal nome. I nomi interni possono richiedere il resolver dell’organizzazione invece di un sostituto pubblico, e un browser con un proprio resolver sicuro può rispondere diversamente dalla richiesta del sistema operativo. Dove i due divergono, il resolver del browser è quello che l’utente vive, e quella distinzione appartiene al ticket.

Tunnel completo o solo sottoreti aziendali

Alcuni profili esistono solo per raggiungere una manciata di sottoreti aziendali; altri sono costruiti per trasportare tutto e hanno bisogno di un’uscita funzionante dietro. Leggi lo scopo documentato prima di presumere che l’indicatore copra ogni applicazione e ogni famiglia di indirizzi. Un profilo di rete privata può funzionare esattamente come progettato mentre il browser, che non avrebbe mai dovuto usarlo, continua a fallire. Leggi la tabella di routing senza modificarla, e includi IPv6, perché un percorso IPv4 funzionante non dice nulla dell’altra famiglia.

Una rotta più specifica può vincere mentre la rotta predefinita esiste ancora, per questo la tabella va letta e non presunta. Adattatori virtuali concorrenti possono possedere traffico che ti aspettavi altrove, soprattutto dopo che un secondo client VPN è stato installato e dimenticato. Non cancellare la rotta predefinita come esperimento; trasforma una diagnosi in un secondo disservizio.

Un solo sito che fallisce tra quelli che funzionano è un problema di quel sito, e dimostra anche che il tunnel trasporta traffico. Gli stalli che compaiono solo nei trasferimenti grandi indicano la dimensione dei pacchetti, non la raggiungibilità.

Quando il server non inoltra mai nulla

Se ogni destinazione fallisce su due dispositivi e due reti di accesso, il tunnel è attivo e l’uscita non inoltra. È quell’accoppiata a separare un guasto lato server da un dispositivo mal configurato in un solo punto. Invia all’operatore le domande su inoltro, NAT e percorso di ritorno, non uno screenshot dell’indicatore.

Quei tre coprono la maggior parte delle cause lato server, e tocca all’operatore rispondere. La pagina di risoluzione dei problemi di connettività di OpenVPN percorre le stesse domande dal lato server, quindi passala insieme al ticket. Uno screenshot di un indicatore verde non risponde a nessuna.

Esamina il log del client dopo l’accesso per errori nell’applicazione di rotte, impostazioni DNS o dell’adattatore virtuale. Gli errori in quella fase indicano il dispositivo, non il server. Un errore che non compare mai nel log è altrettanto informativo, perché sposta il sospetto dall’altra parte.

Controlla un livello alla volta

Dopo aver cambiato qualcosa, riconnettiti e ripeti esattamente l’applicazione che ha fallito. Una singola pagina che carica dimostra meno di un percorso ripetibile verso le risorse per cui il profilo è stato costruito. Due comandi separano la risoluzione dalla raggiungibilità, e il secondo dipende dall’host. Esegui la riga curl ovunque, poi il comando di routing che corrisponde all’host davanti a te.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Se la richiesta numerica funziona e il nome no, resta sul DNS. Se nessuna delle due funziona, confronta la tabella di routing con il valore predefinito atteso del tunnel e controlla la famiglia che stai davvero testando. Se la rotta è corretta e la richiesta muore ancora all’uscita, la domanda restante è dell’operatore, e le prove che hai conservato sono il ticket.