Timeout della connessione VPN: DNS, trasporto, negoziazione o accesso

«La connessione è scaduta» è l'errore meno specifico che un client VPN possa stampare. Significa che un'operazione ha mancato la sua scadenza, e ogni fase, dalla risoluzione del nome alla risposta di accesso, ha una scadenza. I client che mostrano solo il messaggio finale fanno sembrare le fasi identiche, così le persone alzano il timeout, cambiano la porta e reinstallano il profilo, in quest'ordine, senza imparare nulla. Confrontare le fasi è più veloce: ciascuna fallisce in un punto diverso, e ogni guasto lascia un tipo diverso di prova.

Quattro fasi, quattro guasti diversi

La sequenza è fissa anche quando il client la nasconde: il nome va risolto, va stabilito un trasporto verso l'indirizzo risultante, il protocollo deve negoziare i suoi parametri e le chiavi, e l'account deve essere autenticato. La guida alla risoluzione dei problemi di connettività di OpenVPN segue lo stesso ordine per il proprio client, e gli altri la seguono da vicino. Un timeout alla seconda fase e uno alla quarta non hanno nulla in comune se non la parola sullo schermo.

Leggi il registro cercando l'ultima riga che indica progresso, non l'ultima riga prima dell'errore. La maggior parte dei client stampa qualcosa come un indirizzo risolto, un socket stabilito, un handshake avviato o una richiesta di autenticazione, e la fase che segue quella riga è quella scaduta.

La risoluzione del nome fallisce prima di qualsiasi contatto

Se l'endpoint non viene mai risolto, il client non ha nulla a cui connettersi e non è avvenuto alcun lavoro di trasporto. Quel guasto è di solito istantaneo anziché un timeout completo, ed è il modo più economico per distinguerlo dal resto. Prova il nome con il resolver di sistema e con un secondo resolver, e confronta le due risposte prima di concludere che il server è giù.

Un vecchio indirizzo copiato da un post del forum è una causa comune di timeout che sembra un problema del server, perché ora l'indirizzo appartiene a qualcos'altro o a niente. Usa il profilo attuale dell'operatore invece di sostituire un indirizzo che funzionava prima. L'assenza di risposta al ping non è prova in nessuna direzione: molti endpoint scartano ICMP pur servendo perfettamente.

La configurazione del trasporto attende un pacchetto che non arriverà

Quando il DNS è a posto e il client brucia comunque tutto il timeout, lo strato di trasporto è il sospetto. Su TCP puoi testare la porta direttamente; Test-NetConnection su Windows o nc -vz su Linux ti dice se qualcosa accetta la connessione, ed è più utile di un ping. Su UDP non puoi testare allo stesso modo, perché su quello strato non c'è handshake da completare, e questa asimmetria provoca molte conclusioni sbagliate.

Ciò che un test TCP dimostra è limitato: un servizio che accetta la porta 443 non è necessariamente l'ascoltatore VPN, e un endpoint solo UDP non ha alcuna porta TCP per accettare qualcosa. Riscrivere un profilo da UDP a TCP non crea un ascoltatore dall'altra parte; cambia solo ciò che il tuo client attende. Se la rete filtra il protocollo, la modifica produce un timeout diverso nella stessa fase.

I portali captive meritano un controllo proprio in questa fase. Finché il portale non autorizza il dispositivo, il traffico in uscita va al portale e il tentativo di tunnel resta semplicemente appeso. Completa prima il portale nel browser, poi riprova, e non cambiare il profilo mentre il portale è ancora in sospeso.

Negoziazione e accesso significano che il server ha risposto

Una volta che il tunnel raggiunge il server, il client avvia un handshake e l'errore cambia natura. Un blocco qui riguarda la compatibilità, non la raggiungibilità: versioni di protocollo non corrispondenti, un'impostazione di cifratura o del canale dati che l'altra parte non accetterà, o un profilo che si aspetta una funzione che il server non offre. OpenVPN ha spostato i suoi valori predefiniti di negoziazione tra versioni principali abbastanza spesso che un profilo scritto per una generazione può raggiungere il server e comunque non salire.

L'autenticazione è l'ultima fase e la più facile da leggere male. Un rifiuto esplicito è una risposta, il che significa che il percorso funziona e il problema è l'identità, il certificato o lo stato dell'account. Un flusso di accesso unico basato su browser è un terzo caso: il client attende un'azione che non hai fatto, o un browser che non riesce ad avviare, e non arriverà nulla finché non completi quel passaggio.

Confronta le prove prima di cambiare il nuovo tentativo

Tieni fissi dispositivo e profilo e cambia una cosa alla volta, iniziando dalla rete. Se lo stesso profilo si connette con un hotspot del telefono e scade sul Wi-Fi dell'hotel, la variabile è il percorso, non il server. Se fallisce ovunque, la variabile è il profilo o l'endpoint. Se fallisce solo a una certa ora del giorno, registra il timestamp e confrontalo con gli eventi lato server prima di supporre qualcosa sul carico.

Per un servizio che amministri, il confronto decisivo è se il tentativo arriva davvero. Una connessione che raggiunge l'ascoltatore e poi si blocca appartiene alla fase di negoziazione; una che non compare mai nella vista dell'ascoltatore è un problema di trasporto o di risoluzione, e nessun ritocco dei tentativi la sposterà. I log del server separano anche un accesso rifiutato da una caduta silenziosa, che è la differenza tra una correzione di identità e una di firewall.

Annota la versione del client, il nome del profilo, l'ora del tentativo con il suo fuso orario e il primo errore utile invece dell'ultima riga di disconnessione. Rimuovi chiavi e materiale con credenziali prima di condividere l'estratto. Poi fai una correzione significativa e riprova, perché una scadenza più lunga aiuta solo l'operazione lenta documentata e non fa nulla per un indirizzo sbagliato o una porta bloccata.