Perché OpenVPN ha smesso di connettersi dopo un aggiornamento di Ubuntu?

I profili VPN che funzionavano la settimana scorsa si rompono dopo un aggiornamento di versione di Ubuntu, e il registro raramente menziona l'aggiornamento. Ciò che nomina è lo strato che ha fallito: la stretta di mano TLS, la cifratura negoziata per il canale dati, il pacchetto installato o la copia di OpenSSL che il binario carica all'avvio. Ogni strato ha la sua forma d'errore e la sua riparazione, per cui la classificazione è il primo lavoro e la modifica il secondo. Tratta il profilo come innocente finché il registro non lo nomina.

Quale strato ha fallito: stretta di mano, cifratura, pacchetto o libreria

Leggi il registro del client prima di toccare il profilo. Il primo errore nell'output è quello che identifica lo strato; tutto ciò che viene stampato dopo è di solito la conseguenza di quel primo fallimento. Quando il client non parte affatto, il registro VPN è il file sbagliato da aprire.

Le lamentele su certificati e firme, o un messaggio sulla lunghezza della chiave, vengono dal canale di controllo e dalla politica della libreria che lo governa. Un avviso che inizia con DEPRECATED OPTION appartiene invece alla negoziazione del canale dati.

Una riga come Unrecognized option è una terza categoria: il nuovo binario non accetta più una direttiva che il vecchio tollerava, quindi va riscritto il profilo, non allentata la libreria. I guasti di pacchetto sembrano ancora diversi perché avvengono prima che giri qualsiasi codice del tunnel. Un binario mancante, un plugin che non si carica o un repository che punta al nome in codice sbagliato producono tutti quella forma. Quattro sintomi, quattro posti da guardare e quasi nessuna sovrapposizione fra le riparazioni.

Quando la stretta di mano fallisce, la politica TLS rifiuta il certificato

Ubuntu 22.04 ha portato il sistema a OpenSSL 3, e il livello di sicurezza predefinito di quel ramo è più severo sulle firme dei certificati e sulle dimensioni delle chiavi di quanto fosse 20.04. Un certificato CA firmato con un digest più vecchio, o una chiave sotto la soglia attuale, ora falliscono durante la stretta di mano. Poiché nulla è ancora autenticato, l'errore si legge come una password sbagliata o un server morto.

La riparazione stretta allega una stringa di cifratura solo a questa connessione. Nell'editor desktop, apri il profilo, vai alle impostazioni avanzate e metti DEFAULT:@SECLEVEL=0 nel campo della cifratura TLS. Il file di chiavi di NetworkManager prende lo stesso valore sotto [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Riavvia NetworkManager e riconnettiti, perché il demone memorizza nella cache i profili analizzati e altrimenti continuerebbe a usare la copia che già possiede. Sappi cosa fa la riga prima di tenerla: quell'impostazione è una soglia su diversi parametri di certificati e chiavi, non un nome di cifratura, quindi abbassarla allarga ciò che il singolo profilo accetta. Annota quale server l'ha richiesta e togli l'impostazione quando l'operatore riemette materiale aggiornato. Modificare /etc/ssl/openssl.cnf raggiunge la stessa soglia per ogni programma che legge quel file, ben oltre la VPN.

OpenVPN 2.6 richiede la cifratura elencata per la negoziazione

Ubuntu 22.10 ha introdotto OpenVPN 2.6, e in quella versione --cipher smette di scegliere da solo il canale dati. La cifratura deve essere presente anche nella lista data-ciphers negoziata, altrimenti il client stampa un avviso di obsolescenza e poi non riesce ad alzare il tunnel.

Il plugin di NetworkManager dello stesso periodo scriveva ancora solo la vecchia direttiva. Questo dettaglio divide la diagnosi, perché un profilo corretto a mano può connettersi da una shell e continuare a fallire dall'applet del desktop. Aggiungi la lista al file di connessione sotto [vpn]:

data-ciphers=AES-256-CBC

Usa il valore annunciato dal server, non quello che ricordi; un server che offre AES-256-GCM non negozierà con una lista client che nomina solo CBC. Riavvia il gestore e riconnettiti, poi ripeti il tentativo da una shell con la cifratura passata esplicitamente sia per la negoziazione sia per il fallback:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Se quel comando alza il tunnel, il server, i certificati e le credenziali sono tutti sani, e l'unico difetto rimasto è l'opzione salvata del gestore. Un avviso sulla direttiva keysize appartiene alla stessa pulizia: commentalo e conserva il file originale accanto al profilo.

I guasti di pacchetti e plugin sembrano guasti VPN

Non ogni fallimento dopo l'aggiornamento è crittografico. Un repository OpenVPN aggiunto sotto un nome in codice che la versione non usa produce un pacchetto che non si installa mai, quindi confronta ciò che lsb_release -a riporta con il file di elenco che hai aggiunto. Un componente universe mancante o una tasca di sicurezza producono un pacchetto che non si trova affatto. Entrambi i casi lasciano il profilo intatto e il tunnel impossibile.

Leggi l'errore del gestore di pacchetti prima del registro VPN. Se il client non è mai stato installato, nessuna modifica al profilo produrrà una stretta di mano.

I profili a due fattori che smettono di chiedere sono la versione plugin della stessa storia. La sfida viene da un plugin di autenticazione, e un aggiornamento che lo ha rimosso o sostituito lascia il profilo intatto mentre la richiesta sparisce. Reinstalla il plugin supportato invece di cancellare il secondo fattore per far funzionare la connessione.

Una libreria del fornitore può nascondersi dietro un errore di politica

Un pattern merita riconoscimento perché sconfigge ogni riparazione di politica. Uno strumento di configurazione di un fornitore hardware può installare le proprie librerie OpenSSL e collocarle davanti alle copie di sistema nel percorso di ricerca del loader. Il client parte allora contro una libreria che nessuno ha aggiornato, e il fallimento all'avvio sembra esattamente un certificato rifiutato.

Reinstallare il pacchetto VPN non cambia quale libreria venga trovata per prima, e abbassare il livello TLS non raggiunge una libreria che non è mai venuta dal sistema. Chiedi al loader quali oggetti crittografici risolve davvero il binario:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Rimuovi o reindirizza la copia del fornitore, poi esegui di nuovo lo stesso controllo. La versione attesa deve essere quella in uso prima di tornare al profilo.

Fissare un client più vecchio compra tempo, non una soluzione

Mantenere la versione precedente del client ripristina il tunnel finché dura la trattenuta. Blocca anche gli aggiornamenti di sicurezza di quel pacchetto e programma la stessa rottura per l'aggiornamento successivo, quindi trattalo come un aggiramento datato, non come una risoluzione.

Se lo fissi comunque, trattieni il pacchetto esplicitamente perché un aggiornamento non sorvegliato non possa annullare il fissaggio, annota il motivo e la data per riesaminarlo, e imposta un promemoria per la prossima versione del profilo del fornitore. La condizione da tenere d'occhio è un profilo server che negozia una cifratura attuale; una volta che esiste, il fissaggio non ha più giustificazione. Un fissaggio non registrato, invece, diventa un'interruzione che nessuno sa spiegare sei mesi dopo, perché chi l'ha applicato se n'è andato e il file non registra nulla.

La prossima volta che una VPN muore dopo un aggiornamento di versione, poni cinque domande in ordine: quale strato ha prodotto il primo errore, la politica TLS ha rifiutato il certificato, la cifratura è negoziabile in entrambe le direzioni, il pacchetto e il suo plugin si sono davvero installati, e quale libreria carica il processo. Solo quando tutte e cinque tornano pulite un downgrade ha senso.