SSTP zajął port 443: dlaczego Apache nie startuje

Apache przestaje odpowiadać na 443 tego popołudnia, w którym ktoś włącza przychodzące połączenia VPN, a jego dziennik błędów obwinia bind, a nie rezerwację, która za nim stoi. Windows Routing and Remote Access włącza wtedy SSTP, a nasłuchiwacz SSTP zajmuje TCP 443 przez stos HTTP, zanim uwierzytelni się jakikolwiek klient. Roszczenie obowiązuje nawet wtedy, gdy brakuje certyfikatu, nazwa jest błędna lub każde uzgadnianie zostaje odrzucone, więc VPN, do którego nikt nie może wejść, nadal zajmuje port. Najpierw przeczytaj tabelę nasłuchu; PID, który posiada 443, decyduje, która z poniższych poprawek jest dla ciebie w ogóle otwarta.

Rezerwacja przeżywa zepsuty certyfikat

SSTP opakowuje PPP w sesję TLS, dlatego potrzebuje 443 i dlatego przechodzi przez proxy, które odrzucają inne tunele. Nasłuchiwacz nie jest gniazdem, które usługa VPN otwiera dla siebie: SstpSvc rejestruje go w sterowniku HTTP jądra, więc port pozostaje zarezerwowany, dopóki usługa działa. Ta rejestracja nigdy nie konsultuje certyfikatu, co oznacza, że wygasła nazwa, niedopasowany subject lub brak certyfikatu pozostawiają 443 zajęty. Błędy dzielą się wtedy w dwóch kierunkach: odrzucone uzgodnienia trafiają do dziennika System pod RasSstp, a serwer WWW może tylko zgłosić, że nie zdołał się związać.

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

Pierwszy wiersz zwraca PID właściciela; drugi nazywa usługę za nim, a odpowiedzią jest zwykle usługa HTTP albo stos RRAS. Gdy tasklist odpowiada wspólnym procesem hosta, czytaj kolumnę usługi zamiast zgadywać z nazwy procesu.

Ostrzeżenia RasSstp warto czytać dopiero potem, bo opisują nieudane uzgadnianie i nie mówią nic o rezerwacji, która wywołała kolizję. Punkt końcowy VPN, który odrzuca każdego klienta, nadal posiada port. Traktuj dziennik jako drugie pytanie, a nie pierwsze.

IIS dzieli sterownik, Apache otwiera gniazdo

IIS przekazuje swoje bindings temu samemu sterownikowi jądra, którego używa SSTP, a ten sterownik rozdziela połączenia przychodzące według nazwy hosta i prefiksu URL, więc obu usługom można kazać chcieć 443, bez tego by którakolwiek zawiodła. Apache i nginx robią odwrotnie: wywołują bind na własnym gnieździe, a system operacyjny odmawia, bo adres jest już zajęty. W żadnej z konfiguracji nie ma nic złego; różnica tkwi w tym, które API posiada port. To także dlatego włączenie VPN przewraca jedną witrynę na jednym hoście, a identyczną witrynę na innym hoście zostawia nietkniętą.

Ta asymetria decyduje o kształcie naprawy. Jeśli IIS jest już frontowymi drzwiami, kolizja staje się kwestią prefiksów, bindings i certyfikatów. Jeśli frontowymi drzwiami jest Apache, albo on schodzi z 443, albo robi to nasłuchiwacz SSTP, a następna sekcja omawia oba ruchy.

Wybierz, która usługa zatrzyma 443

Port nasłuchiwacza mieszka w jednej wartości rejestru, dziesiętnym DWORD pod kluczem parametrów Sstpsvc. Zmień wartość, uruchom ponownie Routing and Remote Access i potwierdź z tabeli nasłuchu, że stary port jest wolny.

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

Wybierz port, którego nic innego na hoście nie chce, i wpisz go dziesiętnie: reg add zapisuje DWORD dokładnie tak, jak został wpisany, więc wartość pomyślana jako szesnastkowa trafia jako inny port. Jeśli zapytanie mówi, że wartość nie istnieje, drugi wiersz ją tworzy. Restart-Service RemoteAccess wyrzuca wszystkich połączonych, co warto zaplanować. Uruchom potem ponownie kontrolę nasłuchu, bo nieaktualny wpis na 443 oznacza, że usługa zachowała starą rejestrację.

Przeniesienie nasłuchiwacza ma cenę, której zmiana rejestru nie pokazuje. Zwykli klienci SSTP wybierają 443, więc każdy profil klienta potrzebuje nowego portu, a przepływ przestaje przypominać żądanie sieciowe dla wszystkiego, co bada ścieżkę. W sieci, która toleruje tylko ruch wyglądający jak HTTPS, usuwa to większość powodu, dla którego wybrano SSTP. Mała, zarządzana populacja klientów to pochłania; publiczna lub BYOD baza użytkowników nie.

Drugi ruch zatrzymuje 443 przy IIS i traktuje Apache jako backend, do którego proxy przekazuje żądania. Zachowuje domyślne ustawienie SSTP i zostawia jednego właściciela portu, kosztem przekazywanych nagłówków, adresu klienta, którego aplikacja już bezpośrednio nie widzi, oraz backendu, który musi mówić protokołem faktycznie wysyłanym przez proxy.

Udowodnij właściciela, certyfikat i uzgadnianie po kolei

Ukończone połączenie TCP dowodzi, że istnieje nasłuchiwacz, i niczego więcej, dlatego skan portów może wyglądać zdrowo, gdy tunel wciąż zawodzi. Cztery etapy zawodzą na różne sposoby, a naprawa wymierzona w etap, którego nie zepsułeś, zwykle pogłębia kolizję. Przejdź je po kolei i zatrzymaj się tam, gdzie odpowiedź się rozjeżdża.

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

Pierwszy wiersz nazywa PID trzymający 443, i powinna to być usługa, którą właśnie skonfigurowałeś. Drugi wymienia certyfikaty maszyny wraz z ich subject, więc nazwa niezgodna z adresem w profilu klienta rzuca się w oczy od razu. Zapytanie o zdarzenia zwraca świeże rekordy SSTP, a uzgadnianie, które nigdy nie dociera do uwierzytelniania PPP, zostawia inny rekord niż to, które się uwierzytelnia, a potem zostaje odrzucone. Ostatni etap widać tylko na kliencie, gdzie wpis zgłasza połączenie albo nazywa błąd PPP.

Gdy jeden host musi wykonywać obie prace, wybierz właściciela 443 świadomie i zapisz ten wybór, bo inaczej następna osoba, która włączy jakąś funkcję, odkryje tę kolizję na nowo. Rozdzielenie ról pozostaje czystszą odpowiedzią: publiczny serwer WWW i punkt końcowy dostępu zdalnego mają osobne cykle poprawek, certyfikatów i restartów, a te cykle spotykają się według własnego harmonogramu. W każdym razie zostaw kontrolę nasłuchu, ścieżkę rejestru i wybrany port w notatce przekazania.