OpenVPN-ის up სკრიპტი ძალიან ადრე გაეშვა, თუ ის არასდროს იყო მზად?

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

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

სად დგას up გაშვების თანმიმდევრობაში

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

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

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

რას იღებს ჰუკი სინამდვილეში მემკვიდრეობით

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

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

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

რატომ არ არის ძილი მზადყოფნის შემოწმება

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

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

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

დასუფთავება და ხელახალი დაკავშირება იგივე ზრუნვას იმსახურებს

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

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

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

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