OpenVPN odmieta prvý riadok? Súbor je pravdepodobne v UTF-16

Chyba ukazuje na prvý riadok súboru .ovpn a cituje niečo, čo vyzerá ako pomiešané písmená tam, kde má byť client. Súbor sa v editore otvára bez problémov, prvý riadok znie client a direktíva je úplne obyčajná. Obe pozorovania platia, pretože editor bajty dekóduje a klient nie. To, čo vidíte, je takmer vždy problém kódovania, nie problém syntaxe.

Mýtus: editor vám súbor ukazuje

Textový editor dekóduje bajty na znaky pomocou kódovania, ktoré buď zistí, alebo odhadne. Keď odhadne UTF-16, súbor vyzerá na obrazovke dokonale, pričom bajty pod ním sú dvojice a za každým latinským písmenom nasleduje nulový bajt. OpenVPN číta tieto bajty ako znaky a nesúlad sa prejaví pri prvej direktíve, ktorú sa pokúsi spracovať.

Takže viditeľný riadok a dodaný riadok sú dve rôzne veci. Zmazanie podivných znakov, ktoré vidíte, je zmena zobrazenia, nie kódovania, a ďalšie spracovanie zlyhá z rovnakého dôvodu s mierne odlišnou správou. Preto honba za znakom z chyby stále nikam nevedie. Bajty sú chybné už v zdroji a každý ďalší čitateľ hádá rovnakú poškodenú postupnosť.

Konkrétnu podobu zlyhania stojí za to rozpoznať, pretože je špecificky diagnostická. Znak na samom začiatku súboru v profile, ktorý inde na iných strojoch fungoval, je otázka poradia bajtov, nie slovnej zásoby.

Čo prvé bajty skutočne hovoria

Čítajte bajty, nie znaky. Dva malé príkazy to vyriešia za sekundy a ani jeden nevyžaduje otvárať súbor v aplikácii, ktorá by ho mohla zmeniť:

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

Vzor, ktorý hľadáte, je dvojica úvodných bajtov nasledovaná textom, v ktorom je každý druhý bajt nulový. FF FE označuje UTF-16 little-endian, FE FF big-endian a EF BB BF UTF-8 so značkou poradia bajtov. Obyčajný súbor UTF-8 bez značky začína priamo bajtom prvého písmena.

Nulové bajty medzi písmenami sú vodítko. V UTF-16 little-endian zaberá slovo client dvanásť bajtov namiesto šiestich, pretože za každým znakom ASCII nasleduje nula. Takúto štruktúru vám obrazovka editora neukáže a zmazanie dvoch bajtov ju neodstráni.

Je tu dôležitý rozdiel: čítačka konfigurácie OpenVPN skutočne preskakuje značku poradia bajtov UTF-8 na začiatku súboru, ako ukazuje čítačka konfigurácie 2.6. Táto tolerancia platí práve pre túto značku a nič neurobí pre súbor UTF-16, ktorého písmená sú preložené nulami. Považovať obe značky za ten istý problém je druhá polovica mýtu.

Konverzia je uložiť ako, nie zmazať

Predtým, než čokoľvek urobíte, uložte nedotknutú kópiu operátorovho originálu a pracujte na samostatnom súbore. Profil môže obsahovať súkromný kľúč alebo údaje účtu, takže kópia je zároveň vaša cesta späť aj vaša referencia.

Potom vykonajte skutočnú konverziu kódovania, buď cez výslovnú ponuku kódovania v editore, alebo pomocou prevodníka, ktorý uvádza vstupné a výstupné kódovanie:

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

Overte výsledok, namiesto toho, aby ste dôverovali návratovému kódu príkazu. Konverzia by mala zachovať každú direktívu a musí zachovať každý vložený blok certifikátu alebo kľúča bajt po bajte v jeho značkách. Prebaľovanie údajov PEM, zmena koncov riadkov v bloku alebo preformátovanie profilu počas konverzie vytvára nový problém, zatiaľ čo opravuje starý.

Namierte klienta alebo službu na skonvertovaný súbor a pozrite sa na prvú chybu, ktorú ohlási. Ak pomiešaný znak zmizol, práca s kódovaním je hotová a čokoľvek, čo potom zlyhá, je iná otázka.

Čo opravené kódovanie neopraví

Kódovanie určuje, ako sa text číta; nehovorí nič o tom, či sú voľby platné pre klienta pred vami. Profil exportovaný pre inú implementáciu sa môže čisto spracovať a napriek tomu byť odmietnutý kvôli voľbe, ktorú bežiaci build nepodporuje, alebo kvôli direktíve, ktorej argument v tom klientovi znamená niečo iné.

Tie neskoršie chyby si zaslúžia vlastné vyšetrovanie: presný pravopis, syntax argumentu a verziu, ktorá ho prijíma. Nepovažujte úspešné spracovanie za úspešný profil.

Vyšetrovanie udržujte lokálne, kým sa tým zaoberáte. Verejné online prevodníky a vložené hex výpisy sú zlé miesto pre súbor, ktorý môže obsahovať súkromný kľúč, pretože problém s kódovaním sa opravuje ľahko, kdežto uniknutý kľúč nie.