OpenVPNek lehen lerroa baztertzen du? Fitxategia ziurrenik UTF-16 da

Erroreak .ovpn fitxategi baten lehen lerroa seinalatzen du eta client egon beharko lukeen tokian hizki nahasiek ematen duten zerbait aipatzen du. Fitxategia ondo irekitzen da zure editorean, lehen lerroak client irakurtzen du, eta direktiba erabat arrunta da. Bi behaketak egiazkoak dira, editoreak byteak deskodetzen dituelako eta bezeroak ez. Ikusten ari zarena ia beti kodeketa arazoa da, ez sintaxi arazoa.

Mitoa: editoreak fitxategia erakusten dizu

Testu editore batek byteak karaktere bihurtzen ditu detektatzen edo asmatzen duen kodeketa batekin. UTF-16 asmatzen duenean, fitxategia ezin hobea dirudi pantailan, azpiko byteak bikoteak diren bitartean, letra latindar bakoitzaren ondoren zero byte bat baitago. OpenVPN byte horiek karaktere gisa irakurtzen ditu, eta desadostasuna analizatzen saiatzen den lehen direktiban agertzen da.

Beraz, ikusgai dagoen lerroa eta entregatutako lerroa bi gauza desberdin dira. Ikusten dituzun karaktere arraroak ezabatzea bistaratzearen aldaketa da, ez kodeketarena, eta hurrengo analisiak huts egiten du arrazoi beragatik mezu pixka bat desberdinarekin. Horregatik erroreko ikurraren atzetik ibiltzeak ez du inoiz inora eramaten. Byteak oker daude iturburuan, eta beherago dagoen irakurle bakoitzak sekuentzia hautsia bera asmatzen du.

Hutsaren forma zehatza ezagutzea merezi du, modu jakin batean diagnostikoa baita. Fitxategiaren hasieran bertan dagoen ikurra, beste makina batzuetan bestela funtzionatu duen profilean, byte ordenaren kontua da, ez hiztegiaren kontua.

Zer esaten dute benetan lehen byteek

Irakurri byteak, ez karaktereak. Bi komando txikik segundo gutxitan argitzen dute, eta batek ere ez du fitxategia alda dezakeen aplikazio batean irekitzea eskatzen:

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

Bilatzen ari zaren eredua hasierako byte pare bat da, eta ondoren testua non bigarren byte bakoitza zero den. FF FE-k UTF-16 little-endian adierazten du, FE FF-k big-endian, eta EF BB BF-k UTF-8 byte ordenaren markarekin. Markarik gabeko UTF-8 fitxategi arrunt bat lehen letraren bytearekin hasten da zuzenean.

Letren arteko zero byteak dira arrastoa. UTF-16 little-endianen client hitzak hamabi byte hartzen ditu sei beharrean, ASCII karaktere bakoitzaren ondoren zero bat baitago. Egitura hori ezin dizu editore baten pantailak erakutsi, eta bi byteko ezabaketa batek ezin du kendu.

Hemen ñabardura garrantzitsu bat dago: OpenVPNren konfigurazio irakurgailuak fitxategi baten hasierako UTF-8 byte ordenaren marka gainditzen du, 2.6 konfigurazio irakurgailuak erakusten duen bezala. Tolerantzia hori marka horri dagokio soilik, eta ez du ezer egiten letrak zeroz beteta dituen UTF-16 fitxategi batentzat. Bi markak arazo berberatzat hartzea mitoaren bigarren erdia da.

Bihurtzea gisa gordetzea da, ez ezabatzea

Ezer egin aurretik, gorde operadorearen jatorrizkoaren kopia ukitu gabea eta lan egin fitxategi bereizi batean. Profileak gako pribatu bat edo kontu materiala izan dezake, beraz kopia bai atzera egiteko bidea bai zure erreferentzia da.

Gero egin kodeketa bihurketa benetakoa, bai editorearen kodeketa menu esplizituaren bidez, bai sarrera eta irteera kodeketa adierazten duen bihurtzaile batekin:

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

Egiaztatu emaitza, komandoaren irteera-egoeran fidatu beharrean. Bihurketak direktiba guztiak mantendu behar ditu, eta edozein ziurtagiri edo gako bloke txertatu bytez byte mantendu behar du bere marken barruan. PEM datuak berriro biltzeak, bloke baten barruko lerro-amaierak aldatzeak edo bihurketan zehar profila birformateatzeak arazo berri bat sortzen du zaharra konpontzen ari den bitartean.

Zuzendu bezeroa edo zerbitzua bihurtutako fitxategira eta begiratu jakinarazten duen lehen errorea. Ikur nahasia desagertu bada, kodeketa lana eginda dago eta ondoren huts egiten duen edozer beste kontu bat da.

Kodeketa konponduak konpontzen ez duena

Kodeketak zehazten du testua nola irakurtzen den; ez du ezer esaten aurrean duzun bezeroarentzat aukerak baliozkoak diren ala ez. Beste inplementazio baterako esportatutako profileak garbi analiza daiteke eta hala ere baztertu daiteke exekutatzen ari den bertsioak onartzen ez duen aukera batengatik, edo argumentuak bezero horretan beste zerbait esan nahi duen direktiba batengatik.

Geroagoko errore horiek beren ikerketa merezi dute: idazkera zehatza, argumentuaren sintaxia eta onartzen duen bertsioa. Ez ezazu analisi arrakastatsua profil arrakastatsutzat har.

Eduki ikerketa tokian tokikoa horretan ari zaren bitartean. Lineako bihurtzaile publikoak eta itsatsitako hex dumpak leku txarra dira gako pribatu bat izan dezakeen fitxategi batentzat, kodeketa arazoa erraza baita konpontzen eta filtratutako gako bat ez.