OpenVPN odbija prvi red? Datoteka je vjerovatno UTF-16

Greška pokazuje na prvi red .ovpn datoteke i citira nešto što izgleda kao izmiješana slova tamo gdje bi trebalo stajati client. Datoteka se bez problema otvara u vašem uređivaču, prvi red glasi client, a direktiva je potpuno obična. Oba zapažanja su tačna, jer uređivač dekodira bajtove, a klijent ne. Ono što gledate gotovo je uvijek problem kodiranja, a ne problem sintakse.

Mit: uređivač vam pokazuje datoteku

Tekstualni uređivač dekodira bajtove u znakove kodiranjem koje ili otkrije ili pogodi. Kada pogodi UTF-16, datoteka izgleda savršeno na ekranu dok su bajtovi ispod parovi, s nultim bajtom nakon svakog latiničnog slova. OpenVPN čita te bajtove kao znakove, a nesklad se pojavljuje na prvoj direktivi koju pokuša raščlaniti.

Dakle, vidljivi red i dostavljeni red dvije su različite stvari. Brisanje neobičnih znakova koje vidite promjena je prikaza, a ne kodiranja, i sljedeće raščlanjivanje pada zbog istog razloga uz malo drugačiju poruku. Zato potraga za znakom iz greške stalno vodi nikamo. Bajtovi su pogrešni na izvoru, a svaki čitalac nizvodno pogađa isti pokvareni slijed.

Konkretan oblik kvara vrijedi prepoznati, jer je na specifičan način dijagnostički. Znak na samom početku datoteke, u profilu koji je inače radio na drugim mašinama, pitanje je reda bajtova, a ne rječnika.

Šta prvi bajtovi zapravo govore

Čitajte bajtove, a ne znakove. Dvije male komande rješavaju stvar u sekundama, a nijedna ne zahtijeva otvaranje datoteke u aplikaciji koja bi je mogla promijeniti:

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

Obrazac koji tražite je par vodećih bajtova iza kojih slijedi tekst u kojem je svaki drugi bajt nula. FF FE označava UTF-16 s malim redom bajtova, FE FF veliki, a EF BB BF UTF-8 s oznakom reda bajtova. Obična UTF-8 datoteka bez oznake počinje izravno bajtom prvog slova.

Nulti bajtovi između slova odaju problem. U UTF-16 s malim redom bajtova riječ client zauzima dvanaest bajtova umjesto šest, jer iza svakog ASCII znaka slijedi nula. Tu strukturu ekran uređivača ne može vam pokazati, a brisanje od dva bajta je ne može ukloniti.

Ovdje leži važna nijansa: OpenVPN-ov čitač konfiguracije zaista preskače oznaku reda bajtova UTF-8 na početku datoteke, kako pokazuje čitač konfiguracije 2.6. Ta tolerancija odnosi se upravo na tu oznaku i ne čini ništa za UTF-16 datoteku čija su slova podstavljena nulama. Tretirati dvije oznake kao isti problem druga je polovina mita.

Konverzija je snimi kao, a ne brisanje

Prije bilo čega sačuvajte netaknutu kopiju operaterovog originala i radite na zasebnoj datoteci. Profil može sadržavati privatni ključ ili podatke računa, pa je kopija i vaš povratak i vaša referenca.

Zatim izvršite stvarnu konverziju kodiranja, bilo kroz izričit meni kodiranja u uređivaču, bilo konverterom koji navodi ulazno i izlazno kodiranje:

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

Provjerite rezultat umjesto da vjerujete izlaznom statusu komande. Konverzija mora sačuvati svaku direktivu i mora sačuvati svaki ugrađeni blok certifikata ili ključa bajt po bajt unutar njegovih oznaka. Ponovno umatanje PEM podataka, mijenjanje krajeva redova unutar bloka ili preformatiranje profila tokom konverzije stvara novi problem dok ispravlja stari.

Usmjerite klijenta ili servis na konvertovanu datoteku i pogledajte prvu grešku koju prijavi. Ako je izmiješani znak nestao, posao s kodiranjem je završen i sve što nakon toga padne drugo je pitanje.

Šta ispravljeno kodiranje ne ispravlja

Kodiranje određuje kako se tekst čita; ono ne govori ništa o tome jesu li opcije valjane za klijenta pred vama. Profil izvezen za drugu implementaciju može se čisto raščlaniti i ipak biti odbijen zbog opcije koju pokrenuta verzija ne podržava ili zbog direktive čiji argument u tom klijentu znači nešto drugo.

Te kasnije greške zaslužuju vlastitu istragu: tačan pravopis, sintaksu argumenta i verziju koja ga prihvata. Ne smatrajte uspješno raščlanjivanje uspješnim profilom.

Držite istragu lokalnom. Javni online konverteri i zalijepljeni hex ispisi loše su mjesto za datoteku koja može sadržavati privatni ključ, jer problem kodiranja je lako ispraviti, a procurio ključ nije.