Avviser OpenVPN den første linja? Fila er truleg UTF-16

Feilen peikar på den første linja i ei .ovpn-fil og siterer noko som ser ut som samanblanda bokstavar der client skulle stå. Fila opnar fint i teksthandsamaren din, den første linja les client, og direktivet er heilt vanleg. Begge observasjonane stemmer, fordi teksthandsamaren dekodar byta og klienten ikkje gjer det. Det du ser, er nesten alltid eit kodingsproblem, ikkje eit syntaksproblem.

Myten: teksthandsamaren viser deg fila

Ein teksthandsamar dekodar byt til teikn med ein koding han anten oppdagar eller gissar på. Når han gissar på UTF-16, ser fila perfekt ut på skjermen medan byta under er par, med ein nullbyte etter kvar latinsk bokstav. OpenVPN les desse byta som teikn, og avviket viser seg ved det første direktivet det prøver å tolke.

Så den synlege linja og den leverte linja er to ulike ting. Å sletta dei rare teikna du ser, er ei endring i visinga, ikkje i kodinga, og neste tolking feilar av same grunn med eit litt annan melding. Difor fører jakta på teiknet i feilen aldri nokon stad. Byta er feil ved kjelda, og kvar lesar lenger nede gissar på den same øydelagde sekvensen.

Den konkrete forma for feilen er verdt å kjenna att, fordi han er diagnostisk på ein bestemt måte. Eit teikn heilt i starten av fila, i ein profil som elles har fungert på andre maskinar, er eit spørsmål om byteorden snarare enn om ordforråd.

Kva dei første byta faktisk seier

Les byta i staden for teikna. To små kommandoar avgjer det på sekund, og ingen av dei krev at du opnar fila i eit program som kan endra henne:

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

Mønsteret du ser etter, er eit par innleiande byt etterfølgd av tekst der kvar andre byte er null. FF FE markerer UTF-16 little-endian, FE FF markerer big-endian, og EF BB BF markerer UTF-8 med ein byteordensmarkering. Ei vanleg UTF-8-fil utan merke startar rett med byten til den første bokstaven.

Nullbyta mellom bokstavane er det avgjerande teiknet. I UTF-16 little-endian tek ordet client tolv byt i staden for seks, fordi kvart ASCII-teikn vert følgd av ein null. Den strukturen kan ikkje skjermen til ein teksthandsamar visa deg, og han kan ikkje ei sletting av to byt fjerna.

Her ligg ein viktig nyanse: konfigurasjonslesaren til OpenVPN hoppar faktisk over ein UTF-8-byteordensmarkering i starten av ei fil, slik 2.6-konfigurasjonslesaren viser. Den toleransen gjeld nettopp den markeringa, og han gjer ingenting for ei UTF-16-fil med bokstavar som er fylte med nullar. Å handsama dei to markeringane som same problemet er den andre halvdelen av myten.

Konvertering er lagre som, ikkje sletting

Ta vare på ein urørd kopi av originalen til operatøren før du gjer noko, og arbeid på ei eiga fil. Ein profil kan innehalda ein privat nøkkel eller kontomateriale, så kopien er både tilbakerullingspunktet og referansen din.

Utfør deretter ein ekte kodingskonvertering, anten via den eksplisitte kodingmenyen til teksthandsamaren eller med eit konverteringsverktøy som oppgir inn- og utkodinga:

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

Stadfest resultatet i staden for å stola på utgangsstatusen til kommandoen. Konverteringa bør bevara kvart direktiv, og ho må bevara ein kvar innebygd sertifikat- eller nøkkelblokk byte for byte innanfor markørane sine. Å pakka PEM-data inn på nytt, endra linjeslutt inne i ei blokk eller omformatera profilen under konverteringa skaper eit nytt problem medan det gamle vert løyst.

Peik klienten eller tenesta mot den konverterte fila og sjå på den første feilen ho rapporterer. Viss det samanblanda teiknet er borte, er kodingsarbeidet ferdig, og alt som feilar etterpå, er eit anna spørsmål.

Kva ei retta koding ikkje rettar

Koding avgjer korleis tekst vert lesen; ho seier ingenting om alternativa er gyldige for klienten framom deg. Ein profil eksportert for ein annan implementasjon kan tolkast reint og likevel verta avvist på grunn av eit alternativ den køyrande bygginga ikkje støttar, eller på grunn av eit direktiv der argumentet tyder noko anna i den klienten.

Dei seinare feila fortener si eiga undersøking: den nøyaktige stavemåten, syntaksen til argumentet og versjonen som godtek det. Ikkje sjå på ei vellukka tolking som ein vellukka profil.

Hald undersøkinga lokal medan du held på. Offentlege nettkontverterar og innlimte hex-dumpar er ein dårleg stad for ei fil som kan innehalda ein privat nøkkel, fordi kodingsproblemet er lett å retta og ein leken nøkkel ikkje er det.