OpenVPN dice che ncp-disable è sconosciuto: cosa lo ha sostituito?

Il client si rifiuta di avviarsi con un errore di opzioni che nomina ncp-disable, mentre il profilo funzionava sulla macchina precedente. Quel messaggio non significa che l'opzione sia scritta male o che la cifratura sia rotta. Significa che il binario davanti a voi non conosce affatto la direttiva, e ci sono due motivi molto diversi per questo. Quale si applichi decide se modificate il profilo o cambiate il client.

L'errore può venire da un binario più nuovo

Un errore di opzione non riconosciuta riguarda il parser, non il tunnel. OpenVPN 2.4 ha aggiunto parametri di cifratura negoziabili, la 2.5 ha dichiarato obsoleto l'interruttore che li disattivava e la 2.6 lo ha rimosso del tutto. Per questo un profilo scritto per la 2.3 o la 2.4 fallisce su un client attuale anche se nulla nel file è cambiato. La versione che si lamenta è più nuova, non più vecchia.

Scoprite quale eseguibile ha prodotto il messaggio prima di modificare qualsiasi cosa. Un client desktop porta con sé il proprio motore, mentre un binario da riga di comando installato a parte ha la propria versione. I due possono non essere d'accordo sulla stessa macchina.

openvpn --version lo risolve per il binario che state testando. Un client con GUI potrebbe non esporre quel comando; in tal caso leggete la sua schermata Informazioni o la versione della libreria inclusa.

Cosa controllava davvero l'opzione

La direttiva disattivava la negoziazione dei parametri crittografici, quindi entrambe le estremità tornavano a un comportamento di selezione più vecchio guidato dall'impostazione cipher. Non ha mai disattivato la cifratura e non ha mai trasformato il tunnel in testo in chiaro. Leggerla come un interruttore di sicurezza è la prima svolta sbagliata, e porta a modifiche che peggiorano la connessione invece di migliorarla.

Una volta esistente la negoziazione, la domanda equivalente è quali cifrari ciascun lato è disposto a usare. È una questione di politica, e la politica vive in data-ciphers dalla 2.5 in poi.

Il nome più vecchio ncp-ciphers appartiene alla 2.4. Mescolare i due nomi tra i peer è una fonte comune di fallimenti di negoziazione a senso unico. Un profilo che porta entrambi è un profilo modificato da due persone in momenti diversi.

Sostituite la politica, non l'ortografia

Impostate data-ciphers su entrambi i peer con una scelta condivisa voluta e tenete la lista abbastanza corta che un revisore possa ragionarci. Cambiare una riga arbitraria non dimostra nulla; il risultato dipende dall'intersezione delle due liste e da ciò che lo stack TLS supporta. Confermate l'accordo dei peer leggendo il risultato negoziato invece della configurazione. Poi scrivete le due liste nel registro di distribuzione perché il prossimo cambio parta da uno stato noto.

Aggiornate il profilo tramite chi lo possiede. Aggiungere un'opzione di ignoranza per nascondere una direttiva obsoleta lascia la questione di politica senza risposta.

Se un peer più vecchio ha davvero bisogno di una gestione della compatibilità, limitatela a quella distribuzione. Ripristinare globalmente un comportamento obsoleto non è un prerequisito per collegare peer moderni. L'eccezione dovrebbe nominare il peer per cui esiste.

Due righe che sembrano una lista di cifrari e non lo sono

Impilare due righe di cifratura non ripristina nemmeno la negoziazione, e il risultato è un profilo che sembra una lista pur comportandosi come un unico valore. Una riga con AES-256-CBC e la successiva con CBC è un tentativo comune. CBC da solo nomina una modalità, non un algoritmo, quindi un parser può accettarlo in uno slot e rifiutarlo in quello dopo. Le direttive cipher ripetute impostano la stessa opzione due volte invece di accumulare candidati.

Verificate i nomi accettati con openvpn --show-ciphers sul binario di destinazione invece di copiare una lista da una guida scritta per un altro ramo. La lista cambia tra le versioni. Un nome valido in un ramo non è necessariamente valido nell'altro.

Se lo scopo era confrontare le prestazioni, annotate gli algoritmi e il carico di lavoro. Passare a CBC non è una misura dell'assenza di cifratura.

Verificate cosa ha negoziato davvero la connessione

Aprite una nuova connessione e leggete la riga del canale dati nel registro, che nomina il cifrario in uso. La suite del canale di controllo è decisa separatamente, quindi la lista consentita nel file mostra solo ciò che è stato offerto. Quando i due peer hanno scelto qualcosa che non vi aspettavate, le liste sono il posto dove guardare, non l'interfaccia del tunnel. Confermate il risultato su una seconda connessione dopo ogni modifica, perché un riavvio può riutilizzare una sessione in cache.

Conservate il risultato negoziato nel registro di distribuzione accanto alla versione del profilo. È il fatto che risponde alla domanda successiva su quale cifrario protegga davvero il traffico.