შეუძლია OpenVPN-ის კაკლის სკრიპტს გამოიყენოს ახლახან აშენებული გვირაბი?

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

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

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

OpenVPN თავის კაკლებს სინქრონულად იძახებს, იმავე პროცესში, რომელიც პაკეტებს გადაადგილებს. up აქტიურდება, როცა tun ან tap მოწყობილობა არსებობს, მაგრამ ნებისმიერი მარშრუტის დამატებამდე, ხოლო route-up მარშრუტების შემდეგ; არც ერთი მომენტი არ იძლევა გარანტიას, რომ მოპირდაპირე მხარე უპასუხებს. სანამ რომელიმე კაკლის სკრიპტი მუშაობს, დემონი არ გადასცემს, ამიტომ ბრძანება, რომელიც ელოდება ტრაფიკის გვირაბში გავლას, ელოდება გვირაბს, რომელიც ამ ბრძანებას ელოდება. ეს ციკლური ლოდინია მიზეზი, რატომ გადის ხელით გაშვება და კაკალს ვადა ეწურება.

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

აირჩიეთ კაკალი მოვლენის მიხედვით და არა მოხერხებულობის მიხედვით

მიაბით up სამუშაოს, რომელსაც მხოლოდ მოწყობილობა სჭირდება, route-up სამუშაოს, რომელსაც მარშრუტები სჭირდება, და client-connect და client-disconnect დატოვეთ სერვერის მხარეს თითო კლიენტის ამოცანებისთვის. გათიშვისას გასუფთავებამ უნდა გაუძლოს ორჯერ გაშვებას, ვინაიდან მუდმივ ინტერფეისზე ხელახალი დაკავშირება არ მიჰყვება სრული გადატვირთვის იმავე მიმდევრობას. სერვერზე client-connect აქტიურდება, როცა კლიენტი ადასტურებს თავს და არა როცა დემონი იწყებს, რაც ღირს დადასტურება ლოგიკის იქ გადატანამდე. თუ სამუშაო მომსახურების სიცოცხლის ციკლს ეკუთვნის და არა ერთ კავშირს, systemd ერთეული უკეთესი სახლია, ვიდრე ნებისმიერი კაკალი.

კაკლის ბრძანებებს დემონი უშუალოდ ასრულებს, გარეშე ჭურვისა, ამიტომ up სტრიქონში ifconfig_remote მოდის როგორც სიტყვასიტყვითი ტექსტი. გაახვიეთ ბრძანება გამოკვეთილ ჭურვში, ან შეინახეთ ლოგიკა სკრიპტში, რომელიც გარემოს კითხულობს. ipchange ერთი დირექტივაა, რომელიც საკუთარ არგუმენტებს ამატებს: ის ბრძანებას გადასცემს მისამართსა და პორტს, ამიტომ არც ერთისთვის დაწერილი სკრიპტი ორ მოულოდნელს ხედავს.

სამუშაოს გამოყოფის სამი გზა

პირველი ვარიანტია დამხმარის ფონზე გაშვება თვით კაკლიდან: დაიწყეთ ის setsid-ით ან systemd-run --scope-ით, დახურეთ მემკვიდრეობით მიღებული აღწერილობები და მაშინვე გადით ნულით. მეორეა, კაკალმა დაწეროს პატარა მდგომარეობის ფაილი და systemd-ის ტაიმერმა ან ბილიკის ერთეულმა იმოქმედოს მასზე, რაც კაკალს ტრივიალურად ინახავს და ხელახალი ცდის პოლიტიკას იქ ათავსებს, სადაც ჟურნალებია. მესამეა კაკლის სრულად მიტოვება და სამუშაოს გადატანა VPN მომსახურების შემდეგ დალაგებულ ერთეულში, რაც სწორი პასუხია, როცა სამუშაო საერთოდ არ არის თითო კავშირზე. სამივე ერთ წესს იზიარებს: კაკალი უნდა დაბრუნდეს მანამ, სანამ გვირაბი დასჭირდება.

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

გამოყავით sandbox-ის ჩავარდნები სიცოცხლის ციკლის ჩავარდნებისგან

როცა სკრიპტი root-ის მოთხოვნიდან მუშაობს და მომსახურებად მარცხდება, მიზეზი ჩვეულებრივ sandbox-ია და არა ქსელი. შემზღუდველი ProtectHome, მხოლოდ-კითხვადი ProtectSystem ან არარსებული სამუშაო დირექტორია შეიძლება სკრიპტი ან მისი მონაცემები მიუწვდომელი გახადოს, ხოლო SELinux ჰოსტზე ფაილს ასევე სჭირდება კონტექსტი, რომელიც შესრულებას უშვებს. წაიკითხეთ ერთეული systemctl cat openvpn-server@server-ით და ჟურნალი journalctl -u openvpn-server@server -n 80-ით, შემდეგ მოძებნეთ ნებართვის ან კონტექსტის შეცდომა და არა კავშირის ვადის გასვლა. sandbox-ის გამორთვა ბოლო ნაბიჯი უნდა იყოს და არა პირველი.

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

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