რატომ არ შეუძლია nc -uz-ს დაამტკიცოს, რომ OpenVPN სერვერი მზადაა

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

რა შეუძლია და რა არ შეუძლია UDP შემოწმებას დააკვირდეს

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

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

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

სამი გამომძახებელი, სამი განსხვავებული კითხვა

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

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

შემოწმება ააგეთ მიმდინარე ინსტანციიდან

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

გატეხეთ ის განზრახ და დააკვირდით შემოწმებას

შემოწმება სანდოა მხოლოდ მას შემდეგ, რაც მისი ჩავარდნა გინახავთ. გააჩერეთ სერვერი, გაუშვით შემოწმება და დაადასტურეთ მოსალოდნელი შედეგი. შემდეგ ხელახლა გაუშვით ის და დაადასტურეთ, რომ შემოწმება სხვა ცვლილების გარეშე აღდგება.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

წაიკითხეთ ბლოკი სტრიქონობრივად. netcat ბრძანება ბეჭდავს exit=0 მაშინ, როცა არაფერია მიბმული, და ეს არის მთელი პრობლემა ერთ სტრიქონში. პირველი ss არაფერს ბეჭდავს, გადატვირთვა წარმატებით სრულდება, და მეორე ss კვლავ აჩვენებს მსმენელს. თუ თქვენი შემოწმება გაჩერებული სერვერის წინააღმდეგ გადის, ის ლოკალურ სტეკს ზომავს და სხვა არაფერს.

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

რა უნდა თქვას სტატუსის ხაზმა

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

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

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