¿OpenVPN rechaza la primera línea? El archivo probablemente es UTF-16

El error apunta a la primera línea de un archivo .ovpn y cita algo que parece letras revueltas donde debería decir client. El archivo se abre sin problemas en su editor, la primera línea dice client y la directiva es del todo corriente. Ambas observaciones son ciertas, porque el editor descodifica los bytes y el cliente no. Lo que está viendo es casi siempre un problema de codificación, no de sintaxis.

El mito: el editor le muestra el archivo

Un editor de texto descodifica bytes en caracteres con una codificación que o bien detecta o bien adivina. Cuando adivina UTF-16, el archivo se ve perfecto en pantalla mientras los bytes subyacentes son parejas, con un byte cero después de cada letra latina. OpenVPN lee esos bytes como caracteres, y la discrepancia aparece en la primera directiva que intenta analizar.

Así que la línea visible y la línea entregada son dos cosas distintas. Borrar los caracteres extraños que ve es un cambio en la visualización, no en la codificación, y el siguiente análisis falla por el mismo motivo con un mensaje algo distinto. Por eso perseguir el testigo del error no lleva a ninguna parte. Los bytes están mal en el origen, y cada lector posterior adivina la misma secuencia rota.

Merece la pena reconocer la forma concreta del fallo, porque es diagnóstica de una manera específica. Un testigo justo al principio del archivo, en un perfil que por lo demás ha funcionado en otras máquinas, es una cuestión de orden de bytes y no de vocabulario.

Qué dicen realmente los primeros bytes

Lea los bytes en lugar de los caracteres. Dos comandos pequeños lo resuelven en segundos, y ninguno requiere abrir el archivo en una aplicación que pueda cambiarlo:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

El patrón que busca es un par de bytes iniciales seguidos de texto en el que cada segundo byte es cero. FF FE indica UTF-16 little-endian, FE FF indica big-endian y EF BB BF indica UTF-8 con marca de orden de bytes. Un archivo UTF-8 normal sin marca empieza directamente con el byte de la primera letra.

Los bytes cero entre letras son la pista. En UTF-16 little-endian la palabra client ocupa doce bytes en lugar de seis, porque cada carácter ASCII va seguido de un cero. Esa estructura no es algo que la pantalla de un editor pueda mostrarle, ni algo que un borrado de dos bytes pueda eliminar.

Aquí hay un matiz importante: el lector de configuración de OpenVPN sí que salta una marca de orden de bytes UTF-8 al principio de un archivo, como muestra el lector de configuración 2.6. Esa tolerancia es específica de esa marca y no hace nada por un archivo UTF-16 cuyas letras están rellenadas con ceros. Tratar las dos marcas como el mismo problema es la segunda mitad del mito.

Convertir es guardar como, no borrar

Guarde una copia intacta del original del operador antes de hacer nada y trabaje sobre un archivo aparte. Un perfil puede contener una clave privada o material de cuenta, así que la copia es a la vez su marcha atrás y su referencia.

Después realice una conversión de codificación real, ya sea mediante el menú explícito de codificación del editor o con un conversor que declare su codificación de entrada y de salida:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

Verifique el resultado en lugar de confiar en el estado de salida del comando. La conversión debe conservar cada directiva, y tiene que conservar cualquier bloque de certificado o clave incrustado byte por byte dentro de sus marcas. Volver a envolver datos PEM, cambiar los finales de línea dentro de un bloque o reformatear el perfil durante la conversión crea un problema nuevo mientras arregla el viejo.

Apunte el cliente o el servicio al archivo convertido y mire el primer error que reporte. Si el testigo revuelto ha desaparecido, el trabajo de codificación está hecho y cualquier cosa que falle después es otra cuestión.

Qué no arregla una codificación arreglada

La codificación determina cómo se lee el texto; no dice nada sobre si las opciones son válidas para el cliente que tiene delante. Un perfil exportado para otra implementación puede analizarse limpiamente y aun así ser rechazado por una opción que la compilación en ejecución no admite, o por una directiva cuyo argumento significa otra cosa en ese cliente.

Esos errores posteriores merecen su propia investigación: la ortografía exacta, la sintaxis del argumento y la versión que lo acepta. No trate un análisis correcto como un perfil correcto.

Mantenga la investigación en local mientras está en ello. Los conversores públicos en línea y los volcados hex pegados son un mal lugar para un archivo que puede contener una clave privada, porque el problema de codificación es fácil de arreglar y una clave filtrada no.