OpenVPN პირველ სტრიქონს უარყოფს? ფაილი, სავარაუდოდ, UTF-16-ია

შეცდომა .ovpn ფაილის პირველ სტრიქონზე მიუთითებს და ციტირებს რაღაცას, რაც არეულ ასოებს ჰგავს იქ, სადაც client უნდა იყოს. ფაილი თქვენს რედაქტორში უპრობლემოდ იხსნება, პირველი სტრიქონი client-ს კითხულობს, და დირექტივა სრულიად ჩვეულებრივია. ორივე დაკვირვება მართალია, რადგან რედაქტორი ბაიტებს დეკოდირებს, კლიენტი კი არა. რასაც ხედავთ, თითქმის ყოველთვის კოდირების პრობლემაა და არა სინტაქსის.

მითი: რედაქტორი ფაილს გაჩვენებთ

ტექსტური რედაქტორი ბაიტებს სიმბოლოებად გარდაქმნის კოდირებით, რომელსაც ან ამოიცნობს ან ჩაიფიქრებს. როცა UTF-16-ს ჩაიფიქრებს, ფაილი ეკრანზე სრულყოფილი ჩანს, მაშინ როცა ქვეშა ბაიტები წყვილებია და ყოველი ლათინური ასოს შემდეგ ნულოვანი ბაიტი მოდის. OpenVPN ამ ბაიტებს სიმბოლოებად კითხულობს და შეუსაბამობა პირველ იმ დირექტივაზე ჩნდება, რომლის ანალიზსაც ცდილობს.

ამიტომ ხილული სტრიქონი და მიწოდებული სტრიქონი ორი სხვადასხვა რამაა. იმ უცნაური სიმბოლოების წაშლა, რომლებსაც ხედავთ, ჩვენების ცვლილებაა და არა კოდირების, და შემდეგი ანალიზიც იმავე მიზეზით ვარდება, ოდნავ განსხვავებული შეტყობინებით. ამიტომ შეცდომაში მოცემული ნიშნის დევნა არასოდეს არსად მიდის. ბაიტები წყაროშივე არასწორია და ყოველი შემდგომი მკითხველი იმავე დამტვრეულ მიმდევრობას ჩაიფიქრებს.

ღირს ამ მარცხის კონკრეტული ფორმის ამოცნობა, რადგან ის თავისებურად დიაგნოსტიკურია. ნიშანი ფაილის თავიდანვე, იმ პროფილში, რომელიც სხვა მანქანებზე მუშაობდა, ბაიტების რიგის საკითხია და არა ლექსიკის.

რას ამბობს სინამდვილეში პირველი ბაიტები

წაიკითხეთ ბაიტები და არა სიმბოლოები. ორი პატარა ბრძანება წყვეტს ამას წამებში და არც ერთი მათგანი არ მოითხოვს ფაილის იმ აპში გახსნას, რომელმაც შეიძლება შეცვალოს იგი:

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

ნიმუში, რომელსაც ეძებთ, არის წამყვანი ბაიტების წყვილი, რომელსაც მოჰყვება ტექსტი, სადაც ყოველი მეორე ბაიტი ნულია. FF FE აღნიშნავს UTF-16 little-endian-ს, FE FF big-endian-ს, ხოლო EF BB BF აღნიშნავს UTF-8-ს ბაიტების რიგის ნიშნით. ჩვეულებრივი UTF-8 ფაილი ნიშნის გარეშე პირდაპირ პირველი ასოს ბაიტით იწყება.

ნულოვანი ბაიტები ასოებს შორის ყველაზე მთავარი მინიშნებაა. UTF-16 little-endian-ში სიტყვა client ექვსის ნაცვლად თორმეტ ბაიტს იკავებს, რადგან ყოველ ASCII სიმბოლოს ნული მოჰყვება. ამ სტრუქტურას რედაქტორის ეკრანი ვერ გაჩვენებთ და ორი ბაიტის წაშლა ვერ მოაშორებს.

აქ მნიშვნელოვანი ნიუანსია: OpenVPN-ის კონფიგურაციის მკითხველი ნამდვილად გამოტოვებს ფაილის დასაწყისში UTF-8 ბაიტების რიგის ნიშანს, როგორც 2.6 კონფიგურაციის მკითხველი გვიჩვენებს. ეს შემწყნარებლობა სწორედ იმ ნიშანს ეხება და არაფერს აკეთებს ისეთი UTF-16 ფაილისთვის, რომლის ასოები ნულებითაა გამსავებული. ორი ნიშნის ერთ პრობლემად მიჩნევა მითის მეორე ნახევარია.

გადაკეთება შენახვა-როგორც არის, და არა წაშლა

სანამ რამეს იზამთ, შეინახეთ ოპერატორის ორიგინალის ხელუხლებელი ასლი და იმუშავეთ ცალკე ფაილზე. პროფილში შეიძლება იყოს პირადი გასაღები ან ანგარიშის მონაცემები, ამიტომ ასლი ერთდროულად თქვენი უკუსვლაცაა და თქვენი ცნობარიც.

შემდეგ შეასრულეთ ნამდვილი კოდირების გადაკეთება, ან რედაქტორის გამოკვეთილი კოდირების მენიუთი, ან გადამყვანით, რომელიც თავისი შემავალი და გამომავალი კოდირებას ასახელებს:

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

შეამოწმეთ შედეგი და ნუ დაეყრდნობით ბრძანების გასვლის სტატუსს. გადაკეთებამ უნდა შეინარჩუნოს ყოველი დირექტივა და ვალდებულია ბაიტ-ბაიტ შეინარჩუნოს ნებისმიერი ჩაშენებული სერტიფიკატის ან გასაღების ბლოკი მისი მარკერების შიგნით. PEM მონაცემების გადახვევა, ბლოკის შიგნით სტრიქონების დაბოლოებების შეცვლა ან გადაკეთების დროს პროფილის გადაფორმატება ახალ პრობლემას ქმნის ძველის გასწორებისას.

მიუთითეთ კლიენტი ან სერვისი გადაკეთებულ ფაილზე და შეხედეთ პირველ შეცდომას, რომელსაც ის გვამცნობს. თუ არეული ნიშანი გაქრა, კოდირების სამუშაო დასრულებულია და ყველაფერი, რაც შემდეგ ვარდება, სხვა საკითხია.

რას არ ასწორებს გასწორებული კოდირება

კოდირება განსაზღვრავს, როგორ იკითხება ტექსტი; ის არაფერს ამბობს იმაზე, არის თუ არა პარამეტრები თქვენ წინაშე მდგარი კლიენტისთვის ნამდვილი. სხვა იმპლემენტაციისთვის ექსპორტირებული პროფილი შეიძლება სუფთად გაანალიზდეს და მაინც უარყოფილ იქნას იმ პარამეტრის გამო, რომელსაც მოქმედი აწყობა არ უჭერს მხარს, ან იმ დირექტივის გამო, რომლის არგუმენტი იმ კლიენტში სხვა რამეს ნიშნავს.

ეს გვიანი შეცდომები საკუთარ გამოძიებას იმსახურებს: ზუსტი მართლწერა, არგუმენტის სინტაქსი და ის ვერსია, რომელიც მას იღებს. წარმატებული ანალიზი ნუ ჩათვალეთ წარმატებულ პროფილად.

გამოძიება ადგილობრივად აწარმოეთ, სანამ ამით ხართ დაკავებული. საჯარო ონლაინ გადამყვანები და ჩასმული hex გამონაბეჭდები ცუდი ადგილია იმ ფაილისთვის, რომელშიც შეიძლება პირადი გასაღები იყოს, რადგან კოდირების პრობლემა ადვილად გამოსწორდება, გაჟონილი გასაღები კი არა.