OpenVPN noraida pirmo rindu? Fails, visticamāk, ir UTF-16

Kļūda norāda uz .ovpn faila pirmo rindu un citē kaut ko, kas izskatās pēc sajauktiem burtiem tur, kur vajadzētu būt client. Fails jūsu redaktorā atveras bez problēmām, pirmā rinda nolasa client, un direktīva ir pilnīgi parasta. Abi novērojumi ir patiesi, jo redaktors atšifrē baitus, bet klients to nedara. Tas, ko redzat, gandrīz vienmēr ir kodējuma problēma, nevis sintakses problēma.

Mīts: redaktors jums parāda failu

Teksta redaktors atšifrē baitus rakstzīmēs, izmantojot kodējumu, ko tas vai nu nosaka, vai uzmin. Kad tas uzmin UTF-16, fails ekrānā izskatās nevainojami, kamēr apakšā esošie baiti ir pāri, pēc katra latīņu burta nāk nulles baits. OpenVPN šos baitus lasa kā rakstzīmes, un neatbilstība parādās pirmajā direktīvā, ko tas mēģina parsēt.

Tātad redzamā rinda un piegādātā rinda ir divas dažādas lietas. Redzamo dīvaino rakstzīmju dzēšana ir attēlojuma, nevis kodējuma izmaiņa, un nākamā parsēšana neizdodas tā paša iemesla dēļ ar nedaudz citādu ziņojumu. Tāpēc kļūdas marķiera vajāšana vienmēr noved nekur. Baiti ir nepareizi avotā, un katrs nākamais lasītājs uzmin to pašu salauzto secību.

Šīs neveiksmes konkrēto formu ir vērts atpazīt, jo tā savā ziņā ir diagnostiska. Marķieris pašā faila sākumā, profilā, kas citādi ir strādājis citās mašīnās, ir baitu kārtības, nevis vārdu krājuma jautājums.

Ko patiesībā saka pirmie baiti

Lasiet baitus, nevis rakstzīmes. Divas mazas komandas to atrisina sekundēs, un neviena no tām neprasa atvērt failu programmā, kas to varētu mainīt:

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

Modelis, ko meklējat, ir pāris sākuma baitu, kam seko teksts, kurā katrs otrais baits ir nulle. FF FE apzīmē UTF-16 little-endian, FE FF apzīmē big-endian, un EF BB BF apzīmē UTF-8 ar baitu kārtības atzīmi. Vienkāršs UTF-8 fails bez atzīmes sākas tieši ar pirmā burta baitu.

Nulles baiti starp burtiem ir galvenā pazīme. UTF-16 little-endian gadījumā vārds client aizņem divpadsmit baitus, nevis sešus, jo pēc katras ASCII rakstzīmes nāk nulle. Šādu struktūru redaktora ekrāns jums nevar parādīt, un to nevar novērst divu baitu dzēšana.

Šeit ir svarīga nianse: OpenVPN konfigurācijas lasītājs patiešām izlaiž UTF-8 baitu kārtības atzīmi faila sākumā, kā rāda 2.6 konfigurācijas lasītājs. Šī iecietība attiecas tieši uz šo atzīmi, un tā neko nedara UTF-16 failam, kura burti ir piepildīti ar nullēm. Abu atzīmju uzskatīšana par vienu problēmu ir mīta otrā puse.

Konvertēšana ir saglabāšana kā, nevis dzēšana

Pirms kaut ko darāt, saglabājiet neskartu operatora oriģināla kopiju un strādājiet ar atsevišķu failu. Profilā var būt privāta atslēga vai konta dati, tāpēc kopija ir gan jūsu atrite, gan atsauce.

Pēc tam veiciet īstu kodējuma konvertēšanu, vai nu izmantojot redaktora skaidro kodējuma izvēlni, vai ar pārveidotāju, kas norāda ievades un izvades kodējumu:

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

Pārbaudiet rezultātu, nevis paļaujieties uz komandas iziešanas statusu. Konvertēšanai jāsaglabā katra direktīva, un tai jāsaglabā jebkurš iegultais sertifikāta vai atslēgas bloks baits pa baitam tā atzīmēs. PEM datu pārtīšana, rindu beigu maiņa bloka iekšienē vai profila pārformatēšana konvertēšanas laikā rada jaunu problēmu, kamēr tiek labota vecā.

Norādiet klientam vai pakalpojumam konvertēto failu un apskatiet pirmo ziņoto kļūdu. Ja sajauktais marķieris ir pazudis, kodējuma darbs ir pabeigts, un viss, kas pēc tam neizdodas, ir cits jautājums.

Ko izlabots kodējums neizlabo

Kodējums nosaka, kā teksts tiek lasīts; tas neko nesaka par to, vai opcijas ir derīgas klientam jums priekšā. Profils, kas eksportēts citai implementācijai, var tikt tīri parsēts un tomēr tikt noraidīts opcijas dēļ, ko darbojošā būvējums neatbalsta, vai direktīvas dēļ, kuras arguments tajā klientā nozīmē ko citu.

Tās vēlākās kļūdas ir pelnījušas savu izmeklēšanu: precīzo rakstību, argumenta sintaksi un versiju, kas to pieņem. Neuzskatiet veiksmīgu parsēšanu par veiksmīgu profilu.

Veiciet izmeklēšanu lokāli, kamēr ar to nodarbojaties. Publiski tiešsaistes pārveidotāji un ielīmēti hex izdrukas ir slikta vieta failam, kurā var būt privāta atslēga, jo kodējuma problēmu ir viegli izlabot, bet noplūdušu atslēgu ne.