Kas OpenVPN keeldub esimesest reast? Fail on tõenäoliselt UTF-16

Viga osutab .ovpn-faili esimesele reale ja tsiteerib midagi, mis näeb välja nagu segamini aetud tähed kohas, kus peaks olema client. Fail avaneb redaktoris ilusti, esimene rida loeb client ja direktiiv on täiesti tavaline. Mõlemad tähelepanekud on tõesed, sest redaktor dekodeerib baidid ja klient mitte. See, mida te näete, on peaaegu alati kodeeringu probleem, mitte süntaksi probleem.

Müüt: redaktor näitab teile faili

Tekstiredaktor dekodeerib baidid tähemärkideks kodeeringuga, mille ta kas tuvastab või oletab. Kui ta oletab UTF-16, näeb fail ekraanil täiuslik välja, samal ajal kui all olevad baidid on paarid, iga ladina tähe järel on nullbait. OpenVPN loeb neid baite tähemärkidena ja lahknevus ilmneb esimese direktiivi juures, mida ta proovib parsida.

Seega nähtav rida ja tarnitud rida on kaks erinevat asja. Nähtavate kummaliste tähemärkide kustutamine on muudatus kuvamises, mitte kodeeringus, ja järgmine parsimine ebaõnnestub samal põhjusel veidi teistsuguse teatega. Sellepärast ei vii veas oleva märgi tagaajamine kunagi kuhugi. Baidid on allikas valed ja iga järgnev lugeja oletab sama katkist jada.

Tõrke konkreetset kuju tasub ära tunda, sest see on omamoodi diagnostiline. Märk faili päris alguses, profiilis, mis on muidu teistes masinates töötanud, on baitide järjekorra, mitte sõnavara küsimus.

Mida esimesed baidid tegelikult ütlevad

Lugege baite, mitte tähemärke. Kaks väikest käsku selgitavad selle sekunditega ja kumbki ei nõua faili avamist rakenduses, mis võiks seda muuta:

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

Muster, mida otsite, on paar algbaite, millele järgneb tekst, kus iga teine bait on null. FF FE tähistab UTF-16 little-endian, FE FF big-endian ja EF BB BF UTF-8 koos baitide järjekorra märgiga. Tavaline UTF-8-fail ilma märgita algab otse esimese tähe baidiga.

Nullbaidid tähtede vahel on vihje. UTF-16 little-endianis võtab sõna client kaksteist baiti kuue asemel, sest iga ASCII-tähemärgi järel on null. Seda struktuuri ei saa redaktori ekraan teile näidata ja seda ei suuda kahe baidi kustutamine kõrvaldada.

Siin on oluline nüanss: OpenVPN-i konfiguratsioonilugeja jätab tõepoolest vahele UTF-8 baitide järjekorra märgi faili alguses, nagu näitab konfiguratsioonilugeja 2.6. See sallivus kehtib just selle märgi kohta ega tee midagi UTF-16-faili puhul, mille tähed on nullidega täidetud. Kahe märgi käsitlemine sama probleemina on müüdi teine pool.

Teisendamine on salvesta-nimena, mitte kustutamine

Enne millegi tegemist hoidke operaatori originaalist puutumata koopiat ja töötage eraldi failiga. Profiil võib sisaldada privaatvõtit või konto materjali, seega on koopia nii teie tagasitee kui ka viide.

Seejärel tehke tegelik kodeeringu teisendus, kas redaktori selgesõnalise kodeeringumenüü kaudu või muunduriga, mis märgib ära sisend- ja väljundkodeeringu:

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

Kontrollige tulemust, selle asemel et usaldada käsu väljumisolekut. Teisendus peaks säilitama iga direktiivi ja peab säilitama iga manustatud sertifikaadi- või võtmebloki bait baidi haaval oma märgiste sees. PEM-andmete ümbermurdmine, reavahetuste muutmine bloki sees või profiili ümbervormindamine teisendamise ajal loob uue probleemi, samal ajal kui vana parandatakse.

Suunake klient või teenus teisendatud failile ja vaadake esimest viga, millest see teatab. Kui segamini aetud märk on kadunud, on kodeerimistöö tehtud ja kõik, mis pärast seda ebaõnnestub, on juba teine küsimus.

Mida parandatud kodeering ei paranda

Kodeering määrab, kuidas teksti loetakse; see ei ütle midagi selle kohta, kas valikud on teie ees oleva kliendi jaoks kehtivad. Mõne teise implementatsiooni jaoks eksporditud profiil võib puhtalt parsida ja siiski tagasi lükata valiku tõttu, mida jooksev build ei toeta, või direktiivi tõttu, mille argument tähendab selles kliendis midagi muud.

Need hilisemad vead väärivad oma uurimist: täpne kirjapilt, argumendi süntaks ja versioon, mis selle vastu võtab. Ärge pidage õnnestunud parsimist õnnestunud profiiliks.

Hoidke uurimine kohalikuna, kuni sellega tegelete. Avalikud veebipõhised muundurid ja kleepitud hex-dumpid on halb koht faili jaoks, mis võib sisaldada privaatvõtit, sest kodeeringuprobleemi on lihtne parandada ja lekkinud võtit mitte.