La configurazione VPN pubblica ha smesso di funzionare? Leggi la fase di guasto

Il profilo funzionava martedì, e venerdì il client gira per trenta secondi e si arrende. Nulla è cambiato sulla tua macchina. È esattamente questo il punto: una configurazione scaricata descrive un host in un istante, e l’operatore dall’altra parte non ha alcun obbligo di mantenere vera quella descrizione. La tentazione è iniziare a modificare le impostazioni di sicurezza finché il tunnel non torna su. È proprio quell’istinto a portare le persone a eseguire un profilo con la verifica dei certificati disattivata, cosa peggiore che non avere alcun tunnel.

Il file descrive un istante, non un contratto

Un file di configurazione è un insieme di asserzioni: questo nome host ascolta su questa porta con questo protocollo, presenta un certificato che corrisponde a questo nome e accetta queste credenziali. Quando una di esse smette di essere vera, il file è obsoleto e la correzione appartiene al lato operatore del confine, non alle tue impostazioni.

Gli elenchi di nodi pubblici lo rendono esplicito per loro natura. I nodi sono gestiti da volontari, compaiono e scompaiono, gli indirizzi vengono riciclati e le porte vengono bloccate dalla rete dietro cui si trovano. L’elenco è un’istantanea che viene rigenerata, e la copia sul tuo disco è una fotografia di un’istantanea più vecchia.

I servizi commerciali cambiano più lentamente, ma non mai. Le autorità di certificazione ruotano, un listener passa da un indirizzo condiviso a uno dedicato, un vecchio protocollo viene ritirato e arriva una nuova lista di cifrari. Ognuno di questi cambiamenti è invisibile finché il tuo client non prova a connettersi e riceve una risposta diversa da quella che il file si aspetta.

Leggi la fase di guasto prima di toccare un’impostazione

Il messaggio di errore dice quale asserzione è caduta, e ogni asserzione ha una riparazione completamente diversa. Modificare i cifrari quando il nome host non risolve più fa perdere un pomeriggio e non insegna nulla a nessuno.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

La riga centrale separa un percorso bloccato da una stretta di mano rotta, e la terza mostra l’emittente e le date di validità del certificato effettivamente presentato. Se quell’emittente non è quello che il profilo ha fissato, il certificato è cambiato, e nessuna opzione lato client renderà di nuovo corretto il vecchio fissaggio.

I cambi di certificato e di identità sono quelli silenziosi

La maggior parte dei guasti si annuncia. I cambi di identità no, perché un client che fissa un nome di certificato rifiuterà un certificato nuovo perfettamente valido con un messaggio che molti leggono come un bug. Il tunnel è a posto. Il fissaggio è obsoleto.

Cerca le opzioni di identità prima di concludere qualcosa:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Se il profilo porta una CA incorporata e l’operatore è passato a una nuova autorità, il vecchio file non può validare il nuovo server. Sostituire il blocco CA con quello pubblicato dall’operatore è una riparazione legittima. Cancellare la direttiva di verifica non lo è, e sono le stesse battute di tasti con un esito molto diverso.

Un aggiornamento del client può produrre lo stesso sintomo senza alcun cambiamento dell’operatore. Opzioni che erano tollerate in silenzio ora vengono rifiutate, oppure un protocollo obsoleto viene rimosso. È un limite di compatibilità del tuo software, e vale la pena provare un secondo profilo con lo stesso client prima di dare la colpa al server.

Solo l’operatore può pubblicare un sostituto valido

Quando un nodo scompare, il sostituto deve arrivare dalla stessa fonte che ha pubblicato l’originale. Un profilo che arriva in un messaggio diretto perché «usa lo stesso nome del server» è una configurazione non verificata di una parte sconosciuta, e importarlo dà a quella parte il controllo del tuo instradamento.

Il controllo costa poco. Scarica il file attuale dalla posizione pubblicata, confronta l’endpoint e il protocollo con l’elenco e conferma l’impronta del materiale CA invece di fidarti del nome del file:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Se i due hash differiscono solo negli spazi, hai un cambio di formattazione. Se differiscono negli endpoint, l’operatore ha spostato qualcosa e il file pubblicato è l’autorità. Se il file pubblicato è più vecchio di quello che hai, probabilmente stai guardando una cache, e la risposta obsoleta ti manderà nella direzione sbagliata.

Ritira la voce vecchia e annota cosa è successo

Una volta verificato un sostituto funzionante, elimina il vecchio profilo invece di tenerlo come riserva. Una voce obsoleta che si connette a metà è una trappola: verrà scelta durante un’interruzione, fallirà lentamente, e chi fa debug passerà i primi dieci minuti sul file sbagliato.

Tieni un registro breve fuori dalla configurazione: la data, l’endpoint vecchio, la fase di guasto e cosa lo ha sostituito. I nodi pubblici cambiano, e sei settimane dopo la stessa domanda arriva con un’altra persona. Una riga in un file di note la risolve in pochi secondi.

Se da una rete tutti i nodi falliscono allo stesso modo e da un’altra nessuno, smetti di modificare profili e guarda il percorso locale. Un portale captive, un intervallo di porte filtrato o un proxy che intercetta produrranno errori identici presso fornitori non correlati, e quello schema è l’unico segnale che il problema non è mai stato il file.