OpenVPN არ ირთვება: წაიკითხეთ პირველი ხაზი და არა კონფიგურაცია

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

სამი მხოლოდ-კითხვადი ბრძანება მიგიყვანთ იქ: ჯერ journalctl -u openvpn@server -b --no-pager, შემდეგ systemctl status openvpn@server, და ss -lunp UDP მსმენელებისა და მათი მფლობელებისთვის.

პირველი ხაზი ირჩევს ტოტს

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

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

კიდევ ვინ უჭირავს 1194 პორტი

დამნაშავე ჩვეულებრივ არ არის მეორე სერვერი, რომელიც ვიღაცამ განზრახ დააყენა. დაელოდეთ ხელით გაშვებულ კლიენტს, რომელიც ჯერ კიდევ ცოცხალია სხვა ტერმინალში, ან მეორე პროფილს, რომელმაც შემთხვევით იგივე პორტი აირჩია, ან მომწოდებლის პაკეტს, რომლის საკუთარი გვირაბი 1194-ს უჭირავს. სოკეტის მფლობელი ჩანს ss -lunp-ში; გადაეცით ეს PID systemctl status-ს, რათა გაიგოთ, პასუხისმგებელია თუ არა ერთეული. გამორთეთ იგი მისივე მართვის გზით და არა სიგნალით.

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

წაშლის შემდეგ დარჩენილი ერთეულები

წაშლა შლის ბინარებს; ხელით დაწერილი ერთეულის ფაილები, ჩვეულებრივ /etc/systemd/system-ის ქვეშ, გადარჩება. შემდეგ Systemd კვლავ ცდის ერთეულს, რომელიც მიუთითებს გზაზე, რომელიც აღარ არსებობს, და შეტყობინება ეხება სწორედ იმ დაკარგულ ფაილს და არა გუშინდელ წაშლას. systemctl status აჩვენებს ერთეულის ფრაგმენტის გზას ზემოთ, ამიტომ სანამ რამეს წაშლით, შეამოწმეთ იგი dpkg -S-ით. როცა ობოლი გაქრება, systemctl daemon-reload და systemctl reset-failed ასუფთავებენ მდგომარეობას; წინააღმდეგ შემთხვევაში ყოველი შემდგომი სტატუსის შემოწმება მას მემკვიდრეობით იღებს.

როცა which openvpn პასუხობს რაღაცას /usr/local-ის ქვეშ, თამაშში მყოფი ბინარი მომწოდებლის ინსტალატორიდან მოვიდა და არა apt-იდან. ასეთი ინსტალატორი ჩვეულებრივ თავის მსმენელს, თავის ჩატვირთვის ჩანაწერს და თავის კონფიგურაციის საქაღალდეს მოაქვს, ამიტომ ხილული ბრძანების წაშლა სოკეტს დაკავებულს ტოვებს.

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

სანამ ხელახლა ცდით, მოაწესრიგეთ მდგომარეობა

გაასუფთავეთ წარუმატებელი მდგომარეობა სანამ მისგან დასკვნებს გამოიტანთ: systemctl reset-failed შლის მთვლელებს, და systemctl status შემდეგ იუწყება ერთეულის მიმდინარე მდგომარეობას და არა მის ისტორიას. ერთხელ გაუშვით და წაიკითხეთ სწორედ იმ გაშვების ჟურნალი და არა მანქანის საერთო მდგომარეობა. ერთეული, რომელიც აქტიურად აცხადებს თავს, მაშინ როცა გვირაბი არაფერს გადააქვს, ცალკე პრობლემაა და ბევრად უფრო ხშირი. ორივე ერწყმის ერთმანეთს ბაგების რეპორტებში, რადგან ორივე მთავრდება მომხმარებლის სიტყვებით, რომ VPN არ მუშაობს.

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