Un vecchio profilo .ovpn fallisce su Ubuntu 24.04: quali righe eliminare

Il profilo viene scaricato, importato e poi si ferma alla riga 12 del file con un messaggio Unrecognized option che nomina keysize. Nulla dell'account è cambiato e il server continua ad accettare altri client. È cambiato il client stesso: Ubuntu 24.04 installa OpenVPN 2.6, mentre l'esportazione è stata scritta per la 2.4. La riparazione è una breve serie di eliminazioni, e l'ordine conta perché ogni opzione obsoleta interrompe l'analisi prima ancora che la successiva venga letta.

Leggi la riga dell'errore prima di toccare il file

OpenVPN nomina il file e la riga in cui l'analisi si è fermata, quindi puoi correggere un solo problema per esecuzione. Avvia il profilo da un terminale invece che da un'applet desktop, perché l'applet di solito inghiotte stderr e il numero di riga è l'unico indizio affidabile che ottieni: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Correggi quella riga, esegui di nuovo e aspettati che il prossimo errore nomini un'opzione diversa.

Un errore di analisi compare sempre prima di qualsiasi handshake TLS, quindi un messaggio che menziona un certificato ha già superato la fase sintattica. Questa distinzione ti evita di modificare un file che fallisce solo all'autenticazione. Leggi la prima parola del messaggio, non la sua metà.

Tre classi di errore, tre riparazioni diverse

Le vecchie esportazioni falliscono in tre modi distinguibili, ed è proprio il fonderle in un unico problema a spingere le persone a reinstallare pacchetti che non erano mai stati guasti. La formulazione del messaggio ti dice in quale classe ti trovi prima di aprire il file.

• Gli errori di analisi nominano un file e una riga, e si fermano prima che esista traffico.
• Gli errori di negoziazione si connettono, poi segnalano che i due estremi non sono riusciti a concordare una cifratura comune o un canale dati accettabile.
• Gli errori di autenticazione arrivano più lontano e nominano un certificato, un utente o una credenziale rifiutata.

Modificare il profilo corregge solo la prima classe. La negoziazione richiede una decisione a entrambi gli estremi del tunnel, e una credenziale rifiutata non è affatto un problema di sintassi. Se il tuo messaggio menziona una cifratura comune o un canale dati, le eliminazioni qui sotto non cambieranno nulla.

Elimina le opzioni che la 2.6 ha rimosso, in questo ordine

Ognuna di queste righe ferma l'analisi da sola, quindi il client le segnala una alla volta. Scorri l'elenco e riesegui dopo ogni eliminazione.

Elimina prima keysize, perché non ha un equivalente moderno e la sua presenza di solito segnala una cifratura che il client attuale rifiuta comunque. Poi elimina ncp-disable, che controllava la negoziazione delle cifrature, è diventato obsoleto nella 2.5 ed è sparito nella 2.6. Sostituisci ns-cert-type server con remote-cert-tls server, che esprime la stessa intenzione tramite un controllo supportato. La cronologia delle modifiche 2.6 elenca le rimozioni rimanenti accanto alle loro sostituzioni, quindi tutto ciò che il parser rifiuta ancora ha una risposta documentata.

Conserva una copia del profilo originale prima della prima modifica. I provider rigenerano le esportazioni, e un diff contro il file intatto è il modo più rapido per separare le tue modifiche dalle loro. Se un'eliminazione lascia partire il client ma il tunnel fallisce ancora, sei passato alla classe della negoziazione e le righe rimanenti non sono la causa. Metti la versione del client nel nome del file così la prossima persona sa a quale rilascio puntano le modifiche.

Mantieni BF-CBC solo come fallback circoscritto

Alcuni provider terminano ancora su BF-CBC, che OpenVPN 2.6 non negozierà senza aiuto perché la cifratura ha un blocco di 64 bit. La riparazione ristretta è una lista di fallback più il provider legacy di OpenSSL, non un declassamento dell'intero client.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

La prima riga carica il provider legacy così OpenSSL può ancora istanziare quella cifratura, la seconda conserva la negoziazione moderna per i peer che la supportano, e la terza si applica solo quando il server non offre nulla di meglio. È un indebolimento deliberato del tunnel, quindi annota accanto al file perché esiste. Chiedi al provider anche un'esportazione rigenerata, perché il fallback è un ponte e non una destinazione.

Non ricorrere a --compat-mode come risposta universale. Cambia diversi comportamenti insieme, comprese le impostazioni predefinite di negoziazione e rinegoziazione, quindi non scoprirai mai quale modifica è stata decisiva. Preferisci le tre righe esplicite qui sopra, perché ciascuna dichiara il proprio effetto.

Verifica con il profilo che il client carica davvero

Le connessioni importate vengono spesso copiate in una directory di sistema, quindi modificare il file nella cartella dei download può non cambiare assolutamente nulla. Trova la copia che viene eseguita: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Poi avvia il tunnel e leggi la riga di log che riporta quale cifratura del canale dati è stata scelta davvero. Una connessione che completa l'handshake sul fallback ti dice che il server non ha mai offerto nulla di moderno.

Prova da una rete che non è quella attesa dal provider, così un portale captive o una rete ospiti filtrata non si mascherano da guasto del profilo. Annota la versione del client accanto a ogni richiesta di assistenza.

Una volta che il tunnel è attivo, invia una richiesta che deve attraversarlo e una che non deve, poi conferma che la risposta del resolver è cambiata come previsto. Se il profilo ora viene analizzato ma la connessione fallisce ancora, hai lasciato alle spalle il problema di sintassi e il testo dell'errore nominerà la nuova classe. Tieni il file modificato sotto controllo di versione accanto a una nota che nomina la versione di OpenVPN a cui punta.