Perché aggiungere opt-verify non risolverà il tuo errore di cifratura OpenVPN

Trovi un suggerimento di aggiungere opt-verify, aggiungi la riga, e l’errore di cifratura resta esattamente dov’era. Quel risultato è prevedibile, perché l’opzione non ha mai negoziato una cifratura. Era un controllo di coerenza delle opzioni, deprecato nella 2.6 e rimosso nella 2.7, e un profilo che con essa viene ancora analizzato non ha per questo imposto nulla.

Aiuta sapere cosa faceva prima la riga prima di concludere che sia il pezzo mancante. La storia spiega anche perché ora non può aiutare.

Cosa imponeva prima l’opzione

Il manuale della 2.6 contrassegna opt-verify come deprecato e descrive il comportamento precedente: il server scarta i client le cui opzioni dichiarate non corrispondono alle sue, confrontando cose come il tipo di dispositivo e l’MTU. Quel controllo dipende anche dal fatto che il controllo di coerenza delle opzioni resti attivo, quindi un server che gira con disable-occ non l’ha mai avuto. Nota da cosa è costruito il confronto: testo che descrive la configurazione della controparte. Non dice nulla su quale cifratura userà il canale dati.

È il primo motivo per cui il flag non può riparare un errore di cifratura. La scelta della cifratura è regolata dalla policy data-ciphers e da ciò che entrambe le parti supportano, e un controllo testuale di coerenza non estende quell’elenco né esegue la negoziazione. Il secondo motivo è la portata: il controllo riguarda se le opzioni dichiarate sembrano compatibili, non la qualità del percorso che ne risulta.

Cosa fa la 2.7 quando vede la riga

Nella 2.7 l’opzione non c’è più. Il parser riconosce ancora il nome, ed è per questo che un vecchio profilo si carica senza errore di sintassi, e segnala che l’opzione è stata rimossa invece di ignorarla in silenzio. Riconoscere un nome e imporre un comportamento sono cose diverse, e solo la prima accade ancora. Le note di rimozione danno il motivo: una volta che i parametri sono negoziabili, due parti possono legittimamente avere stringhe di opzioni diverse pur concordando sulla connessione.

Un profilo che viene analizzato non è quindi prova che sia stato eseguito alcun controllo di ammissione. Se il tuo unico segnale è che il client si è connesso, hai imparato che la sintassi è stata accettata.

Dove vive davvero il guasto

Conserva il primo errore concreto prima di cambiare qualsiasi cosa, perché i messaggi successivi sono di solito sue conseguenze. Un guasto di negoziazione del canale dati appartiene alla policy di cifratura approvata e alle capacità che entrambe le parti annunciano realmente. Un guasto di versione o suite TLS appartiene al canale di controllo. Un rifiuto di certificato richiede l’identità e la catena di fiducia, non un flag di compatibilità.

Identifica anche il motore su entrambi i lati. Un’applicazione desktop può includere una build diversa dal binario da riga di comando con cui hai fatto la prova, e il supporto delle opzioni differisce tra loro. Consulta la documentazione di quel motore invece di presumere che ogni programma che importa un profilo si comporti allo stesso modo.

Sostituisci l’intento, non solo la riga

Se un server gestito più vecchio si affidava davvero al controllo di coerenza, annota quale vincolo imponeva prima dell’aggiornamento. Mantenere un’opzione ignorata in un profilo più recente non può preservare quella policy, e nemmeno cancellare righe indiscriminatamente.

Non rispondere a un vecchio suggerimento secondo cui tutte le cifrature sono disabilitate abilitando ogni algoritmo storico.

Dopo una correzione approvata, esamina i risultati negoziati su una nuova connessione e prova l’applicazione di cui l’utente ha davvero bisogno. Tieni la versione del server e la policy effettiva accanto a quel risultato, così la persona successiva vede cosa è stato concordato e non solo cosa è stato accettato.

L’obiettivo è un vincolo supportato e un percorso autenticato che funzioni, non un flag legacy che viene ancora analizzato.