OpenVPN rexeita a primeira liña? O ficheiro probablemente é UTF-16

O erro apunta á primeira liña dun ficheiro .ovpn e cita algo que parece letras revoltas onde debería dicir client. O ficheiro ábrese sen problemas no seu editor, a primeira liña di client e a directiva é do todo corrente. Ambas as observacións son certas, porque o editor descodifica os bytes e o cliente non. O que está a ver é case sempre un problema de codificación, non de sintaxe.

O mito: o editor móstralle o ficheiro

Un editor de texto descodifica bytes en caracteres cunha codificación que ou ben detecta ou ben adiviña. Cando adiviña UTF-16, o ficheiro vese perfecto na pantalla mentres os bytes subxacentes son parellas, cun byte cero despois de cada letra latina. OpenVPN le eses bytes como caracteres, e a discrepancia aparece na primeira directiva que tenta analizar.

Así que a liña visible e a liña entregada son dúas cousas distintas. Borrar os caracteres estraños que ve é un cambio na visualización, non na codificación, e a seguinte análise falla polo mesmo motivo cunha mensaxe algo distinta. Por iso perseguir o testemuño do erro non leva a ningures. Os bytes están mal na orixe, e cada lector posterior adiviña a mesma secuencia rota.

Paga a pena recoñecer a forma concreta do fallo, porque é diagnóstica dunha maneira específica. Un testemuño xusto ao comezo do ficheiro, nun perfil que por demais funcionou noutras máquinas, é unha cuestión de orde de bytes e non de vocabulario.

Que din realmente os primeiros bytes

Lea os bytes en lugar dos caracteres. Dous comandos pequenos resolven a cuestión en segundos, e ningún require abrir o ficheiro nunha aplicación que poida cambialo:

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

O patrón que busca é un par de bytes iniciais seguidos de texto no que cada segundo byte é cero. FF FE indica UTF-16 little-endian, FE FF indica big-endian e EF BB BF indica UTF-8 con marca de orde de bytes. Un ficheiro UTF-8 normal sen marca comeza directamente co byte da primeira letra.

Os bytes cero entre letras son a pista. En UTF-16 little-endian a palabra client ocupa doce bytes en lugar de seis, porque cada carácter ASCII vai seguido dun cero. Esa estrutura non é algo que a pantalla dun editor lle poida mostrar, nin algo que un borrado de dous bytes poida eliminar.

Aquí hai un matiz importante: o lector de configuración de OpenVPN si salta unha marca de orde de bytes UTF-8 ao comezo dun ficheiro, como mostra o lector de configuración 2.6. Esa tolerancia é específica desa marca e non fai nada por un ficheiro UTF-16 cuxas letras están enchidas con ceros. Tratar as dúas marcas como o mesmo problema é a segunda metade do mito.

Converter é gardar como, non borrar

Garde unha copia intacta do orixinal do operador antes de facer nada e traballe nun ficheiro aparte. Un perfil pode conter unha clave privada ou material de conta, así que a copia é á vez a súa marcha atrás e a súa referencia.

Despois realice unha conversión de codificación real, xa sexa mediante o menú explícito de codificación do editor ou cun conversor que declare a súa codificación de entrada e de saída:

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

Verifique o resultado en lugar de confiar no estado de saída do comando. A conversión debe conservar cada directiva, e ten que conservar calquera bloque de certificado ou clave incrustado byte por byte dentro das súas marcas. Volver envolver datos PEM, cambiar os finais de liña dentro dun bloque ou reformatear o perfil durante a conversión crea un problema novo mentres arranxa o vello.

Apunta o cliente ou o servizo ao ficheiro convertido e mire o primeiro erro que reporte. Se o testemuño revoltos desapareceu, o traballo de codificación está feito e calquera cousa que falle despois é outra cuestión.

Que non arranxa unha codificación arranxada

A codificación determina como se le o texto; non di nada sobre se as opcións son válidas para o cliente que ten diante. Un perfil exportado para outra implementación pode analizarse limpiamente e aínda así ser rexeitado por unha opción que a compilación en execución non admite, ou por unha directiva cuxo argumento significa outra cousa nese cliente.

Eses erros posteriores merecen a súa propia investigación: a ortografía exacta, a sintaxe do argumento e a versión que o acepta. Non trate unha análise correcta como un perfil correcto.

Manteña a investigación en local mentres está niso. Os conversores públicos en liña e os volcados hex pegados son un mal lugar para un ficheiro que pode conter unha clave privada, porque o problema de codificación é fácil de arranxar e unha clave filtrada non.