AES-256-GCM non trovato: capacità del client o negoziazione?

Un profilo OpenVPN che funziona altrove segnala che AES-256-GCM non viene trovato, o che i peer non condividono alcuna cifratura, e il primo istinto è modificare il profilo. Questi due messaggi descrivono guasti diversi. Uno dice che il programma locale non ha quell’algoritmo; l’altro che entrambi gli estremi hanno algoritmi ma nessuna scelta comune. Modificare il profilo non risolve né l’uno né l’altro finché non sai quale hai.

Leggi il testo esatto dell’errore e il binario che lo ha prodotto.

Stabilisci quale errore hai

Il messaggio su una cifratura non trovata viene dall’analisi delle opzioni sulla macchina locale, prima che sia inviato qualsiasi pacchetto. Significa che l’eseguibile davanti a te, o la libreria a cui è collegato, non offre quell’algoritmo. Il messaggio sull’assenza di cifratura comune arriva più tardi, durante la negoziazione, e implica che entrambi i lati supportano cifrature ma non ne concordano una.

La distinzione conta perché uno è un problema di versione del software e l’altro di configurazione. Il primo si risolve con un numero di versione. Il secondo si risolve confrontando due elenchi.

Una lacuna locale di capacità

Le vecchie build della comunità precedono i valori predefiniti moderni, e un’applicazione desktop può portare il proprio motore, diverso dal pacchetto a riga di comando installato accanto. Esegui i controlli sull’eseguibile che ha realmente avviato la connessione, poi scegli una build supportata invece di insegnare un nuovo algoritmo a un vecchio binario.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Se AES-256-GCM non compare in quell’elenco, nessuna riga del profilo lo aggiungerà. La soluzione è un client più recente o un’altra build, e i vincoli del peer più vecchio diventano una questione di progettazione separata.

Nei client basati su OpenVPN 3 il motore e le direttive accettate differiscono dalla linea comunitaria 2.x, quindi lo stesso testo del profilo può fallire per motivi che non hanno nulla a che vedere con l’elenco delle cifrature.

Una lacuna di negoziazione

Quando entrambi i peer elencano l’algoritmo, resta la domanda su quale elenco offra ciascun lato. L’OpenVPN comunitario ha rinominato la direttiva di negoziazione: ncp-ciphers in 2.4 è diventato data-ciphers in 2.5, e in 2.6 la vecchia riga cipher serve soprattutto a compatibilità e ripiego, non a definire l’insieme negoziato.

Per questo modificare solo una vecchia riga cipher può lasciare intatto l’elenco di negoziazione. La riga vecchia conta ancora per il ripiego, che è un lavoro separato. Confondere le due cose produce modifiche che non cambiano nulla di visibile.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Confronta gli elenchi dei due estremi e il messaggio di rifiuto del server. Se l’intersezione è vuota, allinea gli elenchi deliberatamente invece di copiare un valore da un articolo scritto per un’altra versione. Un elenco troppo generoso indebolisce in silenzio ogni connessione. Un elenco troppo stretto esclude il peer che volevi mantenere.

Mantieni esplicita la compatibilità

Un ripiego per un peer vecchio è una decisione con un costo: l’intera distribuzione accetta un’opzione più debole perché un solo dispositivo possa collegarsi. Scrivilo come tale e limitarlo al peer che ne ha bisogno.

Due condizioni decidono l’esito. Se l’errore è locale, sostituisci la build. Se l’errore è di negoziazione, allinea gli elenchi su entrambi i lati e annota quali versioni supporti.

Poi segnala l’errore esatto con l’output di versione e capacità allegato. Questa coppia separa un algoritmo mancante da un disaccordo e ferma la successiva serie di modifiche speculative prima che inizi.