OpenVPN შეცდომის გარეშე არ იწყება? ნახეთ journal

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

გამოსავალს ოთხი ადგილი შთანთქავს: unit-ის journal, plugin, რომელიც ფლობს კავშირს, გვირაბის მეორე ბოლო და სხვა ბინარული ფაილი, ვიდრე ის, რომელიც, თქვენი აზრით, მუშაობს. თითოეულს თავისი შემოწმება აქვს.

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

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

დაამატეთ systemctl show -p Result -p ExecMainStatus openvpn-client@office სუფთა გასვლის სიგნალისგან გასაყოფად. სტატუსი 1 და Result=exit-code პროგრამის გადაწყვეტილებაა; Result=signal ან ტაიმაუტი პირიქით გარემოზე მიუთითებს, და პროფილის რედაქტირების არც ერთი რაოდენობა ამას არ შეცვლის. ჩაწერეთ ორივე მნიშვნელობა სანამ რაიმეს გადატვირთავთ, რადგან გადატვირთვა შლის იმ დროებით მდგომარეობას, რომელმაც ისინი წარმოქმნა.

instance-ის სახელი გზის ნაწილია

შეფუთული შაბლონის unit არ იღებს ფაილის გზას. ის იღებს instance-ის სახელს, და ეს სახელი ემატება დირექტორიას პროფილის საპოვნელად: office Debian და Ubuntu პაკეტებში წყდება /etc/openvpn/client/office.conf გზად. ფაილი სახელად office-v2.conf რომელიც გაშვებულია როგორც @office არასდროს იკითხება, და unit ჩუმად გადის, რადგან მისი თვალსაზრისით საქმე არ იყო. საძიებო დირექტორია განსხვავდება client და server რეჟიმებში, ამიტომ იგივე შეცდომა შაბლონის შეცვლისას სულ სხვა ადგილს მიუთითებს.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

როცა plugin ფლობს გვირაბს, ტერმინალი ვერაფერს ხედავს

desktop applet-იდან დაწყებულ კავშირს NetworkManager ფლობს, და მისი OpenVPN გამოსავალი გადის ამ სერვისის journal-ში და არა თქვენს გახსნილ shell-ში. client-ის ხელით გაშვება და არაფრის დანახვა ამ განლაგებაში მოსალოდნელია, რადგან ხელით გაშვებული პროცესი არ არის ის, რომელიც კავშირს ატარებს.

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

დამოუკიდებელი გაშვება შეტყობინებების წაკითხვისთვისაა, არა მართული კავშირის ჩასანაცვლებლად, და ორივე შემდეგ განსხვავდება: DNS ინტეგრაცია, მარშრუტები და სიცოცხლის ხანგრძლივობა plugin-ს ეკუთვნის. დამოუკიდებელ გაშვებაში parse შეცდომის გასწორება ავტომატურად არ ასწორებს სახელების გარჩევას, როცა applet იღებს კონტროლს, ამიტომ ორი დაკვირვება ცალკე შეინახეთ.

ორი ბინარული, ერთი PATH

ხელით აწყობილი ინსტალაცია /usr/local ქვეშ იმარჯვებს shell გამოძახებაზე, რადგან /usr/local/sbin უსწრებს /usr/sbin-ს Ubuntu-ის ნაგულისხმევ PATH-ში. unit არ იყენებს თქვენს PATH-ს; ის ასრულებს ExecStart-ში დაწერილ აბსოლუტურ გზას. ასე რომ, ვერსია, რომელიც თქვენს ტერმინალში მუშაობს, და ვერსია, რომელიც სერვისად ვარდება, შეიძლება ნამდვილად სხვადასხვა პროგრამა იყოს.

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

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

კიდევ ერთი გარემოს განსხვავება იმავე ადგილას იმალება. შეფუთული unit ეყრდნობა /run ქვეშ არსებულ გაშვების დირექტორიას, რომელსაც systemd მისთვის ქმნის; ხელით დაწერილი შემცვლელი unit, რომელიც ამ პარამეტრს გამოტოვებს, შეიძლება ჩავარდეს ერთი ფაილის გახსნამდე, და ხარვეზი ჩვეულებრივ უარად გამოიყურება OpenVPN შეტყობინების გარეშე.

ხარვეზები, რომლებზეც client ვერ შეატყობინებს

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

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

დაამუშავეთ ფენები თანმიმდევრობით: არსებობს unit და სწორია instance-ის სახელი, მიაღწია რამე journal-ს ან ფაილს --log, რომელი ბინარული და პროფილი მუშაობდა სინამდვილეში, და ხარვეზი ლოკალურია თუ შორეული. ყოველი პასუხი ხსნის ერთ ფენას. პროფილიდან დაწყება ნიშნავს ფაილის გადაწერას, რომელიც შესაძლოა არასდროს გახსნილა.