რატომ კვდება OpenVPN ლეპტოპის გამოღვიძების შემდეგ?

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

გაამეორეთ გამოღვიძება, სანამ მას ავტომატიზებთ

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

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

სად ცხოვრობს სინამდვილეში systemd-ის ძილის კაუჭი

ბევრი ძველი სახელმძღვანელო /etc/pm/sleep.d-ს მიუთითებს, საქაღალდეს, რომელიც pm-utils-ს ეკუთვნის და რომელსაც systemd-ზე დაფუძნებული ძილი არასოდეს ეკითხება. systemd კაუჭებს კითხულობს /usr/lib/systemd/system-sleep/-დან და /etc/systemd/system-sleep/-დან, ჯერ ფაზას გადასცემს და შემდეგ ოპერაციას, ამიტომ pre და post ერთადერთი მნიშვნელობებია, რომლებზეც კაუჭი ტოტდება. შეინახეთ ლოკალური ასლი /etc-ის ქვეშ, პაკეტირებული ფაილის რედაქტირების ნაცვლად, და გახსოვდეთ, რომ სკრიპტი root-ად მუშაობს გადასვლის შუაში, ამიტომ სწრაფად უნდა დაბრუნდეს.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart ერთეულს მხოლოდ მაშინ ეხება, როცა ის უკვე აქტიურია, ამიტომ განზრახ გამორთული გვირაბი გამოღვიძების განმავლობაშიც გამორთული რჩება. --no-block კაუჭს არ აძლევს კლიენტის მოლაპარაკების დროს ლოდინის საშუალებას, რაც მაშინ მნიშვნელოვანია, როცა ქსელი ჯერ არ ასულა. ორი დროშა ერთად ნიშნავს კაუჭს, რომელიც ჩუმად ვარდება, ნაცვლად იმისა, რომ მთელი გამოღვიძების მიმდევრობა შეაჩეროს. როცა ერთეული უკვე გაჩერებულია, საერთოდ არაფერი ხდება, რაც ზუსტად ის შედეგია, რომელიც იქ გსურთ.

აღადგინეთ სერვისი, tun0-ს თავი დაანებეთ

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

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

გაუმკლავდით დროს, რომელსაც ვერ აკონტროლებთ

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

სახელების გარჩევა ცალკე რბოლაა, რადგან სამუშაო მაგიდის ქსელური დასტა შეიძლება DNS აღადგინოს მას შემდეგ, რაც გვირაბი უკვე ასულია. ძიებები ცალკე შეამოწმეთ resolvectl query internal.example-ით, ნაცვლად იმისა, რომ მუშა მარშრუტიდან გამოიტანოთ ისინი. გვირაბი, რომელიც სწორად მარშრუტიზებს და არაფერს ხსნის, DNS პრობლემაა და არა კაუჭის პრობლემა.

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