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

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

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

კაუჭი მუშაობს, და შემდეგ?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

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

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

root, მინიმალური გარემო, არასწორი მომხმარებელი

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

დაწერეთ კაუჭი აბსოლუტური ბილიკებით, შეინახეთ ის root-ის საკუთრებაში და შესრულებადი, და ჩაწერეთ, რა გააკეთა. ამ ჟურნალის გარეშე შემდეგი გამოძიება ნულიდან იწყება.

ავტომატური დაკავშირება VPN-ის გზა არ არის

NetworkManager გვთავაზობს გააქტიურების ორ მექანიზმს: ავტომატური დაკავშირების დროშას პროფილზე და მეორად კავშირებს, რომლებიც იწყება, როცა ძირითადი პროფილი აქტიურდება. მშობლიური მოწყობილობის ტიპები პირველს ახორციელებენ; VPN დამატებებს ისტორიულად მხოლოდ მეორე აქვთ დანერგილი, ამიტომ OpenVPN პროფილზე ავტომატური დაკავშირების მონიშვნას შეიძლება საერთოდ არ ჰქონდეს ეფექტი. შეამოწმეთ ორივე თვისება, შემდეგ VPN მიამაგრეთ Wi-Fi ან Ethernet პროფილის მეორადად.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd ერთეულით მართულ WireGuard ინტერფეისს სჭირდება სწორედ ის დამატებითი ფაილი და არა კაუჭი, დალაგებული მას შემდეგ, რაც ქსელი ონლაინ იქნება.

დაელოდეთ ქსელს, ზედა ზღვრით

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

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

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

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