OpenVPN afviser linje et? Filen er sandsynligvis UTF-16

Fejlen peger på den første linje i en .ovpn-fil og citerer noget, der ligner sammenblandede bogstaver, hvor client burde stå. Filen åbner fint i din editor, den første linje læses som client, og direktivet er helt almindeligt. Begge observationer er sande, fordi editoren afkoder bytene, og klienten gør det ikke. Det, du ser, er næsten altid et kodningsproblem, ikke et syntaksproblem.

Myten: editoren viser dig filen

En teksteditor afkoder bytes til tegn ved hjælp af en kodning, som den enten registrerer eller gætter på. Når den gætter på UTF-16, ser filen perfekt ud på skærmen, mens bytene under er par, med en nulbyte efter hvert latinske bogstav. OpenVPN læser de bytes som tegn, og uoverensstemmelsen viser sig ved det første direktiv, den forsøger at fortolke.

Så den synlige linje og den leverede linje er to forskellige ting. At slette de mærkelige tegn, du kan se, er en ændring af visningen, ikke af kodningen, og den næste fortolkning fejler af samme grund med en lidt anderledes meddelelse. Derfor fører jagten på tegnet i fejlen hele tiden ingen vegne. Bytene er forkerte ved kilden, og enhver læser længere fremme gætter på den samme brudte sekvens.

Den konkrete form for fejlen er værd at genkende, fordi den er diagnostisk på en bestemt måde. Et tegn helt i starten af filen, i en profil der ellers har virket på andre maskiner, er et spørgsmål om byteorden snarere end om ordforråd.

Hvad de første bytes faktisk siger

Læs bytene i stedet for tegnene. To små kommandoer afgør det på sekunder, og ingen af dem kræver, at du åbner filen i et program, der kan ændre den:

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

Det mønster, du leder efter, er et par indledende bytes efterfulgt af tekst, hvor hver anden byte er nul. FF FE markerer UTF-16 little-endian, FE FF markerer big-endian, og EF BB BF markerer UTF-8 med en byteordensmarkering. En almindelig UTF-8-fil uden mærke starter direkte med det første bogstavs byte.

Nulbytene mellem bogstaverne er det afslørende tegn. I UTF-16 little-endian optager ordet client tolv bytes i stedet for seks, fordi hvert ASCII-tegn efterfølges af et nul. Den struktur er ikke noget, en editors skærm kan vise dig, og den er ikke noget, en sletning af to bytes kan fjerne.

Der ligger en vigtig nuance her: OpenVPNs konfigurationslæser springer faktisk en UTF-8-byteordensmarkering over i starten af en fil, som 2.6-konfigurationslæseren viser. Den tolerance gælder netop den markering og gør intet for en UTF-16-fil, hvis bogstaver er polstret med nuller. At behandle de to markeringer som samme problem er den anden halvdel af myten.

Konvertering er gem-som, ikke sletning

Bevar en urørt kopi af operatørens original, før du gør noget, og arbejd på en separat fil. En profil kan indeholde en privat nøgle eller kontomateriale, så kopien er både din tilbagerulning og din reference.

Udfør derefter en egentlig kodningskonvertering, enten via editorens eksplicitte kodningsmenu eller med et konverteringsværktøj, der angiver sin input- og outputkodning:

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

Bekræft resultatet i stedet for at stole på kommandoens exitstatus. Konverteringen bør bevare hvert direktiv, og den skal bevare enhver indlejret certifikat- eller nøgleblok byte for byte inden for sine markører. At ombryde PEM-data igen, ændre linjeafslutninger inde i en blok eller omformatere profilen under konverteringen skaber et nyt problem, mens det gamle løses.

Peg klienten eller tjenesten mod den konverterede fil, og se på den første fejl, den rapporterer. Hvis det sammenblandede tegn er væk, er kodningsarbejdet færdigt, og alt, der fejler bagefter, er et andet spørgsmål.

Hvad en rettet kodning ikke retter

Kodning bestemmer, hvordan tekst læses; den siger intet om, hvorvidt valgmulighederne er gyldige for den klient, du har foran dig. En profil eksporteret til en anden implementering kan fortolkes rent og alligevel afvises på grund af en valgmulighed, som det kørende build ikke understøtter, eller på grund af et direktiv, hvis argument betyder noget andet i den klient.

De senere fejl fortjener deres egen undersøgelse: den præcise stavemåde, argumentets syntaks og den version, der accepterer det. Betragt ikke en vellykket fortolkning som en vellykket profil.

Hold undersøgelsen lokal, mens du er i gang. Offentlige online-konvertere og indsatte hex-dumps er et dårligt sted for en fil, der kan indeholde en privat nøgle, fordi kodningsproblemet er let at rette, og en lækket nøgle ikke er.