Tatanggihan ba ng OpenVPN ang unang linya? Malamang UTF-16 ang file

Itinuturo ng error ang unang linya ng isang .ovpn file at sinipi ang isang bagay na mukhang magulong mga titik kung saan dapat naroon ang client. Maayos na bumubukas ang file sa iyong editor, binabasa ng unang linya ang client, at ang direktiba ay lubos na karaniwan. Parehong totoo ang dalawang obserbasyon, dahil ine-decode ng editor ang mga byte at hindi ginagawa ito ng kliyente. Ang nakikita mo ay halos palaging problema sa encoding, hindi problema sa syntax.

Ang mito: ipinapakita sa iyo ng editor ang file

Ang text editor ay nagde-decode ng mga byte sa mga karakter gamit ang encoding na nadidetect o nahuhulaan nito. Kapag nahulaan nitong UTF-16, perpekto ang hitsura ng file sa screen habang ang mga byte sa ilalim ay pares, may zero byte pagkatapos ng bawat Latin na titik. Binabasa ng OpenVPN ang mga byte na iyon bilang mga karakter, at lumilitaw ang pagkakaiba sa unang direktiba na sinusubukan nitong i-parse.

Kaya ang nakikitang linya at ang naihatid na linya ay dalawang magkaibang bagay. Ang pagbura sa kakaibang mga karakter na nakikita mo ay pagbabago sa display, hindi sa encoding, at nabibigo ang susunod na pag-parse sa parehong dahilan na may bahagyang ibang mensahe. Iyon ang dahilan kung bakit ang paghabol sa token sa error ay hindi kailanman humahantong kahit saan. Mali ang mga byte sa pinagmulan, at ang bawat mambabasa sa ibaba ay hinuhulaan ang parehong sirang pagkakasunod-sunod.

Karapat-dapat kilalanin ang tiyak na hugis ng pagkabigo, dahil diagnostic ito sa isang partikular na paraan. Ang token sa pinakasimula ng file, sa isang profile na gumana sa ibang mga makina, ay tanong tungkol sa ayos ng byte at hindi tungkol sa bokabularyo.

Ano ba talaga ang sinasabi ng mga unang byte

Basahin ang mga byte sa halip na ang mga karakter. Dalawang maliit na utos ang magpapasya nito sa loob ng ilang segundo, at wala sa kanila ang nangangailangan ng pagbukas ng file sa isang app na maaaring magbago nito:

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

Ang pattern na hinahanap mo ay isang pares ng nangungunang byte na sinusundan ng teksto kung saan ang bawat ikalawang byte ay zero. Ang FF FE ay tumutukoy sa UTF-16 little-endian, ang FE FF ay tumutukoy sa big-endian, at ang EF BB BF ay tumutukoy sa UTF-8 na may byte order mark. Ang ordinaryong UTF-8 file na walang marka ay nagsisimula nang direkta sa byte ng unang titik.

Ang mga zero byte sa pagitan ng mga titik ang pangunahing palatandaan. Sa UTF-16 little-endian ang salitang client ay kumukuha ng labindalawang byte sa halip na anim, dahil ang bawat ASCII na karakter ay sinusundan ng zero. Ang istrukturang iyon ay hindi maipapakita sa iyo ng screen ng editor, at hindi ito maaalis ng pagbura ng dalawang byte.

May mahalagang nuance dito: ang configuration reader ng OpenVPN ay talagang lumalaktaw sa isang UTF-8 byte order mark sa simula ng file, tulad ng ipinapakita ng configuration reader 2.6. Ang pagpaparaya na iyon ay partikular sa markang iyon, at wala itong ginagawa para sa isang UTF-16 file na ang mga titik ay pinalamnan ng mga zero. Ang ituring ang dalawang marka bilang isang problema ay ang ikalawang kalahati ng mito.

Ang pag-convert ay save as, hindi pagbura

Magtabi ng buo at hindi nagalaw na kopya ng orihinal ng operator bago gumawa ng anuman, at magtrabaho sa hiwalay na file. Ang profile ay maaaring maglaman ng pribadong key o materyal ng account, kaya ang kopya ay parehong iyong rollback at iyong sanggunian.

Pagkatapos ay gawin ang tunay na conversion ng encoding, alinman sa pamamagitan ng tahasang menu ng encoding ng editor o gamit ang converter na nagsasaad ng input at output encoding nito:

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

I-verify ang resulta sa halip na magtiwala sa exit status ng utos. Dapat mapanatili ng conversion ang bawat direktiba, at dapat nitong mapanatili ang anumang naka-inline na certificate o key block bawat byte sa loob ng mga marker nito. Ang muling pagbabalot ng PEM data, pagbabago ng line endings sa loob ng block o muling pag-format ng profile habang nagko-convert ay lumilikha ng bagong problema habang inaayos ang luma.

Itutok ang kliyente o serbisyo sa na-convert na file at tingnan ang unang error na iniuulat nito. Kung wala na ang magulong token, tapos na ang gawain sa encoding at anumang bumagsak pagkatapos ay ibang tanong.

Ano ang hindi naaayos ng naayos na encoding

Tinutukoy ng encoding kung paano binabasa ang teksto; wala itong sinasabi tungkol sa kung wasto ang mga opsyon para sa kliyenteng nasa harap mo. Ang profile na na-export para sa ibang implementasyon ay maaaring malinis na ma-parse at tanggihan pa rin dahil sa isang opsyon na hindi sinusuportahan ng tumatakbong build, o dahil sa isang direktiba na ang argumento ay may ibang kahulugan sa kliyenteng iyon.

Ang mga huling error na iyon ay karapat-dapat sa sariling pagsisiyasat: ang eksaktong ispeling, ang syntax ng argumento at ang bersyon na tumatanggap nito. Huwag ituring na matagumpay na profile ang isang matagumpay na pag-parse.

Panatilihing lokal ang pagsisiyasat habang ginagawa ito. Ang mga pampublikong online converter at nakadikit na hex dump ay masamang lugar para sa isang file na maaaring may pribadong key, dahil ang problema sa encoding ay madaling ayusin at ang naiwalang key ay hindi.