OpenVPN odmítá první řádek? Soubor je nejspíš v UTF-16

Chyba ukazuje na první řádek souboru .ovpn a cituje něco, co vypadá jako pomíchaná písmena tam, kde má být client. Soubor se v editoru otevírá bez problémů, první řádek zní client a direktiva je zcela obyčejná. Obě pozorování platí, protože editor bajty dekóduje a klient ne. To, co vidíte, je téměř vždy problém kódování, nikoli syntaxe.

Mýtus: editor vám soubor ukazuje

Textový editor dekóduje bajty na znaky pomocí kódování, které buď zjistí, nebo odhadne. Když odhadne UTF-16, soubor vypadá na obrazovce dokonale, zatímco bajty pod ním jsou dvojice, za každým latinským písmenem následuje nulový bajt. OpenVPN čte tyto bajty jako znaky a nesoulad se projeví u první direktivy, kterou se pokusí zpracovat.

Takže viditelný řádek a dodaný řádek jsou dvě různé věci. Smazání podivných znaků, které vidíte, je změna zobrazení, nikoli kódování, a další zpracování selže ze stejného důvodu s mírně odlišnou zprávou. Proto honba za znakem z chyby neustále nikam nevede. Bajty jsou vadné už ve zdroji a každý další čtenář hádá stejnou poškozenou posloupnost.

Konkrétní podobu selhání stojí za to rozpoznat, protože je specificky diagnostická. Znak na samém začátku souboru v profilu, který jinde na jiných strojích fungoval, je otázka pořadí bajtů, nikoli slovní zásoby.

Co první bajty skutečně říkají

Čtěte bajty, ne znaky. Dvě malé příkazy to vyřeší během sekund a ani jeden nevyžaduje otevírat soubor v aplikaci, která by ho mohla změnit:

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

Vzor, který hledáte, je dvojice úvodních bajtů následovaná textem, v němž je každý druhý bajt nulový. FF FE označuje UTF-16 little-endian, FE FF big-endian a EF BB BF UTF-8 se značkou pořadí bajtů. Obyčejný soubor UTF-8 bez značky začíná přímo bajtem prvního písmene.

Nulové bajty mezi písmeny jsou vodítko. V UTF-16 little-endian zabírá slovo client dvanáct bajtů místo šesti, protože za každým znakem ASCII následuje nula. Takovou strukturu vám obrazovka editoru neukáže a smazání dvou bajtů ji neodstraní.

Je tu důležitý rozdíl: čtečka konfigurace OpenVPN skutečně přeskakuje značku pořadí bajtů UTF-8 na začátku souboru, jak ukazuje čtečka konfigurace 2.6. Tato tolerance platí právě pro tuto značku a nic neudělá pro soubor UTF-16, jehož písmena jsou proložena nulami. Považovat obě značky za stejný problém je druhá polovina mýtu.

Převod je uložit jako, ne smazat

Než cokoli uděláte, uložte nedotčenou kopii operátorova originálu a pracujte na samostatném souboru. Profil může obsahovat soukromý klíč nebo údaje účtu, takže kopie je zároveň vaše cesta zpět i vaše reference.

Potom proveďte skutečný převod kódování, buď přes výslovnou nabídku kódování v editoru, nebo pomocí převodníku, který uvádí vstupní a výstupní kódování:

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

Ověřte výsledek, místo abyste věřili návratovému kódu příkazu. Převod musí zachovat každou direktivu a musí zachovat každý vložený blok certifikátu nebo klíče bajt po bajtu uvnitř jeho značek. Přenábalení dat PEM, změna konců řádků uvnitř bloku nebo přeformátování profilu během převodu vytváří nový problém, zatímco opravuje starý.

Namiřte klienta nebo službu na převedený soubor a podívejte se na první chybu, kterou ohlásí. Pokud pomíchaný znak zmizel, práce s kódováním je hotová a cokoli, co pak selže, je jiná otázka.

Co opravené kódování neopraví

Kódování určuje, jak se text čte; neříká nic o tom, zda jsou volby platné pro klienta před vámi. Profil exportovaný pro jinou implementaci se může čistě zpracovat a přesto být odmítnut kvůli volbě, kterou běžící build nepodporuje, nebo kvůli direktivě, jejíž argument v tom klientovi znamená něco jiného.

Tyto pozdější chyby si zaslouží vlastní vyšetřování: přesný pravopis, syntaxi argumentu a verzi, která ho přijímá. Nepovažujte úspěšné zpracování za úspěšný profil.

Vyšetřování udržujte lokální. Veřejné online převodníky a vložené hex výpisy jsou špatné místo pro soubor, který může obsahovat soukromý klíč, protože problém s kódováním se opravuje snadno, kdežto uniklý klíč ne.