SSTP je zauzeo port 443: zašto se Apache neće pokrenuti

Apache prestane odgovarati na 443 onog popodneva kada neko uključi dolazne VPN veze, a njegov dnevnik grešaka krivi bind umjesto rezervacije iza njega. Windows Routing and Remote Access u tom trenutku uključuje SSTP, a SSTP listener zauzima TCP 443 kroz HTTP stek prije nego što se bilo koji klijent autentifikuje. Zahtjev ostaje na snazi čak i kada sertifikat nedostaje, ime je pogrešno ili se svaki handshake odbija, pa VPN u koji niko ne može da se prijavi i dalje drži port. Prvo pročitajte tabelu slušanja; PID koji drži 443 odlučuje koje su vam od ispravki ispod uopšte dostupne.

Rezervacija nadživi pokvaren sertifikat

SSTP umotava PPP u TLS sesiju, zbog čega mu treba 443 i zbog čega prolazi kroz proxy servere koji odbacuju druge tunele. Listener nije socket koji VPN servis otvara za sebe: SstpSvc ga registruje kod kernel HTTP drajvera, pa port ostaje rezervisan sve dok servis radi. Ta registracija nikada ne konsultuje sertifikat, što znači da istekao naziv, neodgovarajući subject ili nikakav sertifikat ostavljaju 443 zauzetim. Greške se zatim dijele u dva smjera: odbijeni handshakeovi završavaju u System dnevniku pod RasSstp, dok web server može samo da prijavi da nije mogao da se veže.

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

Prva linija vraća PID koji drži port; druga imenuje servis iza njega, a odgovor je obično HTTP servis ili RRAS stek. Kada tasklist odgovori kao zajednički host proces, čitajte kolonu servisa umjesto da pogađate iz imena procesa.

RasSstp upozorenja vrijedi čitati tek poslije toga, jer opisuju handshake koji nije uspio i ne govore ništa o rezervaciji koja je izazvala sudar. VPN endpoint koji odbija svakog klijenta i dalje drži port. Tretirajte dnevnik kao drugo pitanje, a ne prvo.

IIS dijeli drajver, Apache otvara socket

IIS predaje svoje bindings istom kernel drajveru koji koristi SSTP, a taj drajver razdvaja dolazne veze po imenu hosta i URL prefiksu, pa se oba servisa mogu zamoliti da žele 443 bez da ijedan od njih padne. Apache i nginx rade suprotno: pozivaju bind na vlastiti socket, a operativni sistem odbija jer je adresa već zauzeta. Ništa u jednoj ni u drugoj konfiguraciji nije pogrešno; razlika je u tome koji API drži port. To je i razlog zašto uključivanje VPN-a obori jednu stranicu na jednom hostu, a identičnu stranicu na drugom hostu ostavi netaknutom.

Ta asimetrija odlučuje oblik popravke. Ako je IIS već ulazna vrata, sudar postaje pitanje prefiksa, bindings i sertifikata. Ako je Apache ulazna vrata, ili se on pomjera sa 443 ili to čini SSTP listener, a sljedeće poglavlje pokriva oba poteza.

Odaberite koji servis zadržava 443

Port listenera živi u jednoj registry vrijednosti, decimalnom DWORD-u pod ključem parametara Sstpsvc. Promijenite vrijednost, restartujte Routing and Remote Access i potvrdite iz tabele slušanja da je stari port slobodan.

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

Odaberite port koji niko drugi na hostu ne želi i upišite ga decimalno: reg add čuva DWORD tačno onako kako je napisan, pa vrijednost zamišljena kao heksadecimalna završi kao drugi port. Ako upit kaže da vrijednost ne postoji, druga linija je kreira. Restart-Service RemoteAccess odbacuje sve koji su povezani, što vrijedi zakazati. Poslije toga ponovo pokrenite provjeru slušanja, jer zastario unos na 443 znači da je servis zadržao staru registraciju.

Premještanje listenera ima cijenu koju izmjena registryja ne pokazuje. Obični SSTP klijenti biraju 443, pa svaki klijentski profil treba novi port, a tok prestaje ličiti na web zahtjev za sve što pregleda putanju. Na mreži koja toleriše samo saobraćaj koji liči na HTTPS, to uklanja većinu razloga zašto je SSTP odabran. Mala, vođena klijentska populacija to podnosi; javna ili BYOD korisnička baza ne.

Drugi potez zadržava 443 kod IIS-a i tretira Apache kao backend na koji proxy prosljeđuje. To čuva SSTP zadano i ostavlja jednog vlasnika porta, po cijeni proslijeđenih headera, adrese klijenta koju aplikacija više ne vidi direktno i backenda koji mora govoriti protokol koji proxy zaista šalje.

Dokažite vlasnika, sertifikat i handshake po redu

Završena TCP veza dokazuje da listener postoji i ništa više, zbog čega port sken može izgledati zdravo dok tunel i dalje ne radi. Četiri faze padaju na različite načine, a popravka usmjerena na fazu koju niste pokvarili obično produbljuje sudar. Obradite ih po redu i zaustavite se tamo gdje se odgovor razilazi.

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

Prva linija imenuje PID koji drži 443, a to bi trebao biti servis koji ste upravo konfigurisali. Druga navodi mašinske sertifikate sa njihovim subjectima, pa ime koje se ne poklapa sa adresom u klijentskom profilu odmah upada u oči. Upit događaja vraća nedavne SSTP zapise, a handshake koji nikada ne stigne do PPP autentifikacije ostavlja drugačiji zapis od onog koji se autentifikuje i zatim bude odbijen. Posljednja faza je vidljiva samo na klijentu, gdje unos ili prijavljuje povezano ili imenuje PPP grešku.

Kada jedan host mora obavljati oba posla, svjesno odaberite vlasnika 443 i zapišite odluku, jer će sljedeća osoba koja uključi neku funkciju inače ponovo otkriti ovaj sudar. Razdvajanje uloga ostaje čistiji odgovor: javni web server i endpoint za daljinski pristup nose odvojene cikluse zakrpa, sertifikata i restarta, a ti ciklusi se sreću po svom rasporedu. U svakom slučaju, u predajnu bilješku ostavite provjeru slušanja, registry putanju i odabrani port.