Ĉu OpenVPN rifuzas la unuan linion? La dosiero probable estas UTF-16

La eraro montras al la unua linio de .ovpn-dosiero kaj citas ion, kio aspektas kiel miksitaj literoj tie, kie devus esti client. La dosiero malfermiĝas senprobleme en via redaktilo, la unua linio legiĝas kiel client, kaj la direktivo estas tute ordinara. Ambaŭ observoj veras, ĉar la redaktilo malĉifras la bajtojn kaj la kliento ne. Tio, kion vi vidas, preskaŭ ĉiam estas kodiga problemo, ne sintaksa problemo.

La mito: la redaktilo montras al vi la dosieron

Teksta redaktilo malĉifras bajtojn en signojn per kodigo, kiun ĝi aŭ detektas aŭ divenas. Kiam ĝi divenas UTF-16, la dosiero aspektas perfekte sur la ekrano dum la subaj bajtoj estas paroj, kun nula bajto post ĉiu latina litero. OpenVPN legas tiujn bajtojn kiel signojn, kaj la malkongruo aperas ĉe la unua direktivo, kiun ĝi provas analizi.

Do la videbla linio kaj la liverita linio estas du malsamaj aferoj. Forigi la strangajn signojn, kiujn vi vidas, estas ŝanĝo de la montrado, ne de la kodigo, kaj la sekva analizo malsukcesas pro la sama kialo kun iom alia mesaĝo. Tial la postkurado de la signo en la eraro ĉiam kondukas nenie. La bajtoj estas malĝustaj ĉe la fonto, kaj ĉiu leganto poste divenas la saman rompitan sinsekvon.

Indas rekoni la specifan formon de la malsukceso, ĉar ĝi estas diagnoza en specifa maniero. Signo tute ĉe la komenco de la dosiero, en profilo, kiu alie funkciis sur aliaj maŝinoj, estas demando pri bajta ordo, ne pri vortprovizo.

Kion la unuaj bajtoj fakte diras

Legu la bajtojn anstataŭ la signojn. Du malgrandaj komandoj solvas tion en sekundoj, kaj neniu el ili postulas malfermi la dosieron en aplikaĵo, kiu povus ŝanĝi ĝin:

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

La ŝablono, kiun vi serĉas, estas paro da kondukaj bajtoj sekvata de teksto, en kiu ĉiu dua bajto estas nulo. FF FE markas UTF-16 little-endian, FE FF markas big-endian, kaj EF BB BF markas UTF-8 kun bajtorda marko. Ordinara UTF-8-dosiero sen marko komenciĝas rekte per la bajto de la unua litero.

Nulaj bajtoj inter literoj estas la signo. En UTF-16 little-endian la vorto client okupas dek du bajtojn anstataŭ ses, ĉar ĉiu ASCII-signo estas sekvata de nulo. Tiun strukturon la ekrano de redaktilo ne povas montri al vi, kaj ĝin forigo de du bajtoj ne povas forigi.

Grava nuanco kuŝas ĉi tie: la konfigura leganto de OpenVPN ja saltas bajtordan markon de UTF-8 ĉe la komenco de dosiero, kiel montras la konfigura leganto 2.6. Tiu toleremo estas specifa por tiu marko, kaj ĝi faras nenion por UTF-16-dosiero, kies literoj estas plenigitaj per nuloj. Trakti la du markojn kiel la saman problemon estas la dua duono de la mito.

Konverti estas konservi-kiel, ne forigi

Konservu netuŝitan kopion de la originalo de la operatoro antaŭ ol fari ion ajn, kaj laboru sur aparta dosiero. Profilo povas enhavi privatan ŝlosilon aŭ kontan materialon, do la kopio estas kaj via retroigo kaj via referenco.

Poste faru efektivan kodigokonverton, aŭ per la eksplicita kodiga menuo de la redaktilo aŭ per konvertilo, kiu deklaras sian enigan kaj eligan kodigon:

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

Kontrolu la rezulton anstataŭ fidi la eligan staton de la komando. La konverto devas konservi ĉiun direktivon, kaj ĝi devas konservi ĉiun enlinian atestilon aŭ ŝlosilblokon bajto post bajto ene de siaj markiloj. Re-envolvi PEM-datumojn, ŝanĝi linifinojn ene de bloko aŭ reformati la profilon dum la konverto kreas novan problemon dum ĝi riparas la malnovan.

Direktu la klienton aŭ servon al la konvertita dosiero kaj rigardu la unuan eraron, kiun ĝi raportas. Se la miksita signo malaperis, la kodiga laboro finiĝis kaj io ajn, kio malsukcesas poste, estas alia demando.

Kion riparita kodigo ne riparas

Kodigo difinas, kiel teksto estas legata; ĝi diras nenion pri tio, ĉu la opcioj validas por la kliento antaŭ vi. Profilo eksportita por alia efektivigo povas analiziĝi pure kaj tamen esti rifuzata pro opcio, kiun la kuranta versio ne subtenas, aŭ pro direktivo, kies argumento signifas ion alian en tiu kliento.

Tiuj postaj eraroj meritas sian propran esploron: la precizan literumadon, la sintakson de la argumento kaj la version, kiu ĝin akceptas. Ne traktu sukcesan analizon kiel sukcesan profilon.

Tenu la esploradon loka, dum vi faras ĝin. Publikaj interretaj konvertiloj kaj algluitaj hex-eligo estas malbona loko por dosiero, kiu povas enhavi privatan ŝlosilon, ĉar la kodiga problemo estas facile riparebla kaj likinta ŝlosilo ne.