OpenVPN პროფილიდან key-method-ის წაშლა არაფერს ცვლის

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

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

სიმპტომი პარსინგის შეცდომაა და არა ხელის ჩამორთმევის მარცხი

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

დირექტივა და გადაცემის ფორმატი ორი სხვადასხვა რამ არის

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

ამიტომ ძველი ბინარულის დაბრუნება „მე-2 მეთოდის აღსადგენად“ არასწორი შეკეთებაა. ის არაფერს აღადგენს, გარდა ძველი ნაგულისხმევი მნიშვნელობების მქონე ძველი პარსერისა, და გაკარგვინებთ მის შემდეგ მოსულ შესწორებებს. იგივე მსჯელობა ეხება სერტიფიკატის შემოწმების ან შიფრების სიის შესუსტებას იმ იმედით, რომ კავშირი დაბრუნდება.

სასარგებლო შემოწმება არის ვერსია და დაპარსული კონფიგურაცია და არა სიტყვის არსებობა ფაილში:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

რა უნდა წაიშალოს და რომელი ფაილიდან

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

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

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

უარყოფილი პროფილი და უარყოფილი კლიენტი ერთნაირად გამოიყურება

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

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

თავსებადობის კითხვები, რომლებზეც ხაზმა არასოდეს უპასუხა

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

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

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