SSTP-მ 443 პორტი დაიკავა: რატომ არ ირთვება Apache

Apache 443-ზე პასუხის გაცემას წყვეტს იმ შუადღეს, როცა ვიღაც შემომავალ VPN კავშირებს რთავს, და მისი შეცდომების ჟურნალი bind-ს ადანაშაულებს და არა მის უკან მდგარ ჯავშნას. Windows Routing and Remote Access იმ მომენტში რთავს SSTP-ს, და SSTP მსმენელი HTTP სტეკის მეშვეობით ითხოვს TCP 443-ს, სანამ რომელიმე კლიენტი ავთენტიფიცირდება. მოთხოვნა ძალაში რჩება მაშინაც, როცა სერტიფიკატი აკლია, სახელი არასწორია ან ყოველი handshake უარყოფილია, ასე რომ VPN, რომელშიც ვერავინ შედის, მაინც იკავებს პორტს. ჯერ წაიკითხეთ მოსმენის ცხრილი; 443-ის მფლობელი PID წყვეტს, რომელი შესწორება ქვემოთ არის თქვენთვის საერთოდ ღია.

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

SSTP PPP-ს TLS სესიაში ახვევს, ამიტომ სჭირდება 443 და ამიტომ გადის პროქსებში, რომლებიც სხვა გვირაბებს უგდებენ. მსმენელი არ არის socket, რომელსაც VPN სერვისი თავისთვის ხსნის: SstpSvc მას ბირთვის HTTP დრაივერთან არეგისტრირებს, ამიტომ პორტი ჯავშნილი რჩება, სანამ სერვისი მუშაობს. ეს რეგისტრაცია არასოდეს კითხულობს სერტიფიკატს, რაც ნიშნავს, რომ ვადაგასული სახელი, შეუსაბამო subject ან საერთოდ სერტიფიკატის არარსებობა 443-ს დაკავებულს ტოვებს. შემდეგ ჩავარდნები ორ მიმართულებად იყოფა: უარყოფილი handshake-ები System ჟურნალში RasSstp-ის ქვეშ ხვდება, ხოლო ვებ სერვერს მხოლოდ იმის თქმა შეუძლია, რომ bind ვერ შეძლო.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

პირველი ხაზი აბრუნებს მფლობელ PID-ს; მეორე ასახელებს მის უკან მდგარ სერვისს, და პასუხი ჩვეულებრივ HTTP სერვისი ან RRAS სტეკია. როცა tasklist საერთო ჰოსტ პროცესით პასუხობს, წაიკითხეთ სერვისის სვეტი და ნუ გამოიცნობთ პროცესის სახელიდან.

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

IIS დრაივერს იზიარებს, Apache socket-ს ხსნის

IIS თავის bindings-ს გადასცემს იმავე ბირთვულ დრაივერს, რომელსაც SSTP იყენებს, და ეს დრაივერი შემომავალ კავშირებს ჰოსტის სახელისა და URL პრეფიქსის მიხედვით ანაწილებს, ასე რომ ორივე სერვისს შეიძლება 443-ის სურვილი ვუთხრათ და არც ერთი არ ჩავარდეს. Apache და nginx პირიქით იქცევიან: bind-ს საკუთარ socket-ზე იძახებენ, და ოპერაციული სისტემა უარყოფს, რადგან მისამართი უკვე დაკავებულია. არც ერთ კონფიგურაციაში არაფერია არასწორი; განსხვავება იმაშია, რომელი API ფლობს პორტს. ამიტომაც VPN-ის ჩართვა ერთ ჰოსტზე ერთ საიტს ამხობს და მეორე ჰოსტზე იდენტურ საიტს ხელუხლებლად ტოვებს.

ეს ასიმეტრია წყვეტს შეკეთების ფორმას. თუ IIS უკვე შესასვლელი კარია, შეჯახება პრეფიქსების, bindings-ისა და სერტიფიკატების საკითხი ხდება. თუ Apache არის შესასვლელი კარი, ან ის გადადის 443-დან, ან SSTP მსმენელი, და შემდეგი ნაწილი ორივე ნაბიჯს მოიცავს.

აირჩიეთ, რომელი სერვისი შეინარჩუნებს 443-ს

მსმენელის პორტი ერთ რეესტრის მნიშვნელობაში ცხოვრობს, ათობითი DWORD Sstpsvc პარამეტრების გასაღების ქვეშ. შეცვალეთ მნიშვნელობა, გადატვირთეთ Routing and Remote Access და მოსმენის ცხრილიდან დაადასტურეთ, რომ ძველი პორტი თავისუფალია.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

აირჩიეთ პორტი, რომელიც ჰოსტზე სხვას არ სჭირდება, და შეიტანეთ ის ათობითში: reg add ინახავს DWORD-ს ზუსტად ისე, როგორც დაწერილია, ამიტომ თექვსმეტობითად ნაფიქრი მნიშვნელობა სხვა პორტად ჯდება. თუ მოთხოვნა ამბობს, რომ მნიშვნელობა არ არსებობს, მეორე ხაზი ქმნის მას. Restart-Service RemoteAccess თიშავს ყველას, ვინც დაკავშირებულია, რაც დაგეგმვის ღირსია. შემდეგ ხელახლა გაუშვით მოსმენის შემოწმება, რადგან 443-ზე მოძველებული ჩანაწერი ნიშნავს, რომ სერვისმა თავისი ძველი რეგისტრაცია შეინარჩუნა.

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

მეორე ნაბიჯი 443-ს IIS-თან ინახავს და Apache-ს იმ backend-ად თვლის, სადაც პროქსი გადაამისამართებს. ის ინარჩუნებს SSTP-ის ნაგულისხმევს და პორტს ერთ მფლობელს უტოვებს, გადამისამართებული სათაურების, იმ კლიენტის მისამართის ფასად, რომელსაც აპლიკაცია აღარ ხედავს პირდაპირ, და backend-ის, რომელმაც უნდა ილაპარაკოს იმ პროტოკოლით, რომელსაც პროქსი რეალურად აგზავნის.

დაამტკიცეთ მფლობელი, სერტიფიკატი და handshake თანმიმდევრობით

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

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

პირველი ხაზი ასახელებს 443-ის მფლობელ PID-ს, და ეს უნდა იყოს ის სერვისი, რომელიც ახლახან გამართეთ. მეორე ჩამოთვლის მანქანის სერტიფიკატებს მათი subject-ებით, ამიტომ კლიენტის პროფილში მოცემულ მისამართს რომ არ ემთხვეოდეს სახელი, მაშინვე თვალში საცემია. მოვლენების მოთხოვნა აბრუნებს ბოლო SSTP ჩანაწერებს, და handshake, რომელიც არასოდეს აღწევს PPP ავთენტიფიკაციას, სხვა ჩანაწერს ტოვებს, ვიდრე ის, რომელიც ავთენტიფიცირდება და შემდეგ უარყოფილია. ბოლო ეტაპი მხოლოდ კლიენტზე ჩანს, სადაც ჩანაწერი ან დაკავშირებულს აცხადებს, ან PPP შეცდომას ასახელებს.

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