OpenVPN diu que ncp-disable és desconegut: què el va substituir?

El client es nega a arrencar amb un error d'opcions que esmenta ncp-disable, i el perfil funcionava a la màquina anterior. Aquest missatge no vol dir que l'opció estigui mal escrita ni que el xifratge estigui trencat. Vol dir que el binari que teniu al davant no coneix gens la directiva, i hi ha dues raons ben diferents per a això. Quina s'aplica decideix si editeu el perfil o canvieu el client.

L'error pot venir d'un binari més nou

Un error d'opció no reconeguda fa referència a l'analitzador, no al túnel. OpenVPN 2.4 va afegir paràmetres de xifratge negociables, la 2.5 va declarar obsolet l'interruptor que els desactivava i la 2.6 el va eliminar del tot. Per tant, un perfil escrit per a la 2.3 o la 2.4 falla en un client actual encara que res del fitxer no hagi canviat. La versió que es queixa és més nova, no més antiga.

Esbrineu quin executable va produir el missatge abans d'editar res. Un client d'escriptori inclou el seu propi motor, mentre que un binari de línia d'ordres instal·lat a part té la seva pròpia versió. Els dos poden no coincidir a la mateixa màquina.

openvpn --version ho resol per al binari que proveu. Pot ser que un client amb GUI no exposi aquesta ordre; en aquest cas, llegiu la seva pantalla d'informació o la versió de la biblioteca inclosa.

Què controlava realment l'opció

La directiva desactivava la negociació de paràmetres criptogràfics, de manera que tots dos extrems tornaven a un comportament de selecció més antic governat pel paràmetre cipher. Mai no va desactivar el xifratge ni va convertir el túnel en text pla. Llegir-la com un interruptor de seguretat és el primer gir equivocat, i porta a canvis que empitjoren la connexió en lloc de millorar-la.

Un cop existeix la negociació, la pregunta equivalent és quins xifratges està disposat a fer servir cada costat. És una qüestió de política, i la política viu a data-ciphers a partir de la 2.5.

El nom més antic ncp-ciphers pertany a la 2.4. Barrejar els dos noms entre parells és una font habitual de fallades de negociació en un sol sentit. Un perfil que porta tots dos és un perfil editat per dues persones en moments diferents.

Substituïu la política, no l'ortografia

Definiu data-ciphers en tots dos parells amb una elecció compartida volguda i mantingueu la llista prou curta perquè un revisor hi pugui raonar. Canviar una línia arbitrària no demostra res; el resultat depèn de la intersecció de les dues llistes i del que admeti la pila TLS. Confirmeu que els parells coincideixen llegint el resultat negociat en lloc de la configuració. Després escriviu les dues llistes al registre de desplegament perquè el proper canvi comenci des d'un estat conegut.

Actualitzeu el perfil a través de qui en sigui propietari. Afegir una opció d'ignorar per amagar una directiva obsoleta deixa la qüestió de política sense resposta.

Si un parell més antic necessita realment un tractament de compatibilitat, limiteu-lo a aquell desplegament. Restaurar globalment un comportament obsolet no és un requisit previ per connectar parells moderns. L'excepció hauria de nomenar el parell per al qual existeix.

Dues línies que semblen una llista de xifratges i no ho són

Apilar dues línies de xifratge tampoc no restaura la negociació, i el resultat és un perfil que sembla una llista mentre es comporta com un sol valor. Una línia amb AES-256-CBC i la següent amb CBC és un intent habitual. CBC per si sol nomena un mode, no un algorisme, així que un analitzador pot acceptar-lo en una ranura i rebutjar-lo a la següent. Les directives cipher repetides defineixen la mateixa opció dues vegades en lloc d'acumular candidats.

Comproveu els noms acceptats amb openvpn --show-ciphers al binari de destinació en lloc de copiar una llista d'una guia escrita per a una altra branca. La llista canvia entre versions. Un nom vàlid en una branca no és necessàriament vàlid en l'altra.

Si l'objectiu era comparar el rendiment, anoteu els algorismes i la càrrega de treball. Passar a CBC no és una mesura que el xifratge estigui absent.

Comproveu què ha negociat realment la connexió

Establiu una connexió nova i llegiu la línia del canal de dades al registre, que nomena el xifratge en ús. El conjunt del canal de control es decideix per separat, així que la llista permesa del fitxer només mostra què s'oferia. Quan els dos parells han triat alguna cosa que no esperàveu, les llistes són on cal mirar, no la interfície del túnel. Confirmeu el resultat en una segona connexió després de qualsevol canvi, perquè un reinici pot reutilitzar una sessió en memòria cau.

Guardeu el resultat negociat al registre de desplegament al costat de la versió del perfil. Aquest és el fet que respon la propera pregunta sobre quin xifratge protegeix realment el trànsit.