რომელი OpenVPN ინსტანცია იყენებს სინამდვილეში თქვენს PiVPN პროფილს?

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

დამხმარე და დემონი სხვადასხვა ობიექტია

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

systemd ჰოსტზე დაიწყეთ აქტიური ერთეულიდან და არა საქაღალდის სიიდან. სახელი დამოკიდებულია შეფუთვაზე: Debian-ისა და Raspberry Pi OS-ის იმიჯები ჩვეულებრივ გვთავაზობენ შაბლონურ ინსტანციას, მაგალითად openvpn-server@server, ხოლო ძველი ინსტალაციები იყენებენ openvpn@server. ჰკითხეთ მმართველს, რომელი მუშაობს, ფაილის სახელიდან გამოცნობის ნაცვლად.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

წაიკითხეთ ExecStart= იმ გამოსავალში. ის ასახელებს შესრულებად ფაილს და ოფციებს, რომლებსაც მმართველი რეალურად უშვებს, მათ შორის ნებისმიერ --config ბილიკს; იქვე მდებარე კონფიგურაციის ფაილი, რომელზეც არც ერთი ბრძანება არ მიუთითებს, არ არის მოქმედი გვირაბის ნაწილი.

თვალი ადევნეთ კონფიგურაციის ჯაჭვს, რომელიც დემონმა ამოხსნა

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

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

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

შეუსაბამეთ ჟურნალი პროცესს და არა შეცდომას, რომელიც გახსოვთ

ჟურნალის ორი დანიშნულება გავრცელებულია და მხოლოდ ერთი მათგანია journal. log-append დაყენებისას დემონი წერს იმ ფაილში და journal ინახავს ცოტას გაშვების სტრიქონების გარდა. მის გარეშე journalctl არის მოვლენების წყარო.

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

გვირაბის ხელახლა აგება დიაგნოსტიკური ნაბიჯი არ არის

მაცდური მოკლე გზა მეორე, უფრო მარტივი გვირაბის აღმართვაა: სტატიკური გასაღები, სერტიფიკატების გარეშე, დამატებითი ავთენტიფიკაციის გარეშე. ის ხშირად დაუკავშირდება და მხოლოდ იმას ამტკიცებს, რომ ორ ჰოსტს შეუძლია UDP ან TCP-ის გატარება ერთმანეთს შორის. არაფერს ამბობს იმაზე, თუ რატომ ვარდება სერტიფიკატებით ავთენტიფიცირებული განლაგება, და ჩუმად ცვლის უსაფრთხოების მოდელს, რომლის შენარჩუნებაც მოგთხოვეს.

იგივე ეხება tls-auth ან tls-crypt გამორთვას, verify-x509-name შესუსტებას, ან მეორე ფაქტორის მიტოვებას მწვანე სტატუსისთვის. გვირაბი, რომელიც მაშინ უკავშირდება, როცა შემოწმება მოიხსნა, სხვა სისტემაა და არა შეკეთებული.

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

რა უნდა გადასცეთ შემდეგ ადამიანს

ჩაწერეთ ოთხი ფაქტი, სანამ ჯერ კიდევ გაქვთ: OpenVPN-ის ვერსია openvpn --version გამოსავლიდან, აქტიური ერთეული, კონფიგურაციის ჯაჭვი მისი ჩართვებით და ერთ მცდელობას დაფარვის ჟურნალის ფანჯარა. ეს ოთხი ბუნდოვან ჩივილს გამეორებად საქმედ აქცევს.

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

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