რატომ რჩება თქვენი OpenVPN კლიენტი გამორთული ერთი დროის ამოწურვის შემდეგ

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

დაიწყეთ იმით, რაც ერთეულმა რეალურად გააკეთა და არა იმით, რასაც მონიტორინგი ამტკიცებს. systemctl status openvpn-client@office და journalctl -u openvpn-client@office -n 50 აჩვენებენ გასვლის მიზეზს და ბოლო სტრიქონს, რომელიც კლიენტმა წასვლამდე დაწერა.

პროცესი გავიდა მანამ, სანამ ვინმე შეამჩნევდა

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

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

არჩევანი ping-exit-სა და ping-restart-ს შორის

აირჩიეთ ping-restart ლეპტოპისთვის ან შორეული ადგილისთვის, რომელმაც თავად უნდა განიკურნოს, და შეინახეთ ping-exit იმ შემთხვევებისთვის, როცა მკვდარმა გვირაბმა პროცესი უნდა გააჩეროს, რათა სხვა რამემ შეძლოს მასზე რეაგირება. რიცხვები ნაკლებად მნიშვნელოვანია, ვიდრე კავშირი: ping 10 ping-restart 60-თან ერთად ნიშნავს ათ წამ სიჩუმეს შემოწმებამდე და სამოცს გადატვირთვამდე, რაც აგრესიულია დანაკარგიან მობილურ კავშირზე და გონივრულია სადენიანზე. დაწერეთ მიზეზი ხაზის გვერდით, თორემ შემდეგი მკითხველი ჩათვლის, რომ ნაგულისხმევი მნიშვნელობები განზრახ იყო.

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

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

systemd ჰოსტზე ყველაზე პატარა მდგრადი ცვლილება ერთი drop-in ფაილია: Restart=on-failure და RestartSec=10 /etc/systemd/system/[email protected]/restart.conf-ში. drop-in მხოლოდ მაშინ იკითხება, როცა systemd საკუთარ განმარტებებს ხელახლა ტვირთავს, ამიტომ ამის შემდეგ გაუშვით systemctl daemon-reload. შეამოწმეთ systemctl show -p Restart -p ExecMainStatus openvpn-client@office-ით იმის ნაცვლად, რომ ჩათვალოთ მნიშვნელობის მისვლა. ფაილის სახელში არსებული ინსტანცია უნდა იყოს ის პროფილი, რომელსაც ერთეული ნამდვილად ტვირთავს, ამიტომ office-ისთვის დაწერილი ფაილი openvpn-client@home-ისთვის არაფერს აკეთებს.

on-failure ერთ შემთხვევას უგულებელყოფს: სუფთა გასვლას ნულოვანი სტატუსით. ზოგიერთი დაშლის გზა ასე მთავრდება, ამიტომ წაიკითხეთ ჩაწერილი სტატუსი და ნუ დაეყრდნობით სახელმძღვანელოს გვერდის ფორმულირებას. თუ თქვენი კლიენტი ნულით თმობს, გჭირდებათ Restart=always, და ფასი ისაა, რომ ნამდვილად გატეხილი პროფილი ისევ და ისევ ბრუნდება, სანამ გაშვების სიჩქარის ლიმიტი ამოქმედდება და ჟურნალი აივსება.

Restart=always განზრახ გაჩერების შემდეგაც ამოქმედდება. ტექნიკური მომსახურებისთვის გამოიყენეთ systemctl stop და დამალეთ ერთეული, თუ ის თქვენი მუშაობის დროს გამორთული უნდა დარჩეს.

დაიჭირეთ გაჟონვა, სანამ გვირაბი გამორთულია

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

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

შეამოწმეთ კლიენტის განზრახ გაჩერებით. გაუშვით systemctl stop openvpn-client@office, შემდეგ curl -m 5 https://example.com, რომელიც ფიზიკურ კავშირზე უნდა ჩავარდეს და არა წარმატდეს. წარმატება ნიშნავს, რომ firewall-ის წესი აკლია ან ზედმეტად დასაშვებია.

ხელახლა დაუკავშირდით, დაადასტურეთ, რომ გვირაბი კვლავ ტრაფიკს ატარებს, და მხოლოდ ამის შემდეგ დაამატეთ შემოწმება მონიტორინგში. ip addr-ის გამოკითხვა cron-იდან tun მოწყობილობისთვის ყველაზე ხშირად წარუმატებელი ზედამხედველობაა, რადგან persist-tun-ით მოწყობილობა სესიაზე მეტხანს ცოცხლობს და შემოწმება ჯანმრთელობას აცხადებს, მაშინ როცა არაფერი არ გადააქვს.