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

Apache prestane odgovarati na 443 onog poslijepodneva kada netko uključi dolazne VPN veze, a njegov dnevnik pogrešaka krivi bind umjesto rezervacije iza njega. Windows Routing and Remote Access u tom trenutku uključuje SSTP, a SSTP slušač zauzima TCP 443 kroz HTTP stog prije nego što se bilo koji klijent autentificira. Zahtjev ostaje na snazi čak i kada certifikat nedostaje, ime je pogrešno ili se svaki handshake odbija, pa VPN u koji nitko ne može ući i dalje drži port. Prvo pročitajte tablicu slušanja; PID koji drži 443 odlučuje koja je od ispravaka ispod uopće dostupna.

Rezervacija nadživi pokvaren certifikat

SSTP umotava PPP u TLS sesiju, zbog čega mu treba 443 i zbog čega prolazi kroz proxy poslužitelje koji odbacuju druge tunele. Slušač nije socket koji VPN usluga otvara za sebe: SstpSvc ga registrira kod jezgrinog HTTP upravljačkog programa, pa port ostaje rezerviran dokle god usluga radi. Ta registracija nikada ne konzultira certifikat, što znači da istekao naziv, neodgovarajući subject ili nikakav certifikat ostavljaju 443 zauzetim. Greške se zatim dijele u dva smjera: odbijeni handshakeovi završavaju u System dnevniku pod RasSstp, dok web poslužitelj može samo prijaviti da se nije mogao vezati.

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

Prva linija vraća PID koji drži port; druga imenuje uslugu iza njega, a odgovor je obično HTTP usluga ili RRAS stog. Kada tasklist odgovori kao zajednički host proces, čitajte stupac usluge umjesto da pogađate iz naziva procesa.

RasSstp upozorenja vrijedi čitati tek nakon 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 upravljački program, Apache otvara socket

IIS predaje svoje bindings istom jezgrinom upravljačkom programu koji koristi SSTP, a taj program razdvaja dolazne veze po nazivu hosta i URL prefiksu, pa se obje usluge mogu zamoliti da žele 443 bez da ijedna padne. Apache i nginx rade suprotno: pozivaju bind na vlastitom socketu, a operacijski sustav odbija jer je adresa već zauzeta. Ništa ni 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 popravka. Ako je IIS već ulazna vrata, sudar postaje pitanje prefiksa, bindings i certifikata. Ako je Apache ulazna vrata, ili se on pomiče s 443 ili to čini SSTP slušač, a sljedeće poglavlje pokriva oba poteza.

Odaberite koja usluga zadržava 443

Port slušača živi u jednoj registry vrijednosti, decimalnom DWORD-u pod ključem parametara Sstpsvc. Promijenite vrijednost, restartajte Routing and Remote Access i potvrdite iz tablice 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 nitko drugi na hostu ne želi i upišite ga decimalno: reg add čuva DWORD toč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 ju stvara. Restart-Service RemoteAccess odbija sve koji su povezani, što vrijedi zakazati. Nakon toga ponovno pokrenite provjeru slušanja, jer zastario unos na 443 znači da je usluga zadržala staru registraciju.

Premještanje slušača ima cijenu koju promjena registryja ne pokazuje. Obični SSTP klijenti biraju 443, pa svaki klijentski profil treba novi port, a tok prestaje nalikovati web zahtjevu za sve što pregledava putanju. Na mreži koja tolerira samo promet koji nalikuje HTTPS-u, 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 zadanu vrijednost i ostavlja jednog vlasnika porta, po cijeni proslijeđenih zaglavlja, adrese klijenta koju aplikacija više ne vidi izravno i backenda koji mora govoriti protokol koji proxy zaista šalje.

Dokažite vlasnika, certifikat i handshake po redu

Završena TCP veza dokazuje da slušač 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 popravak usmjeren 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 trebala biti usluga koju ste upravo konfigurirali. Druga navodi strojne certifikate s njihovim subjectima, pa ime koje se ne poklapa s adresom u klijentskom profilu odmah upada u oči. Upit događaja vraća nedavne SSTP zapise, a handshake koji nikad ne stigne do PPP autentifikacije ostavlja drugačiji zapis od onog koji se autentificira i zatim bude odbijen. Posljednja faza vidljiva je 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 ponovno otkriti ovaj sudar. Razdvajanje uloga ostaje čistiji odgovor: javni web poslužitelj i endpoint za daljinski pristup nose odvojene cikluse zakrpa, certifikata i restarta, a ti se ciklusi sreću po vlastitom rasporedu. U svakom slučaju, u predajnu bilješku ostavite provjeru slušanja, registry putanju i odabrani port.