რატომ ირთვება VPN ერთეული ქსელამდე და შემდეგ კვდება

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

სამიზნე შეხვედრის ადგილია, არა მმართველი

network-online.target წარმოდგენა არ აქვს, რა არის ქსელი. ეს არის კოორდინაციის წერტილი, რომელიც აგროვებს იმ სერვისს, რომელმაც უნდა შეაყოვნოს გაშვება მანამ, სანამ კავშირი გამოსადეგი გახდება, და განსაზღვრებას გადასცემს იმ ქსელის მმართველს, რომელიც მანქანას ფლობს. უმეტეს დესკტოპებსა და სერვერებზე ეს ნიშნავს ლოდინის სერვისს, რომელსაც NetworkManager ან systemd-networkd აწვდის. თუ არცერთს არ ჩართავთ, სამიზნეს არაფერი აქვს მოსალოდნელი, ამიტომ ის სრულდება იმ მომენტში, როცა რაღაც შიგნით შეათრევს, და ეს შეიძლება მოხდეს DHCP-ის პასუხამდე ბევრად ადრე. თქვენი ერთეულის რიგის ხაზი პატიოსანი იყო და მაინც უსარგებლო.

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

წაიკითხეთ ბოლო ჩართვა და არა ერთეულის ფაილი

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

დაამატეთ ლოდინი, შემდეგ განმეორებითი ცდა

გამოიყენეთ drop-in ნაცვლად იმისა, რომ შეცვალოთ პაკეტირებული ერთეული, რათა პაკეტის განახლებამ ცვლილება ჩუმად არ გადააგდოს. ორი დირექტივა მნიშვნელოვანია: ერთეული უნდა დალაგდეს სამიზნის შემდეგ, და მან სამიზნე იმავე ტრანზაქციაში უნდა შეათრიოს. მხოლოდ რიგი სამიზნეს არ იძახებს; სურვილი ამას აკეთებს.

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

[Service]
Restart=on-failure
RestartSec=15

რატომ არის ფიქსირებული ძილი ხაფანგი

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

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

როცა რიგი სწორია და სახელები მაინც ფუჭდება

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

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