systemd აჩერებს VPN სერვისს: შეუსაბამეთ Type= კლიენტს

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

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

რატომ ხდება ერთეული არააქტიური წარმატებული გაშვებიდან წამებში

systemd მდგომარეობას იმ პროცესიდან ასკვნის, რომელიც თავად გაუშვა, ამიტომ Type= მტკიცებაა ამ პროცესზე და არა დოკუმენტაცია. Type=simple-ით ერთეული აქტიურად ითვლება სანამ ბრძანება მუშაობს და არააქტიური ხდება, როცა ის ბრუნდება. ამიტომ კლიენტი, რომელიც კავშირს დამხმარე პროგრამას გადასცემს და გადის, კრახივით გამოიყურება, მაშინაც კი როცა გვირაბი მუშაობს. შემდეგ ჟურნალი აჩვენებს გაშვება-გაჩერების ნიმუშს, რომელიც დაზიანებულ ბინარს ჰგავს.

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

აირჩიეთ ტიპი, რომელიც კლიენტს შეესაბამება

ორი ნიმუში ფარავს მომწოდებლების CLI-ების უმეტესობას: ბრძანება, რომელიც სესიას აკონფიგურებს და გადის, და ბრძანება, რომელიც დაბრუნებამდე fork-ს უკეთებს დამხმარეს. თითოეულს სხვადასხვა ფორმის ერთეული სჭირდება.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot RemainAfterExit=true-თან ერთად ერთეულს აქტიურად ინახავს ბრძანების დაბრუნების შემდეგ, რაც ემთხვევა კონფიგურირება-და-გასვლის ნიმუშს, ხოლო გაჩერების ბრძანება სერვისს სუფთა დახურვას აძლევს. Fork-ის გამკეთებელი კლიენტი ინარჩუნებს იმავე ფორმას, მაგრამ სჭირდება Type=forking, რომ systemd შვილს მიჰყვეს. დააყენეთ Restart=on-failure, RestartSec=30 და სასრული StartLimitBurst, რათა მომწოდებლის შეფერხება არ გადაიქცეს გადატვირთვების ციკლად, რომელიც შეცდომას ჩაფლავს.

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

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

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

სესია მთავრდება და გვირაბს თან წაიღებს

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

სერვისის მომხმარებელი იმავე პრობლემის მეორე ნახევარია. root-ის საკუთრებაში არსებული და 0600 რეჟიმის გასაღები წაუკითხავია სხვა ანგარიშით მომუშავე ერთეულისთვის, რაც არ უნდა მიეღწია sudo-ს თქვენს გარსში.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

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

როცა დემონი უკავშირდება გვირაბის მისამართს, რომელიც ჯერ არ შექმნილა, ის გადის Cannot assign requested address შეტყობინებით. შესწორება ცალსახა დალაგებაა და არა ხელახალი ცდების ციკლი.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

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

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

დაკავშირებული სტატიები