El perfil .ovpn antiguo falla en Ubuntu 24.04: qué líneas hay que borrar

El perfil se descarga, se importa y luego se detiene en la línea 12 del archivo con un mensaje Unrecognized option que nombra keysize. Nada de la cuenta ha cambiado y el servidor sigue aceptando otros clientes. Lo que cambió es el propio cliente: Ubuntu 24.04 instala OpenVPN 2.6, mientras que la exportación se escribió para la 2.4. La reparación es una serie corta de borrados, y el orden importa porque cada opción obsoleta aborta el análisis antes de que la siguiente llegue a leerse.

Lea la línea del error antes de tocar el archivo

OpenVPN nombra el archivo y la línea donde se detuvo el análisis, así que solo puede arreglar un problema por ejecución. Arranque el perfil desde una terminal en lugar de un applet de escritorio, porque el applet suele tragarse stderr y el número de línea es la única pista fiable que recibe: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Corrija esa línea, ejecute de nuevo y espere que el siguiente fallo nombre otra opción.

Un error de análisis aparece siempre antes de cualquier handshake TLS, así que un mensaje que menciona un certificado ya ha superado la fase de sintaxis. Esa distinción le evita editar un archivo que solo falla en la autenticación. Lea la primera palabra del mensaje en lugar de su mitad.

Tres clases de fallo, tres reparaciones distintas

Las exportaciones antiguas fallan de tres maneras distinguibles, y justo el fundirlas en un solo problema es lo que lleva a la gente a reinstalar paquetes que nunca estuvieron rotos. La redacción del mensaje le dice en qué clase está antes de abrir el archivo.

• Los errores de análisis nombran un archivo y una línea, y se detienen antes de que exista tráfico.
• Los errores de negociación conectan y luego informan de que los dos extremos no lograron acordar un cifrado compartido o un canal de datos aceptable.
• Los errores de autenticación llegan más lejos y nombran un certificado, un usuario o una credencial rechazada.

Editar el perfil solo arregla la primera clase. La negociación necesita una decisión en ambos extremos del túnel, y una credencial rechazada no es en absoluto un problema de sintaxis. Si su mensaje menciona un cifrado compartido o un canal de datos, los borrados de abajo no cambiarán nada.

Borre las opciones que la 2.6 eliminó, en este orden

Cada una de estas líneas detiene el análisis por sí sola, así que el cliente las informa de una en una. Recorra la lista y vuelva a ejecutar tras cada borrado.

Borre primero keysize, porque no tiene equivalente moderno y su presencia suele marcar un cifrado que el cliente actual rechaza de todos modos. Después borre ncp-disable, que controlaba la negociación de cifrados, quedó obsoleto en la 2.5 y ya no existe en la 2.6. Sustituya ns-cert-type server por remote-cert-tls server, que expresa la misma intención mediante una comprobación admitida. El historial de cambios de la 2.6 enumera las eliminaciones restantes junto a sus sustituciones, así que todo lo que el analizador siga rechazando tiene una respuesta documentada.

Guarde una copia del perfil original antes de la primera edición. Los proveedores regeneran las exportaciones, y un diff contra el archivo intacto es la forma más rápida de separar sus cambios de los de ellos. Si un borrado permite que el cliente arranque pero el túnel sigue fallando, ya ha pasado a la clase de negociación y las líneas restantes no son la causa. Ponga la versión del cliente en el nombre del archivo para que la siguiente persona sepa a qué versión apuntan las ediciones.

Mantenga BF-CBC solo como alternativa acotada

Algunos proveedores siguen terminando en BF-CBC, con el que OpenVPN 2.6 no negociará sin ayuda porque el cifrado tiene un bloque de 64 bits. La reparación estrecha es una lista de alternativas más el proveedor heredado de OpenSSL, no una degradación de todo el cliente.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

La primera línea carga el proveedor heredado para que OpenSSL aún pueda instanciar ese cifrado, la segunda conserva la negociación moderna para los pares que la admiten, y la tercera solo se aplica cuando el servidor no ofrece nada mejor. Es un debilitamiento deliberado del túnel, así que anote por qué existe junto al archivo. Pida al proveedor una exportación regenerada al mismo tiempo, porque la alternativa es un puente y no un destino.

No recurra a --compat-mode como respuesta universal. Cambia varios comportamientos a la vez, incluidos los valores por defecto de negociación y renegociación, así que nunca sabrá qué cambio fue el importante. Prefiera las tres líneas explícitas de arriba, porque cada una declara su propio efecto.

Verifique con el perfil que el cliente carga de verdad

Las conexiones importadas suelen copiarse a un directorio del sistema, así que editar el archivo de su carpeta de descargas puede no cambiar absolutamente nada. Encuentre la copia que se ejecuta: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Después arranque el túnel y lea la línea del registro que informa de qué cifrado de canal de datos se eligió realmente. Una conexión que completa el handshake con la alternativa le dice que el servidor nunca ofreció nada moderno.

Pruebe desde una red que no sea la que el proveedor espera, para que un portal cautivo o una red de invitados filtrada no se disfracen de fallo del perfil. Anote la versión del cliente junto a cualquier solicitud de soporte.

Una vez que el túnel esté levantado, envíe una solicitud que deba cruzarlo y otra que no deba, y luego confirme que la respuesta del resolutor cambió como esperaba. Si el perfil ya se analiza pero la conexión sigue fallando, ha dejado atrás el problema de sintaxis y el texto del error nombrará la nueva clase. Mantenga el archivo editado en el control de versiones junto a una nota que nombre la versión de OpenVPN a la que apunta.