Avvisar OpenVPN den första raden? Filen är troligen UTF-16

Felet pekar på den första raden i en .ovpn-fil och citerar något som ser ut som sammanblandade bokstäver där client borde stå. Filen öppnas fint i din editor, den första raden läses som client, och direktivet är helt vanligt. Båda iakttagelserna stämmer, eftersom editorn avkodar byten och klienten inte gör det. Det du ser är nästan alltid ett kodningsproblem, inte ett syntaxproblem.

Myten: editorn visar dig filen

En texteditor avkodar byten till tecken med en kodning som den antingen upptäcker eller gissar. När den gissar på UTF-16 ser filen perfekt ut på skärmen medan byten under är par, med en nollbyte efter varje latinsk bokstav. OpenVPN läser dessa byten som tecken, och avvikelsen syns vid det första direktiv det försöker tolka.

Så den synliga raden och den levererade raden är två olika saker. Att radera de konstiga tecknen du ser ändrar visningen, inte kodningen, och nästa tolkning misslyckas av samma skäl med ett något annat meddelande. Därför leder jakten på tecknet i felet aldrig någonstans. Byten är fel vid källan, och varje läsare längre fram gissar på samma trasiga sekvens.

Den konkreta formen av felet är värd att känna igen, eftersom den är diagnostisk på ett särskilt sätt. En token allra först i filen, i en profil som annars har fungerat på andra maskiner, är en fråga om byteordning snarare än om ordförråd.

Vad de första byten faktiskt säger

Läs byten i stället för tecken. Två små kommandon avgör saken på sekunder, och ingen av dem kräver att filen öppnas i ett program som kan ändra den:

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

Mönstret du letar efter är ett par inledande byten följt av text där varannan byte är noll. FF FE markerar UTF-16 little-endian, FE FF markerar big-endian, och EF BB BF markerar UTF-8 med en byteordningsmarkering. En vanlig UTF-8-fil utan markering börjar direkt med den första bokstavens byte.

Nollbyten mellan bokstäverna är ledtråden. I UTF-16 little-endian tar ordet client tolv byten i stället för sex, eftersom varje ASCII-tecken följs av en nolla. Den strukturen kan en editors skärm inte visa dig, och den kan en radering av två byten inte ta bort.

Här finns en viktig nyans: OpenVPN:s konfigurationsläsare hoppar faktiskt över en UTF-8-byteordningsmarkering i början av en fil, som 2.6-konfigurationsläsaren visar. Den toleransen gäller just den markeringen, och den gör ingenting för en UTF-16-fil vars bokstäver är utfyllda med nollor. Att behandla de två markeringarna som samma problem är den andra halvan av myten.

Konvertering är spara som, inte radera

Behåll en orörd kopia av operatörens original innan du gör något, och arbeta på en separat fil. En profil kan innehålla en privat nyckel eller kontomaterial, så kopian är både din återställning och din referens.

Utför sedan en riktig kodningskonvertering, antingen via editorns uttryckliga kodningsmeny eller med ett konverteringsverktyg som anger sin in- och utkodning:

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

Verifiera resultatet i stället för att lita på kommandots utgångsstatus. Konverteringen bör bevara varje direktiv, och den måste bevara varje inbäddat certifikat- eller nyckelblock byte för byte inom sina markeringar. Att rada om PEM-data, ändra radslut inne i ett block eller omformatera profilen under konverteringen skapar ett nytt problem medan det gamla åtgärdas.

Rikta klienten eller tjänsten mot den konverterade filen och titta på det första fel den rapporterar. Om det sammanblandade tecknet är borta är kodningsarbetet klart, och allt som misslyckas därefter är en annan fråga.

Vad en åtgärdad kodning inte åtgärdar

Kodning avgör hur text läses; den säger ingenting om huruvida alternativen är giltiga för klienten framför dig. En profil exporterad för en annan implementation kan tolkas rent och ändå avvisas på grund av ett alternativ som den körande byggen inte stöder, eller på grund av ett direktiv vars argument betyder något annat i den klienten.

De senare felen förtjänar sin egen undersökning: den exakta stavningen, argumentets syntax och den version som accepterar det. Betrakta inte en lyckad tolkning som en lyckad profil.

Håll undersökningen lokal medan du håller på. Offentliga onlinekonverterare och inklistrade hex-dumpar är en dålig plats för en fil som kan innehålla en privat nyckel, eftersom kodningsproblemet är lätt att åtgärda och en läckt nyckel inte är det.