Az OpenVPN elutasítja az első sort? A fájl valószínűleg UTF-16

A hiba a .ovpn-fájl első sorára mutat, és olyasmit idéz, ami összekevert betűknek látszik ott, ahol client állna. A fájl hibátlanul megnyílik a szerkesztőjében, az első sor client, és az utasítás teljesen hétköznapi. Mindkét megfigyelés igaz, mert a szerkesztő dekódolja a bájtokat, a kliens pedig nem. Amit lát, az szinte mindig kódolási probléma, nem szintaktikai hiba.

A mítosz: a szerkesztő megmutatja a fájlt

A szövegszerkesztő bájtokat alakít karakterekké egy általa felismert vagy megtippelt kódolással. Ha UTF-16-ot tippel, a fájl tökéletesnek látszik a képernyőn, miközben a mögötte lévő bájtok párok, minden latin betű után egy nulla bájt áll. Az OpenVPN ezeket a bájtokat karakterekként olvassa, és az eltérés az első utasításnál jelenik meg, amelyet megpróbál feldolgozni.

Tehát a látható sor és a kézbesített sor két különböző dolog. A látható furcsa karakterek törlése a megjelenítést változtatja meg, nem a kódolást, és a következő feldolgozás ugyanazon okból hiúsul meg, kicsit más üzenettel. Ezért vezet a hibában szereplő jel követése mindig zsákutcába. A bájtok a forrásnál rosszak, és minden későbbi olvasó ugyanazt a törött sorozatot tippeli.

Érdemes felismerni a hiba konkrét formáját, mert sajátos módon diagnosztikus. Egy jel a fájl legelején, olyan profilban, amely egyébként más gépeken működött, bájt- és nem szókincs kérdése.

Mit mondanak valójában az első bájtok

A bájtokat olvassa, ne a karaktereket. Két kis parancs másodpercek alatt eldönti, és egyik sem igényli a fájl olyan alkalmazásban való megnyitását, amely megváltoztathatja:

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

A keresett minta egy vezető bájtpár, amelyet olyan szöveg követ, amelyben minden második bájt nulla. Az FF FE az UTF-16 little-endian, az FE FF a big-endian, az EF BB BF pedig a bájt-sorrendjelöléssel ellátott UTF-8 jelölése. Egy jelölés nélküli közönséges UTF-8-fájl közvetlenül az első betű bájtjával kezdődik.

A betűk közötti nulla bájtok a legárulkodóbbak. UTF-16 little-endian kódolásban a client szó tizenkét bájtot foglal hat helyett, mert minden ASCII-karaktert nulla követ. Ezt a szerkezetet a szerkesztő megjelenítése nem tudja megmutatni, és két bájt törlése sem távolítja el.

Itt van egy fontos árnyalat: az OpenVPN konfigurációolvasója valóban átugorja a fájl elején lévő UTF-8 bájt-sorrendjelölést, ahogy a 2.6-os konfigurációolvasó mutatja. Ez a türelem pontosan arra a jelölésre vonatkozik, és semmit nem tesz az olyan UTF-16-fájlért, amelynek betűi nullákkal vannak kitöltve. A két jelölést ugyanannak a problémának tekinteni a mítosz második fele.

Az átalakítás mentés másként, nem törlés

Mielőtt bármit tenne, őrizzen meg egy érintetlen másolatot az üzemeltető eredeti példányából, és külön fájlon dolgozzon. A profil tartalmazhat privát kulcsot vagy fiókadatokat, ezért a másolat egyszerre a visszaút és a hivatkozás.

Ezután végezzen valódi kódolásátalakítást, akár a szerkesztő kifejezett kódolásmenüjén keresztül, akár olyan átalakítóval, amely megadja a bemeneti és kimeneti kódolást:

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

Ellenőrizze az eredményt ahelyett, hogy a parancs kilépési állapotára hagyatkozna. Az átalakításnak meg kell őriznie minden utasítást, és minden beágyazott tanúsítvány- vagy kulcsblokkot bájtról bájtra meg kell őriznie a jelölőin belül. A PEM-adatok újratördelése, a sorvégek módosítása egy blokkon belül vagy a profil újraformázása az átalakítás során új problémát teremt, miközben a régit megoldja.

Irányítsa a klienst vagy a szolgáltatást az átalakított fájlra, és nézze meg az első hibát, amelyet jelent. Ha az összekevert jel eltűnt, a kódolási munka kész, és minden, ami ezután meghiúsul, más kérdés.

Mit nem javít meg a javított kódolás

A kódolás meghatározza, hogyan olvasódik a szöveg; semmit nem mond arról, hogy a beállítások érvényesek-e az Ön előtti kliensre. Egy másik megvalósításhoz exportált profil tisztán feldolgozható, és mégis elutasítható egy olyan beállítás miatt, amelyet a futó build nem támogat, vagy egy olyan utasítás miatt, amelynek argumentuma abban a kliensben mást jelent.

Azok a későbbi hibák saját vizsgálatot érdemelnek: a pontos írásmódot, az argumentum szintaxisát és az azt elfogadó verziót. Ne tekintse a sikeres feldolgozást sikeres profilnak.

Tartsa helyben a vizsgálatot, amíg ezzel foglalkozik. A nyilvános online átalakítók és a beillesztett hex-kiírások rossz hely egy olyan fájlnak, amely privát kulcsot tartalmazhat, mert a kódolási probléma könnyen javítható, a kiszivárgott kulcs pedig nem.