OpenVPN dice que ncp-disable es desconocido: ¿qué lo sustituyó?

El cliente se niega a arrancar con un error de opciones que menciona ncp-disable, y el perfil funcionaba en la máquina anterior. Ese mensaje no significa que la opción esté mal escrita ni que el cifrado esté roto. Significa que el binario que tiene delante no conoce la directiva en absoluto, y hay dos razones muy distintas para ello. Cuál se aplique decide si edita el perfil o cambia el cliente.

El error puede venir de un binario más nuevo

Un error de opción no reconocida tiene que ver con el analizador, no con el túnel. OpenVPN 2.4 añadió parámetros de cifrado negociables, la 2.5 declaró obsoleto el interruptor que los desactivaba y la 2.6 lo eliminó por completo. Por eso un perfil escrito para la 2.3 o la 2.4 falla en un cliente actual aunque nada del archivo haya cambiado. La versión que se queja es más nueva, no más antigua.

Averigüe qué ejecutable produjo el mensaje antes de editar nada. Un cliente de escritorio incluye su propio motor, mientras que un binario de línea de comandos instalado aparte tiene su propia versión. Los dos pueden no coincidir en la misma máquina.

openvpn --version lo resuelve para el binario que está probando. Puede que un cliente con GUI no exponga ese comando; en tal caso, lea su pantalla de información o la versión de la biblioteca incluida.

Qué controlaba realmente la opción

La directiva desactivaba la negociación de parámetros criptográficos, de modo que ambos extremos volvían a un comportamiento de selección más antiguo gobernado por el ajuste cipher. Nunca desactivó el cifrado ni convirtió el túnel en texto plano. Leerla como un interruptor de seguridad es el primer giro equivocado, y lleva a cambios que empeoran la conexión en lugar de mejorarla.

Una vez que existe la negociación, la pregunta equivalente es qué cifrados está dispuesto a usar cada lado. Es una cuestión de política, y la política vive en data-ciphers desde la 2.5.

El nombre más antiguo ncp-ciphers pertenece a la 2.4. Mezclar los dos nombres entre pares es una fuente habitual de fallos de negociación en un solo sentido. Un perfil que lleva ambos es un perfil editado por dos personas en momentos distintos.

Sustituya la política, no la ortografía

Defina data-ciphers en ambos pares con una elección compartida pretendida y mantenga la lista lo bastante corta para que un revisor pueda razonar sobre ella. Cambiar una línea arbitraria no demuestra nada; el resultado depende de la intersección de ambas listas y de lo que admita la pila TLS. Confirme que los pares coinciden leyendo el resultado negociado en lugar de la configuración. Después escriba las dos listas en el registro de despliegue para que el siguiente cambio parta de un estado conocido.

Actualice el perfil a través de quien lo posea. Añadir una opción de ignorar para ocultar una directiva obsoleta deja la cuestión de política sin respuesta.

Si un par más antiguo necesita de verdad un tratamiento de compatibilidad, limítelo a ese despliegue. Restaurar globalmente un comportamiento obsoleto no es un requisito previo para conectar pares modernos. La excepción debería nombrar el par para el que existe.

Dos líneas que parecen una lista de cifrados y no lo son

Apilar dos líneas de cifrado tampoco restaura la negociación, y el resultado es un perfil que parece una lista mientras se comporta como un solo valor. Una línea con AES-256-CBC y la siguiente con CBC es un intento habitual. CBC por sí solo nombra un modo, no un algoritmo, así que un analizador puede aceptarlo en una ranura y rechazarlo en la siguiente. Las directivas cipher repetidas fijan la misma opción dos veces en lugar de acumular candidatos.

Compruebe los nombres aceptados con openvpn --show-ciphers en el binario de destino en lugar de copiar una lista de una guía escrita para otra rama. La lista cambia entre versiones. Un nombre válido en una rama no es necesariamente válido en la otra.

Si el objetivo era comparar el rendimiento, anote los algoritmos y la carga de trabajo. Cambiar a CBC no es una medida de que el cifrado esté ausente.

Compruebe qué ha negociado realmente la conexión

Establezca una conexión nueva y lea la línea del canal de datos en el registro, que nombra el cifrado en uso. El conjunto del canal de control se decide por separado, así que la lista permitida del archivo solo muestra lo que se ofreció. Cuando los dos pares han elegido algo que no esperaba, las listas son el lugar donde mirar, no la interfaz del túnel. Confirme el resultado en una segunda conexión tras cualquier cambio, porque un reinicio puede reutilizar una sesión en caché.

Guarde el resultado negociado en el registro de despliegue junto a la versión del perfil. Ese es el hecho que responde a la siguiente pregunta sobre qué cifrado protege realmente el tráfico.