Por qué añadir opt-verify no arreglará el error de cifrado de OpenVPN

Encuentras una sugerencia para añadir opt-verify, añades la línea y el error de cifrado se queda exactamente donde estaba. Ese resultado es previsible, porque la opción nunca negoció un cifrado. Era una comprobación de coherencia de opciones, obsoleta en la 2.6 y eliminada en la 2.7, y un perfil que todavía se analiza con ella no ha impuesto nada por ello.

Ayuda saber qué hacía antes la línea antes de concluir que es la pieza que falta. La historia también explica por qué ahora no puede ayudar.

Qué imponía antes la opción

El manual de la 2.6 marca opt-verify como obsoleta y describe el comportamiento anterior: el servidor descarta a los clientes cuyas opciones declaradas no coinciden con las suyas, comparando cosas como el tipo de dispositivo y la MTU. Esa comprobación también depende de que la comprobación de coherencia de opciones siga activada, así que un servidor que funciona con disable-occ nunca la tuvo. Fíjate en de qué se construye la comparación: texto que describe la configuración de la otra parte. No dice nada sobre qué cifrado usará el canal de datos.

Esa es la primera razón por la que el indicador no puede reparar un error de cifrado. La selección de cifrado se rige por la política data-ciphers y por lo que ambas partes admiten, y una comprobación textual de coherencia ni amplía esa lista ni realiza la negociación. La segunda razón es el alcance: la comprobación trata de si las opciones declaradas parecen compatibles, no de la calidad del camino que resulta.

Qué hace la 2.7 cuando ve la línea

En la 2.7 la opción ya no está. El analizador todavía reconoce el nombre, por eso un perfil antiguo se carga sin error de sintaxis, e informa de que la opción se eliminó en lugar de pasarla por alto en silencio. Reconocer un nombre e imponer un comportamiento son cosas distintas, y solo la primera sigue ocurriendo. Las notas de eliminación dan la razón: una vez que los parámetros se pueden negociar, dos partes pueden legítimamente tener cadenas de opciones distintas mientras acuerdan la conexión.

Un perfil que se analiza, por tanto, no es prueba de que se haya ejecutado ninguna comprobación de admisión. Si tu única señal es que el cliente se conectó, has aprendido que la sintaxis fue aceptada.

Dónde vive realmente el fallo

Conserva el primer error concreto antes de cambiar nada, porque los mensajes posteriores suelen ser consecuencias de él. Un fallo de negociación del canal de datos pertenece a la política de cifrado aprobada y a las capacidades que ambas partes anuncian realmente. Un fallo de versión o de conjunto TLS pertenece al canal de control. Un rechazo de certificado necesita la identidad y la cadena de confianza, no un indicador de compatibilidad.

Identifica también el motor en ambos extremos. Una aplicación de escritorio puede incluir una compilación distinta del binario de línea de comandos con el que probaste, y el soporte de opciones difiere entre ellos. Consulta la documentación de ese motor en lugar de suponer que todos los programas que importan un perfil se comportan igual.

Sustituye la intención, no solo la línea

Si un servidor gestionado más antiguo dependía de verdad de la comprobación de coherencia, anota qué restricción imponía antes de la actualización. Mantener una opción ignorada en un perfil más nuevo no puede preservar esa política, y borrar líneas indiscriminadamente tampoco.

No respondas a una sugerencia antigua de que todos los cifrados están desactivados habilitando todos los algoritmos históricos.

Tras una corrección aprobada, revisa los resultados negociados en una conexión nueva y prueba la aplicación que el usuario realmente necesita. Mantén la versión del servidor y la política efectiva junto a ese resultado, para que la siguiente persona vea qué se acordó y no solo qué se aceptó.

El objetivo es una restricción admitida y un camino autenticado que funcione, no un indicador heredado que todavía se analiza.