Avviser OpenVPN den første linjen? Filen er sannsynligvis UTF-16

Feilen peker på den første linjen i en .ovpn-fil og siterer noe som ser ut som sammenblandede bokstaver der client skulle stå. Filen åpnes fint i redigeringsprogrammet ditt, den første linjen leses som client, og direktivet er helt vanlig. Begge observasjonene stemmer, fordi redigeringsprogrammet dekoder bytene og klienten ikke gjør det. Det du ser, er nesten alltid et kodingsproblem, ikke et syntaksproblem.

Myten: redigeringsprogrammet viser deg filen

Et tekstredigeringsprogram dekoder byter til tegn med en koding det enten oppdager eller gjetter på. Når det gjetter på UTF-16, ser filen perfekt ut på skjermen mens bytene under er par, med en nullbyte etter hver latinske bokstav. OpenVPN leser disse bytene som tegn, og avviket vises ved det første direktivet det prøver å tolke.

Så den synlige linjen og den leverte linjen er to forskjellige ting. Å slette de rare tegnene du ser, er en endring i visningen, ikke i kodingen, og neste tolkning feiler av samme grunn med en litt annen melding. Derfor fører jakten på tegnet i feilen aldri noe sted. Bytene er feil ved kilden, og hver leser lenger ned gjetter på den samme ødelagte sekvensen.

Den konkrete formen for feilen er verdt å kjenne igjen, fordi den er diagnostisk på en bestemt måte. Et tegn helt i starten av filen, i en profil som ellers har fungert på andre maskiner, er et spørsmål om byteorden snarere enn om ordforråd.

Hva de første bytene faktisk sier

Les bytene i stedet for tegnene. To små kommandoer avgjør det på sekunder, og ingen av dem krever å åpne filen i et program som kan endre den:

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

Mønsteret du ser etter, er et par innledende byter etterfulgt av tekst der hver andre byte er null. FF FE markerer UTF-16 little-endian, FE FF markerer big-endian, og EF BB BF markerer UTF-8 med en byteordensmarkering. En vanlig UTF-8-fil uten merke starter rett med den første bokstavens byte.

Nullbytene mellom bokstavene er det avgjørende tegnet. I UTF-16 little-endian tar ordet client tolv byter i stedet for seks, fordi hvert ASCII-tegn etterfølges av en null. Den strukturen kan ikke et redigeringsprograms skjerm vise deg, og den kan ikke en sletting av to byter fjerne.

Her ligger en viktig nyanse: konfigurasjonsleseren til OpenVPN hopper faktisk over en UTF-8-byteordensmarkering i starten av en fil, slik 2.6-konfigurasjonsleseren viser. Den toleransen gjelder nettopp den markeringen, og den gjør ingenting for en UTF-16-fil hvis bokstaver er polstret med nuller. Å behandle de to markeringene som samme problem er den andre halvdelen av myten.

Konvertering er lagre som, ikke slette

Ta vare på en urørt kopi av operatørens original før du gjør noe, og arbeid på en egen fil. En profil kan inneholde en privat nøkkel eller kontomateriale, så kopien er både tilbakerullingen og referansen din.

Utfør deretter en ekte kodingskonvertering, enten via redigeringsprogrammets eksplisitte koding-meny eller med et konverteringsverktøy som oppgir inn- og utkodingen:

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

Bekreft resultatet i stedet for å stole på kommandoens utgangsstatus. Konverteringen bør bevare hvert direktiv, og den må bevare enhver innebygd sertifikat- eller nøkkelblokk byte for byte innenfor markørene sine. Å pakke PEM-data inn på nytt, endre linjeslutt inni en blokk eller omformatere profilen under konverteringen skaper et nytt problem mens det gamle løses.

Pek klienten eller tjenesten mot den konverterte filen og se på den første feilen den rapporterer. Hvis det sammenblandede tegnet er borte, er kodingsarbeidet ferdig, og alt som feiler etterpå, er et annet spørsmål.

Hva en rettet koding ikke retter

Koding bestemmer hvordan tekst leses; den sier ingenting om hvorvidt alternativene er gyldige for klienten foran deg. En profil eksportert for en annen implementasjon kan tolkes rent og likevel avvises på grunn av et alternativ den kjørende byggingen ikke støtter, eller på grunn av et direktiv hvis argument betyr noe annet i den klienten.

De senere feilene fortjener sin egen undersøkelse: den nøyaktige stavemåten, argumentets syntaks og versjonen som godtar det. Ikke betrakt en vellykket tolkning som en vellykket profil.

Hold undersøkelsen lokal mens du holder på. Offentlige nettkontverterere og innlimte hex-dumper er et dårlig sted for en fil som kan inneholde en privat nøkkel, fordi kodingsproblemet er lett å rette og en lekket nøkkel ikke er det.