OpenVPN rifiuta la prima riga? Il file è probabilmente in UTF-16

L’errore punta alla prima riga di un file .ovpn e cita qualcosa che sembra lettere mescolate dove dovrebbe esserci client. Il file si apre senza problemi nel tuo editor, la prima riga dice client e la direttiva è del tutto ordinaria. Entrambe le osservazioni sono vere, perché l’editor decodifica i byte e il client no. Quello che vedi è quasi sempre un problema di codifica, non di sintassi.

Il mito: l’editor ti mostra il file

Un editor di testo decodifica i byte in caratteri con una codifica che rileva oppure indovina. Quando indovina UTF-16, il file appare perfetto sullo schermo mentre i byte sottostanti sono coppie, con un byte nullo dopo ogni lettera latina. OpenVPN legge quei byte come caratteri, e la discrepanza compare alla prima direttiva che tenta di analizzare.

Quindi la riga visibile e la riga consegnata sono due cose diverse. Cancellare i caratteri strani che vedi è un cambiamento nella visualizzazione, non nella codifica, e l’analisi successiva fallisce per lo stesso motivo con un messaggio leggermente diverso. Per questo inseguire il token nell’errore non porta mai da nessuna parte. I byte sono sbagliati all’origine, e ogni lettore a valle indovina la stessa sequenza rotta.

Vale la pena riconoscere la forma precisa del guasto, perché è diagnostica in un modo specifico. Un token all’inizio esatto del file, in un profilo che per il resto ha funzionato su altre macchine, è una questione di ordine dei byte e non di vocabolario.

Che cosa dicono davvero i primi byte

Leggi i byte invece dei caratteri. Due piccoli comandi risolvono la questione in pochi secondi, e nessuno dei due richiede di aprire il file in un’applicazione che potrebbe modificarlo:

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

Il modello che cerchi è una coppia di byte iniziali seguita da testo in cui ogni secondo byte è nullo. FF FE indica UTF-16 little-endian, FE FF indica big-endian, e EF BB BF indica UTF-8 con una marca di ordine dei byte. Un file UTF-8 semplice senza marca inizia direttamente con il byte della prima lettera.

I byte nulli tra le lettere sono l’indizio. In UTF-16 little-endian la parola client occupa dodici byte invece di sei, perché ogni carattere ASCII è seguito da uno zero. Quella struttura non è qualcosa che il display di un editor può mostrarti, e non è qualcosa che una cancellazione di due byte può rimuovere.

Qui c’è una sfumatura importante: il lettore di configurazione di OpenVPN salta davvero una marca di ordine dei byte UTF-8 all’inizio di un file, come mostra il lettore di configurazione 2.6. Quella tolleranza è specifica di quella marca e non fa nulla per un file UTF-16 le cui lettere sono riempite di zeri. Trattare le due marche come lo stesso problema è la seconda metà del mito.

Convertire è salva con nome, non cancellare

Conserva una copia intatta dell’originale dell’operatore prima di fare qualsiasi cosa, e lavora su un file separato. Un profilo può contenere una chiave privata o materiale dell’account, quindi la copia è sia il tuo ritorno indietro sia il tuo riferimento.

Poi esegui una vera conversione di codifica, tramite il menu di codifica esplicito dell’editor oppure con un convertitore che dichiari la codifica di input e di output:

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

Verifica il risultato invece di fidarti dello stato di uscita del comando. La conversione dovrebbe preservare ogni direttiva, e deve preservare qualsiasi blocco di certificato o chiave incorporato byte per byte entro i suoi marcatori. Riavvolgere dati PEM, cambiare i fine riga all’interno di un blocco o riformattare il profilo durante la conversione crea un nuovo problema mentre risolve quello vecchio.

Punta il client o il servizio al file convertito e guarda il primo errore che riporta. Se il token mescolato è sparito, il lavoro di codifica è finito e qualunque cosa fallisca dopo è un’altra questione.

Che cosa non risolve una codifica sistemata

La codifica determina come viene letto il testo; non dice nulla sulla validità delle opzioni per il client che hai davanti. Un profilo esportato per un’altra implementazione può essere analizzato senza errori ed essere comunque rifiutato per un’opzione che la build in esecuzione non supporta, o per una direttiva il cui argomento in quel client significa altro.

Quegli errori successivi meritano un’indagine a parte: l’ortografia esatta, la sintassi dell’argomento e la versione che lo accetta. Non considerare un’analisi riuscita un profilo riuscito.

Tieni l’indagine in locale mentre ci lavori. I convertitori pubblici online e i dump esadecimali incollati sono un cattivo posto per un file che può contenere una chiave privata, perché il problema di codifica è facile da risolvere e una chiave trapelata no.