OpenVPN refuzon rreshtin e parë? Skedari është ndoshta UTF-16

Gabimi tregon rreshtin e parë të një skedari .ovpn dhe citon diçka që duket si shkronja të përziera atje ku duhet të jetë client. Skedari hapet pa problem në redaktuesin tuaj, rreshti i parë lexon client, dhe direktiva është krejt e zakonshme. Të dy vëzhgimet janë të vërteta, sepse redaktuesi i dekodon bajtët dhe klienti nuk e bën. Ajo që po shihni është pothuajse gjithmonë një problem kodimi, jo një problem sintakse.

Miti: redaktuesi ju tregon skedarin

Një redaktues teksti i dekodon bajtët në karaktere me një kodim që ose e zbulon ose e merr me mend. Kur merr me mend UTF-16, skedari duket përsosur në ekran ndërsa bajtët poshtë tij janë çifte, me një bajt zero pas çdo shkronje latine. OpenVPN i lexon këta bajtë si karaktere, dhe mospërputhja shfaqet në direktivën e parë që përpiqet ta analizojë.

Pra rreshti i dukshëm dhe rreshti i dorëzuar janë dy gjëra të ndryshme. Fshirja e karaktereve të çuditshme që shihni është një ndryshim në shfaqje, jo në kodim, dhe analiza tjetër dështon për të njëjtën arsye me një mesazh pak më ndryshe. Kjo është arsyeja pse ndjekja e simbolit në gabim nuk çon kurrë askund. Bajtët janë të gabuar në burim, dhe çdo lexues më poshtë merr me mend të njëjtën sekuencë të thyer.

Vlen të njihet forma konkrete e dështimit, sepse është diagnostikues në një mënyrë të veçantë. Një simbol pikërisht në fillim të skedarit, në një profil që përndryshe ka punuar në makina të tjera, është çështje renditjeje bajtësh dhe jo fjalori.

Çfarë thonë në të vërtetë bajtët e parë

Lexoni bajtët, jo karakteret. Dy komanda të vogla e zgjidhin çështjen brenda sekondash, dhe asnjëra nuk kërkon hapjen e skedarit në një aplikacion që mund ta ndryshojë:

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

Modeli që kërkoni është një çift bajtësh fillestarë të ndjekur nga tekst në të cilin çdo bajt i dytë është zero. FF FE tregon UTF-16 little-endian, FE FF tregon big-endian, dhe EF BB BF tregon UTF-8 me shenjë renditjeje bajtësh. Një skedar normal UTF-8 pa shenjë fillon drejtpërdrejt me bajtin e shkronjës së parë.

Bajtët zero midis shkronjave janë treguesi kryesor. Në UTF-16 little-endian fjala client zë dymbëdhjetë bajtë në vend të gjashtë, sepse çdo karakter ASCII ndiqet nga një zero. Atë strukturë ekrani i një redaktuesi nuk mund t'jua tregojë, dhe atë nuk mund ta heqë një fshirje prej dy bajtësh.

Këtu ka një nuancë të rëndësishme: lexuesi i konfigurimit të OpenVPN me të vërtetë anashkalon një shenjë renditjeje bajtësh UTF-8 në fillim të skedarit, siç tregon lexuesi i konfigurimit 2.6. Ajo tolerancë është specifike për atë shenjë, dhe nuk bën asgjë për një skedar UTF-16 shkronjat e të cilit janë mbushur me zero. Trajtimi i dy shenjave si i njëjti problem është gjysma e dytë e mitit.

Konvertimi është ruaj si, jo fshirje

Ruani një kopje të paprekur të origjinalit të operatorit përpara se të bëni çdo gjë, dhe punoni në një skedar të veçantë. Një profil mund të përmbajë një çelës privat ose material llogarie, ndaj kopja është edhe kthimi juaj prapa edhe referenca juaj.

Pastaj kryeni një konvertim të vërtetë kodimi, ose përmes menusë së qartë të kodimit të redaktuesit, ose me një konvertues që deklaron kodimin hyrës dhe dalës:

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

Verifikoni rezultatin në vend që të mbështeteni në statusin e daljes së komandës. Konvertimi duhet të ruajë çdo direktivë, dhe duhet të ruajë çdo bllok certifikate ose çelësi të integruar bajt për bajt brenda shenjave të tij. Rimbështjellja e të dhënave PEM, ndryshimi i mbarimeve të rreshtave brenda një blloku ose riformatimi i profilit gjatë konvertimit krijon një problem të ri ndërsa rregullon të vjetrin.

Drejtojeni klientin ose shërbimin te skedari i konvertuar dhe shikoni gabimin e parë që raporton. Nëse simboli i përzier ka humbur, puna e kodimit ka mbaruar, dhe çdo gjë që dështon më pas është një çështje tjetër.

Çfarë nuk rregullon një kodim i rregulluar

Kodimi përcakton si lexohet teksti; nuk thotë asgjë për atë nëse opsionet janë të vlefshme për klientin përpara jush. Një profil i eksportuar për një implementim tjetër mund të analizohet pastër dhe megjithatë të refuzohet për një opsion që ndërtimi që po ekzekutohet nuk e mbështet, ose për një direktivë argumenti i së cilës do të thotë diçka tjetër në atë klient.

Ato gabime të mëvonshme meritojnë hetimin e tyre: drejtshkrimin e saktë, sintaksën e argumentit dhe versionin që e pranon. Mos e trajtoni një analizë të suksesshme si një profil të suksesshëm.

Mbajeni hetimin lokal ndërsa merreni me të. Konvertuesit publikë në internet dhe hedhjet hex të ngjitura janë një vend i keq për një skedar që mund të përmbajë një çelës privat, sepse problemi i kodimit rregullohet lehtë dhe një çelës i rrjedhur jo.