სერვისის გადატვირთვა OpenVPN up-ზე: კაუჭები სჯობს tun0.device-ს

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

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

რას ადევნებს თვალყურს მოწყობილობის ერთეული სინამდვილეში

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

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

up, route-up და up-restart სხვადასხვა რამეს ნიშნავს

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

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

გაგზავნეთ მოქმედება მისი ლოდინის გარეშე

კაუჭი, რომელიც systemctl restart-ს სინქრონულად იძახებს, შეიძლება ჩიხში შევიდეს ერთეულთან, რომლის რიგიც გვირაბს ელოდება. systemctl --no-block try-restart vpn-dependent.service სამუშაოს რიგში აყენებს და ბრუნდება, რაც ხელს უშლის კაუჭს დაბლოკოს კავშირი, რომელზეც ის რეაგირებდა. try-restart მოქმედებს მხოლოდ გაშვებულ ერთეულზე, მაშინ როცა restart არააქტიურსაც იწყებს; აირჩიეთ განზრახ და არა ჩვევით.

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

გადატვირთვის პოლიტიკა ერთეულში ცხოვრობს და არა კაუჭში

RemainAfterExit=yes-ის მქონე oneshot ერთეული აქტიური რჩება მისი ბრძანების დასრულების შემდეგ, და მეორე გაშვების მოთხოვნა არაფერს აკეთებს, რადგან systemd მას უკვე გაშვებულად თვლის. ეს ისეთი თვისებაა, რომლის ირგვლივაც უნდა დაპროექტდეს, და არა ხარვეზი, რომელსაც განმეორებადი გაშვების გამოძახებებით გვერდს უვლიან. თუ მოქმედება ყოველ კავშირზე უნდა შესრულდეს, ერთეულს სჭირდება ფორმა, რომელიც ამას უშვებს.

After= აწესრიგებს ერთეულებს, და BindsTo= აკავშირებს სიცოცხლის ხანგრძლივობებს, მაგრამ არც ერთი არ ნიშნავს 'გადატვირთე ეს ყოველ ჯერზე, როცა VPN ხელახლა უკავშირდება'. გვირაბზე მიბმული ერთეული ჩერდება, როცა გვირაბი ჩერდება; ის თავს ხელახლა არ გადატვირთავს, როცა გვირაბი ბრუნდება, თუ რაღაც ხელახლა არ გაუშვებს.

სცადეთ სამი ხელახალი დაკავშირება და არა ერთი

ცივი გაშვება, კლიენტის სრული გადატვირთვა და რბილი ხელახალი დაკავშირება თითოეული განსხვავებულ გზას ვარჯიშობს. რბილი ხელახალი დაკავშირებაა ის, რაც ავლენს დაკარგულ up-restart-ს, შემცირებულ გარემოს ან მოწყობილობის ერთეულს, რომელიც არასდროს გახდა არააქტიური. გაუშვით სამივე და დაადასტურეთ ორივე მიმართულება: სერვისი მოქმედებს, როცა გვირაბი ადის, და ის არ ირთვება ხელახლა უკავშირო ბმულის ცვლილებებზე, როგორიცაა Wi-Fi როუმინგი.

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