OpenVPN rebutja la primera línia? El fitxer probablement és UTF-16

L’error assenyala la primera línia d’un fitxer .ovpn i cita una cosa que sembla lletres desordenades on hauria de dir client. El fitxer s’obre sense problemes a l’editor, la primera línia diu client i la directiva és del tot corrent. Totes dues observacions són certes, perquè l’editor descodifica els bytes i el client no. El que veus és gairebé sempre un problema de codificació, no de sintaxi.

El mite: l’editor et mostra el fitxer

Un editor de text descodifica bytes en caràcters amb una codificació que o bé detecta o bé endevina. Quan endevina UTF-16, el fitxer es veu perfecte a la pantalla mentre els bytes subjacents són parelles, amb un byte zero després de cada lletra llatina. OpenVPN llegeix aquests bytes com a caràcters, i la discrepància apareix a la primera directiva que intenta analitzar.

Així doncs, la línia visible i la línia lliurada són dues coses diferents. Esborrar els caràcters estranys que veus és un canvi en la visualització, no en la codificació, i la següent anàlisi falla pel mateix motiu amb un missatge una mica diferent. Per això perseguir el testimoni de l’error no porta enlloc. Els bytes són incorrectes a l’origen, i cada lector posterior endevina la mateixa seqüència trencada.

Val la pena reconèixer la forma concreta de la fallada, perquè és diagnòstica d’una manera específica. Un testimoni al mateix començament del fitxer, en un perfil que per la resta ha funcionat en altres màquines, és una qüestió d’ordre de bytes i no de vocabulari.

Què diuen realment els primers bytes

Llegeix els bytes en lloc dels caràcters. Dues ordres petites ho resolen en segons, i cap de les dues no requereix obrir el fitxer en una aplicació que el pugui canviar:

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

El patró que busques és un parell de bytes inicials seguits de text on cada segon byte és zero. FF FE indica UTF-16 little-endian, FE FF indica big-endian, i EF BB BF indica UTF-8 amb una marca d’ordre de bytes. Un fitxer UTF-8 pla sense marca comença directament amb el byte de la primera lletra.

Els bytes zero entre lletres són la pista. En UTF-16 little-endian, la paraula client ocupa dotze bytes en lloc de sis, perquè cada caràcter ASCII va seguit d’un zero. Aquesta estructura no és una cosa que la pantalla d’un editor et pugui mostrar, ni una cosa que una supressió de dos bytes pugui eliminar.

Aquí hi ha un matís important: el lector de configuració d’OpenVPN sí que salta una marca d’ordre de bytes UTF-8 al començament d’un fitxer, com mostra el lector de configuració 2.6. Aquesta tolerància és específica d’aquesta marca i no fa res per un fitxer UTF-16 les lletres del qual estan farcides de zeros. Tractar les dues marques com el mateix problema és la segona meitat del mite.

Convertir és desar com, no esborrar

Desa una còpia intacta de l’original de l’operador abans de fer res i treballa sobre un fitxer separat. Un perfil pot contenir una clau privada o material de compte, així que la còpia és alhora la teva reversió i la teva referència.

Després fes una conversió de codificació real, o bé pel menú explícit de codificació de l’editor o bé amb un convertidor que declari la codificació d’entrada i de sortida:

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

Verifica el resultat en lloc de confiar en l’estat de sortida de l’ordre. La conversió ha de preservar cada directiva i ha de preservar qualsevol bloc de certificat o clau incrustat byte per byte dins de les seves marques. Tornar a embolicar dades PEM, canviar els finals de línia dins d’un bloc o reformatar el perfil durant la conversió crea un problema nou mentre arregla el vell.

Apunta el client o el servei al fitxer convertit i mira el primer error que reporti. Si el testimoni desordenat ha desaparegut, la feina de codificació està feta i qualsevol cosa que falli després és una altra qüestió.

Què no arregla una codificació arreglada

La codificació determina com es llegeix el text; no diu res sobre si les opcions són vàlides per al client que tens davant. Un perfil exportat per a una altra implementació pot analitzar-se net i tot i així ser rebutjat per una opció que la compilació en execució no admet, o per una directiva l’argument de la qual significa una altra cosa en aquell client.

Aquests errors posteriors mereixen la seva pròpia investigació: l’ortografia exacta, la sintaxi de l’argument i la versió que l’accepta. No tractis una anàlisi correcta com un perfil correcte.

Mantingues la investigació en local mentre hi siguis. Els convertidors públics en línia i els bolcats hex enganxats són un mal lloc per a un fitxer que pot contenir una clau privada, perquè el problema de codificació és fàcil d’arreglar i una clau filtrada no.