La lista VPN pubblica dice online; il tuo client dice di no

Apri la directory, ordini per velocità, scegli un nodo contrassegnato come online, e il client si arrende prima di finire di connettersi. La lista non mentiva, esattamente. Riportava il risultato della sonda di qualcun altro, da un’altra rete, in un momento precedente, contro un servizio che un volontario può spegnere in qualsiasi momento. Capire quel divario trasforma una caccia frustrante in una breve sequenza di controlli che puoi eseguire su qualsiasi candidato.

Che cosa ha misurato davvero la lista

Una directory pubblica conserva campi come l’ora dell’ultimo controllo, un valore osservato di tempo di andata e ritorno, un conteggio delle sessioni e talvolta una lista di protocolli. Ognuno di essi descrive l’ultima osservazione riuscita dal punto di vista del progetto stesso, non lo stato del nodo quando arriva il tuo pacchetto.

La freschezza conta più del numero. Un nodo controllato quattro minuti fa e un nodo controllato quattro ore fa possono mostrare lo stesso marcatore verde, e solo uno dei due assomiglia ancora allo stato registrato. Cerca la marca temporale, non il colore.

L’esercizio volontario aggiunge una seconda fonte di cambiamento che nessun monitor può correggere. L’operatore sta magari riavviando un portatile, esaurendo la larghezza di banda, cambiando provider o semplicemente chiudendo il coperchio. Una voce della lista è un candidato, e trattarla come un accordo sul livello di servizio è un errore di categoria.

Guarda le fasi del client, non l’indicatore rotante

Ogni client VPN passa attraverso la stessa ampia sequenza: risolvere il nome, aprire una connessione di trasporto, negoziare la sicurezza, autenticarsi, poi configurare il tunnel e trasferire i dati. Un guasto a ogni fase lascia prove diverse, e l’indicatore rotante non ne mostra nessuna.

Inizia dalla risoluzione del nome. Se il nome host non si risolve, non è stato testato nulla sulla disponibilità del nodo, perché la connessione non ha mai lasciato la tua macchina. Poi il trasporto: uno scambio TCP o UDP rifiutato o scaduto ti dice che l’endpoint non risponde su quella porta, il che è un riscontro reale sul nodo. Poi negoziazione e autenticazione, dove un certificato sbagliato, un profilo scaduto o un cifrario non corrispondente falliscono mentre il nodo è perfettamente sano. Solo dopo aver configurato il tunnel un guasto di routing o DNS può spiegare l’ultimo passaggio.

Leggi il log del client con la massima verbosità che entra ancora nello schermo, e annota l’ultima riga che ha avuto successo. Quella riga è dove inizia la diagnosi, ed è di solito più informativa di qualsiasi cosa mostri la directory.

Una variabile per tentativo

Confronta i candidati con lo stesso client, la stessa rete di accesso e lo stesso formato di profilo, cambiando solo l’endpoint. Altrimenti un guasto potrebbe essere tuo e lo attribuiresti al nodo.

Due tentativi bastano a stabilire uno schema, e un terzo lo conferma. Se il nodo A fallisce alla fase di trasporto e il nodo B all’autenticazione, hai due problemi non correlati invece di una lista obsoleta.

Quando ogni nodo fallisce allo stesso modo

Un guasto universale alla prima fase punta al tuo lato: un resolver che non può rispondere, un firewall locale che blocca il protocollo o una rete che consente solo il traffico web. La directory non può segnalarlo, perché le sue sonde non partono dal tuo posto.

Prova deliberatamente il caso della rete modellata. Alcune reti di accesso consentono HTTPS verso il web e scartano altri protocolli, il che fa sembrare morto ogni candidato mentre la lista è accurata. Confrontare il caricamento di una pagina nel browser con un tentativo di connessione grezzo separa queste due situazioni in meno di un minuto.

Leggi il guasto alla fase in cui è avvenuto

Riproduci il tentativo da un terminale così che le fasi siano visibili. I tre comandi qui sotto risolvono il nome, verificano se la porta risponde e stampano le righe di negoziazione di un profilo OpenVPN:

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

Se la porta risponde e la riga di negoziazione segnala un problema di certificato, il nodo è attivo e il tuo profilo è scaduto. Se la porta non risponde affatto, la voce è un candidato fallito, e passare al successivo è la risposta giusta invece di fare debug del client. Annota la fase in una riga breve, e il prossimo tentativo parte dalla conoscenza invece che dalla speranza.