OpenVPN და HTTPS 443 პორტზე: ვის ეკუთვნის მსმენელი?
TCP და UDP 443 ცალკე სოკეტებია. ერთი TCP მსმენელის გაზიარებას მფლობელი სჭირდება, ხოლო OpenVPN-ის პორტის გაზიარება ვიწრო შეთანხმებაა, არა პროქსის ხრიკი.
ორ სერვისს შეუძლია ორივემ უპასუხოს 443 პორტზე, არასოდეს კონკურენციის გარეშე, რადგან მსმენელი განისაზღვრება ტრანსპორტით, მისამართითა და პორტით ერთად და არა მხოლოდ ნომრით. დააყენეთ ვებ სერვერი და OpenVPN ერთ მანქანაზე, და ერთადერთი კითხვა, რომელიც პირველად პასუხს იმსახურებს, არის რომელ სოკეტს ითხოვს თითოეული პროცესი ბირთვისგან. ჩაწერეთ ეს სია კონფიგურაციის რედაქტირებამდე, და «მისამართი უკვე გამოყენებაშია» შეცდომების უმეტესობა თავისით აიხსნება. სიის შემდეგ ყველაფერი არჩევანია UDP მსმენელს, საერთო TCP სოკეტსა და პროტოკოლით მარშრუტიზებელ წინა ნაწილს შორის.
დაიწყეთ იმ სოკეტით, რომელსაც თითოეული პროცესი ითხოვს
bind წარმატდება ან ვარდება ამ სამეულზე, ამიტომ ორი დემონი მხოლოდ მაშინ ეჯახება, როცა სამივე ნაწილი ემთხვევა. ამიტომ TCP 443-ზე ვებსაიტი უსასრულოდ თანაარსებობს UDP 443-ის OpenVPN მსმენელთან, და ამიტომ ერთ-ერთი მათგანის იმავე ჰოსტის მეორე ლოკალურ მისამართზე გადატანაც ამთავრებს კამათს. წაიკითხეთ ცოცხალი მსმენელები, და არა ის ფაილები, რომლებსაც ისინი უნდა შეექმნათ, რადგან მოძველებული include ან დავიწყებული unit ფაილი თქვენს გახსენებულ რედაქტირებაზე დიდხანს ცოცხლობს.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
გაუშვით ss -lntup root-ის სახით და წაიკითხეთ ყველა ხაზი, რომელიც 443-ს იხსენებს, IPv6 ჩანაწერების ჩათვლით. v6-ის უნივერსალური მსმენელი ჩვეულებრივ v4 ტრაფიკსაც იღებს, და სწორედ ასე ინახავს დავიწყებული მსმენელი პორტს დაკავებულად მას შემდეგ, რაც შეცვლით იმ ფაილს, რომელიც პასუხისმგებლად მიგაჩნდათ. თუ პროცესის სახელი გაგიკვირდათ, შევიწროეთ გამოტანა ss -lntup 'sport = :443'-ით, სანამ რამეს შეეხებით.
გადაიყვანეთ გვირაბი UDP-ზე, როცა ქსელი იძლევა საშუალებას
UDP მსმენელი მთლიანად გვერდს უვლის შეჯახებას და ჩვეულებრივ ყველაზე მოკლე შეკეთებაა, რადგან არც ერთი სოკეტი არ იზიარება და გზაზე დამატებითი პროდუქტი არ შემოდის. მაგრამ ეს უფასო არ არის. ზოგიერთი კლიენტის ქსელი UDP 443-ს reset-ის გაგზავნის გარეშე ყრის, ამიტომ გვირაბი bind-ზე ჩავარდნის ნაცვლად დადგენას წყვეტს, და მომხმარებელი იუწყება, რომ VPN გამორთულია, წასაკითხი შეცდომის გარეშე. UDP მსმენელი ასევე გადაურჩება ვებ შრის გადატვირთვას, რაც მნიშვნელოვანია მანქანაზე, რომლის საიტიც ხშირად ხელახლა ვრცელდება. გამოსცადეთ იმ ქსელიდან, სადაც მომხმარებლები სხედან, რადგან სერვერზე არსებული shell მხოლოდ იმას ამტკიცებს, რომ სერვერი საკუთარ თავს აღწევს.
შეცვალეთ ტრანსპორტი სერვერის კონფიგურაციაში და კლიენტის პროფილშიც ერთად. პროფილი, რომელიც ჯერ კიდევ TCP-ს ითხოვს, გადაეშვება ხელახალი დაკავშირების ციკლებში მხოლოდ UDP მსმენელის წინააღმდეგ, და ეს ქსელური ხარვეზის მსგავსია, სანამ ორ ფაილს არ შეადარებთ.
მიეცით VPN პროცესს TCP 443-ის მფლობელობა და დანარჩენი გადაამისამართეთ
Community OpenVPN TCP სერვერის რეჟიმში კითხულობს შემომავალი კავშირის პირველ ბაიტებს და ყველაფერს, რაც მისი პროტოკოლი არ არის, HTTPS უკანა ნაწილზე გადაამისამართებს, სწორედ ამისთვისაა port-share დირექტივა. უკანა ნაწილი ჩვეულებრივი ვებ სერვერია TLS-ით ჩართული, რომელიც ამ დირექტივაში ჰოსტითა და პორტით სახელდება და არა URL-ით.
port-share 10.0.0.5 8080
მანქანაზე, სადაც საიტს მეორე კერძო მისამართი აქვს, ეს ხაზი არა-VPN ტრაფიკს 10.0.0.5:8080-ზე აგზავნის, ამიტომ HTTPS ვირტუალური ჰოსტი იქ უნდა იყოს მიბმული და firewall-მა ლოკალური ნახტომი უნდა დაუშვას. ვებ სერვერმა თავად უნდა დაასრულოს TLS, რადგან მომავალი ბაიტები ბრაუზერის ორიგინალური ხელის ჩამორთმევაა და შუალედში არაფერს გაუშიფრავს ისინი. მიმართეთ დირექტივა ჩვეულებრივ HTTP მსმენელზე და ბრაუზერი მიიღებს არასწორი მეთოდის შეცდომას, რომელიც გატეხილ საიტად იკითხება და არა არასწორ ადგილას დაყენებულ უკანა ნაწილად. დირექტივა მხოლოდ TCP სერვერის რეჟიმში არსებობს, და UDP მსმენელს შესამოწმებელი ნაკადი არ აქვს.
რადგან VPN პროცესი ყველა კავშირს იღებს, ვებ აპლიკაცია ხედავს გადამისამართებულ მოთხოვნას, რომელიც ჰოსტის საკუთარი მისამართებიდან მოდის და არა ვიზიტორისგან. ყველაფერი, რასაც კლიენტის ნამდვილი მისამართი სჭირდება, დამოკიდებულია უკანა ნაწილში PROXY პროტოკოლის მხარდაჭერაზე ან მის დამმატებელ წინა ნაწილზე. უკანა ნაწილის სხვა ლოკალურ მისამართზე გადატანა ვიზიტორის მისამართს არ აბრუნებს; ის მხოლოდ იმას ცვლის, თუ ჰოსტის რომელ მისამართებს ჩაწერს საიტი. ჩაწერეთ ეს შეზღუდვა განლაგების შენიშვნებში, სანამ ანალიტიკური ანგარიში კითხვას დასვამს.
უკუ პროქსი არასწორი ინსტრუმენტია; მეოთხე დონის მარშრუტიზატორი არა
HTTP უკუ პროქსი ასრულებს TLS-ს, რომ მოთხოვნები წაიკითხოს, რაც ნიშნავს, რომ OpenVPN-ის ნაკადს ხელუხლებლად ვერ გაატარებს. მეოთხე დონის მარშრუტიზატორს, რომელიც SNI-ით ან პირველი პაკეტის შემოწმებით გადაამისამართებს, შეუძლია ორივეს წინ დადგეს, თუ არ დაასრულებს იმ სესიას, რომელზეც VPN არის დამოკიდებული. ორი მოწყობილობა დიაგრამაზე ერთნაირად გამოიყურება და სოკეტთან სრულიად განსხვავებულად იქცევა.
კომერციული Access Server მოყვება პორტის გაზიარების საკუთარ პარამეტრებს, და ისინი ერთ-ერთზე არ ასახავს საზოგადოების დირექტივას. დაადგინეთ პროდუქტი და ვერსია, სანამ მეორისთვის დაწერილ სახელმძღვანელოს მოარგებთ. ჩუმად უგულებელყოფილი კოპირებული პარამეტრი უარესია, ვიდრე პარამეტრის არარსებობა, რადგან მსმენელების სია შემდეგაც დამაჯერებლად გამოიყურება.
გამოსცადეთ ვებსაიტი და გვირაბი, როგორც ორი ცალკე გზა
ჩატვირთეთ საიტი და დააკავშირეთ გვირაბი, შემდეგ კვლავ წაიკითხეთ მსმენელების სია, რომ ნახოთ რომელი პროცესი ფლობს 443-ს ახლა. ჩატვირთული გვერდი VPN-ზე არაფერს ამტკიცებს, და დაკავშირებული გვირაბი საიტზე არაფერს ამტკიცებს, თუმცა ორივე ერთსა და იმავე ნომერს იყენებს. ქვემოთ სამი ბრძანება ამოწმებს საერთო სოკეტს, ვებ გზას და VPN სერვისს ამ თანმიმდევრობით.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
შეადარეთ კლიენტის მისამართი უკანა ნაწილის წვდომის ჟურნალში იმავე მომენტის VPN ჟურნალის მისამართს. თუ საიტი ყოველ ვიზიტორს ჰოსტის სახით თავად ჩაწერს, გადამისამართება მუშაობს, მისამართის დამუშავება კი არა. თუ ორივე ჟურნალი ჩუმად არის, წინა ნაწილს კავშირი არასოდეს გადაუცია. ყოველ შემთხვევაში, მსმენელების სია წყვეტს, ვინ იღებს სოკეტს, და სწორედ ეს ფაქტია დასადასტურებელი, სანამ კიდევ ერთ ფაილს შეცვლით.
დატოვეთ ეს მსმენელების რუკა კონფიგურაციის გვერდით, რათა 443-ს შემდეგი შემხები ადამიანი იცოდეს, რომელი პროცესი იღებს და სად წავიდა მეორე პროტოკოლი. დაადასტურეთ მფლობელობა ცვლილების შემდეგ და ნუ დაეყრდნობით იმას, რაც რედაქტირებას უნდა გაეკეთებინა.