რომელ პორტებზე ისმენს სინამდვილეში OpenVPN Access Server?
გაიარეთ სოკეტების სია Access Server-ის ჰოსტზე: ამოიცანით ნაგულისხმევი მსმენელები, გამოყავით loopback გამოქვეყნებულებისგან და შეამოწმეთ გადამისამართება პორტის დახურვამდე.
თქვენ უშვებთ ss -lntup Access Server-ის ჰოსტზე და იღებთ სიას, რომელიც ორჯერ გრძელია ვიდრე მოსალოდნელი იყო. ჩანაწერების ნახევარი დემონის ფორმის პორტებია, რომლებზეც ინსტალაციის დროს არავის უხსენებია. რეფლექსია დახუროს ყველაფერი, რაც 443 ან 1194 არ არის, და სწორედ ასე ამტვრევენ ადამიანები საკუთარ კლიენტურ პორტალს.
Access Server ერთი მსმენელი არ არის. ეს არის VPN სერვისი, ვებ სერვისი და კლასტერის მონაწილე, და მას შეუძლია შექმნას დამატებითი დემონისეული პორტები და firewall-ის გადამისამართებები იმის მიხედვით, რამდენი TCP დემონი გაქვთ კონფიგურირებული.
გაიარეთ ინვენტარი თანმიმდევრობით: წაიკითხეთ სოკეტები, გაისახეთ ნაცნობები, დაახარისხეთ დანარჩენი მფლობელისა და მიბმის მიხედვით, შემდეგ შეამოწმეთ რა აქვეყნებს მათ სინამდვილეში.
დაიწყეთ ერთი მხოლოდ-წაკითხვის ბრძანებით
sudo ss -lntup გაძლევთ ტრანსპორტს, ლოკალურ მისამართს, პორტს და მფლობელ პროცესს ყოველი მსმენელი სოკეტისთვის. დროშები მნიშვნელოვანია: -l მოსმენა, -n რიცხვითი, -t TCP, -u UDP, -p პროცესი. root-ის გარეშე მიიღებთ სოკეტებს, მაგრამ არა პროცესების სახელებს, და სწორედ ეს სვეტი გჭირდებათ კლასიფიკაციისთვის.
სანამ რაიმე აზრს ჩამოაყალიბებთ, თითოეული სტრიქონისთვის ჩაწერეთ ოთხი ველი: პროტოკოლი, მიბმის მისამართი, პორტი და ბრძანება. Access Server-ის ვერსია და კონფიგურირებული დემონების რაოდენობა შეინახეთ ამ სიის გვერდით, რადგან ორივე ცვლის მოლოდინს.
ორი იდენტურად გარეგნული სტრიქონი იდენტური არ არის. ერთსა და იმავე ნომერზე TCP და UDP ცალკე სოკეტები არიან ცალკე ზემოქმედებით, და 0.0.0.0 და :: ცალკე მიბმები არიან ცალკე მისამართების ოჯახებისთვის. მხოლოდ 127.0.0.1 მისამართზე მიბმული სერვისი პირდაპირ მიუწვდომელია სხვა ჰოსტიდან, თუმცა ლოკალურ გადამისამართებას ჯერ კიდევ შეუძლია მისი გამოქვეყნება.
მსმენელები, რომლებიც უნდა ამოიცნოთ
ეს ნაგულისხმევი მნიშვნელობები ფარავს განლაგებების უმეტესობას და გაძლევთ შედარების საფუძველს. ეს ნაგულისხმევია, არა სრული ნებადართული სია.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
ყველაფერი ამის მიღმა საჭიროებს ახსნას და არა ვარაუდს. ხშირად ნახავთ მხოლოდ-ლოკალურ მსმენელებს, რომლებიც ეკუთვნის კომპონენტებს, რომლებსაც პროდუქტი თავისთვის აყენებს. დაადასტურეთ ისინი PID-ით და სერვისის კონფიგურაციით და არა დამახსოვრებული პორტის ნომრით, და ნუ მოექცევით უცნობ პორტს მტრად მხოლოდ იმიტომ, რომ უცნობია.
ნაცნობი წყვილის გარეთ მყოფი სოკეტიც ავტომატურად ნარჩენი არ არის. როცა რამდენიმე TCP დემონია კონფიგურირებული, Access Server ქმნის მსმენელებს თითოეული დემონისთვის და მათზე გადამისამართებს ტრაფიკს, ამიტომ მათი რაოდენობა და პორტების მნიშვნელობები მიჰყვება ამ კონფიგურაციას.
დაახარისხეთ სანამ რაიმეს დახურავთ
თითოეული გაურკვეველი სტრიქონისთვის უპასუხეთ სამ კითხვას ამ თანმიმდევრობით.
- მფლობელი და დანიშნულება. შეუსაბამეთ PID ერთეულს ან პროცესს და წაიკითხეთ ამ სერვისის კონფიგურაცია. თუ მფლობელს ვერ დაასახელებთ, არ ხართ მზად სოკეტზე რაიმე გადაწყვიტოთ.
- მიბმის არეალი. Loopback ლოკალურია სახელთა სივრცისთვის. Wildcard მიბმა ხელმისაწვდომია მხოლოდ მაშინ, როცა მარშრუტიზაცია, ჰოსტის ფილტრაცია და ღრუბლოვანი დონის ნებისმიერი წესი ამის საშუალებას იძლევა, ამიტომ მიბმის მისამართი აუცილებელია, მაგრამ არა საკმარისი. შეამოწმეთ IPv4 და IPv6 ცალკე გადაწყვეტილებებად.
- გამოქვეყნებული გზა. მოძებნეთ სერვისის გადამისამართება, დემონისეული გადამისამართებები, გარე პროქსი და ეფექტური firewall პოლიტიკა. ეს არის ნაბიჯი, რომელსაც ადამიანები გამოტოვებენ, და სწორედ ის აქცევს უვნებლად მოჩვენებულ backend პორტს ხელმისაწვდომ ადმინისტრაციულ გზად.
იგივე კითხვა სხვაგვარად იკითხება ჰოსტის გარედან. ჰოსტის firewall წესის გარეშე პორტი მაინც შეიძლება დაიხუროს ღრუბლოვანი უსაფრთხოების ჯგუფის მიერ, და ნებადამცემი ჰოსტის წესის მქონე პორტი შეიძლება მიუწვდომელი იყოს, რადგან მასზე არაფერი მარშრუტიზდება. შეხედეთ ორივე ბოლოს სანამ ინვენტარის დასკვნას დაწერთ.
სადაც გამოქვეყნებული გზა განსხვავდება სოკეტების სიისგან
Access Server-ის საკუთარი დოკუმენტაცია მოიცავს იმ შემთხვევას, რომელიც ყველაზე მეტ დაბნეულობას იწვევს: როცა რამდენიმე TCP დემონი მუშაობს, წინა პორტი გადაამისამართებს დემონისეულ პორტებზე და ხილული განლაგება წყვეტს სოკეტების სიასთან შესაბამისობას. ვებ ინტერფეისის ფილტრაციის გაკვეთილი აღწერს ამ წესებს და იმას, თუ რატომ შეიძლება მხოლოდ აშკარა პორტისთვის დაწერილმა ფილტრმა სრულად გამოტოვოს გადამისამართებული გზა.
კლასტერის მართვა მეორე ადგილია, სადაც ვერსია მნიშვნელოვანია. 3.0-დან ის იზიარებს 943-ს; უფრო ძველი კლასტერის კონფიგურაციები იყენებდნენ 945-ს. ერთი მათგანის გახსნა ან დაბლოკვა ვერსიის შემოწმების გარეშე ქმნის მოწესრიგებულად მოჩვენებულ და მცდარ ინვენტარს.
ასე რომ, გარედან ხილული ზედაპირი სამი რამის გაერთიანებაა: მსმენელი სოკეტები, მათი ხელახლა გამომქვეყნებელი გადამისამართების წესები და ჰოსტის წინ არსებული ქსელური კონტროლები. ნებისმიერი ინვენტარი, რომელიც მხოლოდ პირველს აღრიცხავს, არასრულია, და ნებისმიერი ცვლილება, რომელიც მხოლოდ პირველს ითვალისწინებს, ან გზას ღიად დატოვებს, ან სერვისს მოწყვეტს.
შეამოწმეთ ყოველი ცვლილების შემდეგ
შეცვალეთ მსმენელის პარამეტრები მხარდაჭერილი კონფიგურაციის მფლობელის მეშვეობით და ამ დროს ღიად შეინახეთ აღდგენის კონსოლი. დისტანციურ ჰოსტზე ვებ ინტერფეისზე ადმინისტრაციული წვდომის დაკარგვა არ აღდგება იმ VPN-ით, რომელიც ახლახან გამორთეთ.
შემდეგ გადაამოწმეთ ოთხი რამ, რაც განლაგებას ჩვეულებრივ სჭირდება: VPN კლიენტი უკავშირდება, კლიენტური პორტალი იტვირთება, ადმინისტრაციული წვდომა მუშაობს და კლასტერის კომუნიკაცია კვლავ ფუნქციონირებს, თუ ერთზე მეტ კვანძს უშვებთ. მხოლოდ-VPN ტესტი მშვიდად გადის, სანამ პორტალი გატეხილია.
დაასრულეთ თითოეული სერვისისთვის ნებადართული გზის ჩაწერით: რომელი სოკეტი, რომელი მიბმა, რომელი გადამისამართების წესი, რომელი ქსელური კონტროლი. სწორედ ეს დოკუმენტია სასარგებლო უსაფრთხოების შედეგი. სოკეტების მინიმალური რაოდენობა არ არის, და არც მასობრივი გადატვირთვა, რომელიც ხურავს მსმენელებს, რომელთა იდენტიფიკაცია არავის დაუმთავრებია.