OpenVPN birinci sətri rədd edir? Fayl çox güman ki UTF-16-dır

Xəta .ovpn faylının birinci sətrini göstərir və client sözünün yerinə qarışmış hərflərə bənzəyən bir şey gətirir. Fayl redaktorunuzda problemsiz açılır, birinci sətir client oxuyur və direktiv tamamilə adidir. Hər iki müşahidə doğrudur, çünki redaktor baytları dekodlaşdırır, müştəri isə yox. Gördüyünüz şey demək olar ki, həmişə kodlaşdırma problemidir, sintaksis problemi deyil.

Mif: redaktor sizə faylı göstərir

Mətn redaktoru baytları simvollara ya aşkar etdiyi, ya da təxmin etdiyi kodlaşdırma ilə dekodlaşdırır. UTF-16 təxmin etdikdə fayl ekranda mükəmməl görünür, halbuki altındakı baytlar cütlərdir və hər latın hərfindən sonra sıfır bayt gəlir. OpenVPN bu baytları simvol kimi oxuyur və uyğunsuzluq onun təhlil etməyə çalışdığı ilk direktivdə üzə çıxır.

Yəni görünən sətir və çatdırılan sətir iki fərqli şeydir. Gördüyünüz qəribə simvolları silmək kodlaşdırmaya deyil, göstərişə dəyişiklikdir və növbəti təhlil eyni səbəbdən bir az fərqli mesajla uğursuz olur. Səbəb budur ki, xətanın içindəki işarənin ardınca getmək heç bir yerə çatmır. Baytlar mənbədə səhvdir və axındakı hər oxuyucu eyni pozulmuş ardıcıllığı təxmin edir.

Uğursuzluğun konkret formasını tanımağa dəyər, çünki o, özünəməxsus şəkildə diaqnostikdir. Faylın lap əvvəlində, başqa maşınlarda işləmiş profildə bir işarə söz ehtiyatı deyil, bayt sırası məsələsidir.

İlk baytlar əslində nə deyir

Simvolları deyil, baytları oxuyun. İki kiçik əmr bunu saniyələr içində həll edir və heç biri faylı dəyişə biləcək proqramda açmağı tələb etmir:

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

Axtardığınız naxış, hər ikinci baytın sıfır olduğu mətnin qabağında gələn bir cüt açılış baytıdır. FF FE kiçik bayt sıralı UTF-16, FE FF böyük sıralı, EF BB BF isə bayt sırası işarəli UTF-8 deməkdir. İşarəsiz adi UTF-8 faylı birbaşa ilk hərfin baytı ilə başlayır.

Hərflər arasındakı sıfır baytlar ən yaxşı ipucudur. Kiçik bayt sıralı UTF-16-da client sözü altı yox, on iki bayt tutur, çünki hər ASCII simvolundan sonra sıfır gəlir. Bu quruluşu redaktorun ekranı sizə göstərə bilməz və iki baytlıq silmə onu aradan qaldıra bilməz.

Burada mühüm bir incəlik var: OpenVPN-in konfiqurasiya oxuyucusu faylın əvvəlindəki UTF-8 bayt sırası işarəsini həqiqətən atlayır, bunu 2.6 konfiqurasiya oxuyucusu göstərir. Bu dözüm yalnız həmin işarəyə aiddir və hərfləri sıfırlarla doldurulmuş UTF-16 faylı üçün heç nə etmir. İki işarəni eyni problem kimi qəbul etmək mifin ikinci yarısıdır.

Çevirmə silmə deyil, fərqli adla saxlamaqdır

Heç nə etməzdən əvvəl operatorun orijinalının toxunulmamış surətini saxlayın və ayrı fayl üzərində işləyin. Profildə şəxsi açar və ya hesab materialı ola bilər, ona görə surət həm geri qayıtma, həm də istinad nöqtənizdir.

Sonra həqiqi kodlaşdırma çevirməsi aparın: ya redaktorun açıq kodlaşdırma menyusu ilə, ya da giriş və çıxış kodlaşdırmasını bildirən çevirici ilə:

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

Əmrin çıxış statusuna güvənmək əvəzinə nəticəni yoxlayın. Çevirmə hər direktivi qorumalı və daxili sertifikat və ya açar blokunu markaları içində bayt-bayt saxlamalıdır. PEM məlumatını yenidən sarmaq, blok içində sətir sonlarını dəyişmək və ya çevirmə zamanı profili yenidən formatlamaq köhnə problemi düzəldərkən yenisini yaradır.

Müştərini və ya xidməti çevrilmiş fayla yönəldin və bildirdiyi ilk xətaya baxın. Qarışmış işarə yoxdursa, kodlaşdırma işi bitib və sonra baş verən hər uğursuzluq başqa sualdır.

Düzəldilmiş kodlaşdırmanın düzəltmədiyi şeylər

Kodlaşdırma mətnin necə oxunacağını müəyyən edir; seçimlərin qarşınızdakı müştəri üçün etibarlı olub-olmadığı barədə heç nə demir. Başqa tətbiq üçün eksport edilmiş profil təmiz təhlil oluna və yenə də işləyən buraxılışın dəstəkləmədiyi seçimə və ya arqumenti həmin müştəridə başqa məna daşıyan direktivə görə rədd edilə bilər.

Bu sonrakı xətalar öz araşdırmasına layiqdir: dəqiq yazılış, arqument sintaksisi və onu qəbul edən versiya. Uğurlu təhlili uğurlu profil kimi qəbul etməyin.

Araşdırmanı yerli saxlayın. Açıq onlayn çeviricilər və yapışdırılmış hex çıxışları şəxsi açar ola biləcək fayl üçün pis yerdir, çünki kodlaşdırma problemini düzəltmək asandır, sızmış açarı isə yox.