OpenVPN ამბობს active (exited)? იპოვეთ ის ინსტანსი, რომელიც გაუშვით

ამოწმებთ გვირაბს, უშვებთ systemctl status openvpn-ს და იღებთ active (exited)-ს Main PID-ის გარეშე და ცარიელი პროცესების სიით. ბუნებრივი წაკითხვაა, რომ სერვისი გაეშვა და მოკვდა, ამიტომ ხსნით unit-ს, პოულობთ /bin/true-ს და ასკვნით, რომ პაკეტი გატეხილია. Debian-ის პაკეტში ეს მდგომარეობა არის wrapper, რომელიც ისე მუშაობს, როგორც დაპროექტდა, და გვირაბი ცხოვრობს იმ instance-unit-ებიდან ერთ-ერთში, რომლებსაც ის უშვებს. საერთო unit არასოდეს გეტყვით, რომელმა ინსტანსმა ააშენა ის.

რას ნიშნავს active (exited) სინამდვილეში ამ unit-ზე

შეფუთული unit ერთჯერადი დავალებაა: მისი ExecStart არის /bin/true, და RemainAfterExit=yes არის ის, რაც დასრულებულ unit-ს active (exited)-ად მოხსენებულს ინარჩუნებს. მოხსენით ეს დირექტივა და იგივე წარმატებული /bin/true დავალება დასრულდება inactive (dead)-ში, რაც ზუსტად ის მდგომარეობაა, რომელსაც ადამიანები ელიან და საპირისპირო მიმართულებით არასწორად კითხულობენ. ბრძანება მხოლოდ ადგილის დამჭერია, და unit იმ სამუშაოზე მოგვითხრობს, რომელსაც სხვა unit-ები ასრულებენ. ამ განლაგებაში არაფერია გატეხილი, და /bin/true-ის შეცვლა პაკეტირების კონტრაქტს ცვლის და არა გვირაბს.

wrapper დელეგირებას ახდენს. ის უშვებს იმ instance-unit-ებს, რომლებსაც პაკეტის კონფიგურაცია ან მისი systemd გენერატორი აწვდის, ამიტომ ცარიელი პროცესების სია გვირაბზე არაფერს ამტკიცებს. როცა არც ერთი ინსტანსი არ არის არჩეული, wrapper მაინც წარმატებულია და მაინც არაფერს უშვებს. მდგომარეობა პასუხობს, გაეშვა თუ არა wrapper, და არა, არსებობს თუ არა გვირაბი.

წაიკითხეთ status-ის გამოსავლის სამი ხაზი და არა ფრჩხილებში ჩასმული სიტყვა. Loaded ასახელებს unit-ის ფაილს, რომელიც systemd-მა წაიკითხა, Active ატარებს ბოლო წარმატებული გაშვების დროის ნიშანს, და არმყოფი Main PID შეესაბამება დასრულებულ ერთჯერად დავალებას. ეს სამი ხაზი ასევე გზაა, რომ განასხვაოთ ეს wrapper სერვისისგან, რომელიც გაშვებიდან ერთ წამში ჩამოინგრა.

ჩამოთვალეთ unit-ები, სანამ status-ს კვლავ წაიკითხავთ

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

systemctl list-units 'openvpn*'

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

systemctl list-unit-files 'openvpn*'

წაიკითხეთ ორივე სია ერთად, რადგან შაბლონი მეორეში და ინსტანსი პირველში ორი სხვადასხვა პასუხია. არსებული შაბლონი და მომუშავე ინსტანსი ერთი და იგივე ფაქტი არ არის, და მხოლოდ მეორე ნიშნავს გვირაბს. პაკეტების განლაგება ასევე განსხვავდება დისტრიბუციებსა და OpenVPN-ის ვერსიებს შორის. ძველი openvpn@ შაბლონი, განცალკევებული client და server წყვილი და დისტრიბუციის wrapper ყველა შეიძლება ლეგიტიმური იყოს საკუთარ პაკეტში.

მოერგეთ თქვენს მანქანას და არა ნაპოვნ სახელმძღვანელოს. სხვის გამოსავალში ინსტანსის სახელი შეიძლება იყოს office, მაშინ როცა თქვენი home ან work არის. გადადის მეთოდი და არა სტრიქონი.

მიჰყევით ინსტანსის სახელს ფაილამდე, რომელსაც ის კითხულობს

upstream client შაბლონში unit-ის სამუშაო დირექტორია /etc/openvpn/client და მისი ბრძანება იქიდან იღებს %i.conf-ს, ამიტომ openvpn-client@office კითხულობს /etc/openvpn/client/office.conf-ს. დაადასტურეთ ეს დაკავშირება დაყენებულ unit-ზე და ნუ დაეყრდნობით მაგალითს, რადგან თქვენი შაბლონი შეიძლება უფრო ძველი იყოს ან დისტრიბუციის გადაწერა:

systemctl cat [email protected]

წაიკითხეთ drop-in-ები, რომლებიც ამ გამოსავლის ბოლოში ჩნდება, რადგან .d/-ის ქვეშ არსებული ფაილი შეიძლება შეცვალოს ExecStart, სამუშაო დირექტორი ან კონფიგურაციის გზა. პროფილი, რომელიც office.ovpn-ად ჩამოტვირთეთ, ის ფაილი არ არის, რომელსაც ინსტანსი ხსნის. ეს სხვაობა ჩვეულებრივი მიზეზია იმისა, რომ შეცდომა ასახელებს გზას, რომელიც არასდროს შეგიცვლიათ.

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

გაუშვით ის, შემდეგ წაიკითხეთ ამ ინსტანსის ჟურნალი

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

გაშვება და ჩართვა ცალკე გადაწყვეტილებებია: start unit-ს ახლა ასრულებს, enable შემდეგ ჩატვირთვას აწყობს, და enable --now ორივეს ერთ ნაბიჯში აკეთებს. daemon-reload unit-ის განსაზღვრებებს ხელახლა კითხულობს და არ გადატვირთავს მომუშავე პროცესს და არ იყენებს შეცვლილ პროფილს. პროფილის შეცვლის შემდეგ გადატვირთეთ ინსტანსი, რადგან სწორედ ეს კითხულობს ფაილს ხელახლა.

ნუ დააყენებთ მეორე მმართველს იმავე გვირაბზე

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

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

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