SSTP obsadil port 443: prečo Apache nenastúpi

Apache prestane odpovedať na 443 v to popoludnie, keď niekto zapne prichádzajúce VPN pripojenia, a jeho chybový log obviňuje bind namiesto rezervácie, ktorá je za tým. Windows Routing and Remote Access v tej chvíli zapne SSTP a SSTP listener si nárokuje TCP 443 cez zásobník HTTP skôr, než sa autentifikuje ktorýkoľvek klient. Nárok platí aj vtedy, keď chýba certifikát, meno je nesprávne alebo je každý handshake odmietnutý, takže VPN, do ktorej sa nikto nedostane, napriek tomu port drží. Najprv si prečítajte tabuľku počúvania; PID, ktorý 443 vlastní, rozhoduje o tom, ktorá z nižšie uvedených opráv je pre vás vôbec otvorená.

Rezervácia prežije aj pokazený certifikát

SSTP zabalí PPP do TLS relácie, preto potrebuje 443 a preto prechádza cez proxy, ktoré zahadzujú iné tunely. Listener nie je socket, ktorý by si VPN služba otvárala sama: SstpSvc ho registruje u jadrového HTTP ovládača, takže port zostáva rezervovaný, kým služba beží. Tá registrácia nikdy nekonzultuje certifikát, čo znamená, že prepadnuté meno, nevyhovujúci subject alebo žiadny certifikát nechajú 443 obsadený. Zlyhania sa potom delia dvoma smermi: odmietnuté handshaky končia v System logu pod RasSstp, zatiaľ čo webový server môže len hlásiť, že sa nevedel pripojiť.

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

Prvý riadok vracia vlastniaci PID; druhý pomenúva službu za ním, a odpoveďou je zvyčajne služba HTTP alebo stoh RRAS. Keď tasklist odpovie zdieľaným hostiteľským procesom, čítajte stĺpec služby namiesto hádania z názvu procesu.

Varovania RasSstp stoja za prečítanie až potom, pretože opisujú neúspešný handshake a nehovoria nič o rezervácii, ktorá spôsobila kolíziu. Koncový bod VPN, ktorý odmieta každého klienta, port stále vlastní. Berte log ako druhú otázku, nie prvú.

IIS zdieľa ovládač, Apache otvára socket

IIS odovzdáva svoje bindings tomu istému jadrovému ovládaču, ktorý používa SSTP, a ten ovládač rozdeľuje prichádzajúce spojenia podľa názvu hostiteľa a prefixu URL, takže obom službám možno povedať, aby chceli 443, a ani jedna nezlyhá. Apache a nginx robia opak: volajú bind na vlastnom sockete a operačný systém odmietne, pretože adresa je už obsadená. V žiadnej z konfigurácií nie je nič zlé; rozdiel je v tom, ktoré API port vlastní. Preto zapnutie VPN zhodí jednu stránku na jednom hostiteľovi a identickú stránku na inom hostiteľovi nechá nedotknutú.

Táto asymetria určuje podobu opravy. Ak sú IIS už vstupnými dverami, kolízia sa stane otázkou prefixov, bindings a certifikátov. Ak sú vstupnými dverami Apache, buď sa posunú z 443, alebo to urobí SSTP listener, a nasledujúca časť pokrýva oba pohyby.

Vyberte, ktorá služba si 443 ponechá

Port listeneru žije v jedinej hodnote registra, desiatkovom DWORD pod kľúčom parametrov Sstpsvc. Zmeňte hodnotu, reštartujte Routing and Remote Access a z tabuľky počúvania potvrďte, že starý port je voľný.

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

Vyberte port, ktorý na hostiteľovi nikto iný nechce, a napíšte ho desiatkovo: reg add uloží DWORD presne tak, ako je napísaný, takže hodnota zamýšľaná ako hexadecimálna skončí ako iný port. Ak dopyt hovorí, že hodnota neexistuje, druhý riadok ju vytvorí. Restart-Service RemoteAccess odpojí všetkých pripojených, čo stojí za naplánovanie. Potom znova spustite kontrolu počúvania, pretože zastaraný záznam na 443 znamená, že služba si ponechala starú registráciu.

Presun listeneru má cenu, ktorú úprava registra neukazuje. Bežní klienti SSTP volajú 443, takže každý klientsky profil potrebuje nový port a tok prestane pripomínať webovú požiadavku pre čokoľvek, čo skúma cestu. V sieti, ktorá toleruje len prevádzku vyzerajúcu ako HTTPS, to odstráni väčšinu dôvodu, prečo bolo SSTP zvolené. Malá riadená klientska populácia to absorbuje; verejná alebo BYOD používateľská základňa nie.

Druhý pohyb ponechá 443 u IIS a Apache berie ako backend, na ktorý proxy presmerúva. Zachová predvolenú hodnotu SSTP a nechá portu jedného vlastníka, za cenu presmerovaných hlavičiek, adresy klienta, ktorú aplikácia už nevidí priamo, a backendu, ktorý musí hovoriť protokolom, ktorý proxy naozaj posiela.

Dokážte vlastníka, certifikát a handshake v poradí

Dokončené TCP spojenie dokazuje, že listener existuje, a nič viac, preto môže sken portov vyzerať zdravo, kým tunel stále zlyháva. Štyri fázy zlyhávajú rôznymi spôsobmi a oprava zameraná na fázu, ktorú ste nepokazili, zvyčajne kolíziu prehĺbi. Prejdite ich v poradí a zastavte sa tam, kde sa odpoveď rozchádza.

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

Prvý riadok pomenúva PID držiaci 443 a mal by to byť služba, ktorú ste práve nakonfigurovali. Druhý vymenúva certifikáty stroja s ich subject, takže meno, ktoré nezodpovedá adrese v klientskom profile, hneď vynikne. Dopyt na udalosti vracia nedávne záznamy SSTP a handshake, ktorý nikdy nedosiahne autentifikáciu PPP, zanechá iný záznam než ten, ktorý sa autentifikuje a potom je odmietnutý. Posledná fáza je viditeľná len na klientovi, kde záznam buď hlási pripojené, alebo pomenúva chybu PPP.

Keď musí jeden hostiteľ robiť obe práce, vyberte vlastníka 443 vedome a voľbu zapíšte, pretože inak ďalší človek, ktorý zapne nejakú funkciu, túto kolíziu znova objaví. Rozdelenie rolí zostáva čistejšou odpoveďou: verejný webový server a koncový bod vzdialeného prístupu nesú oddelené cykly záplat, certifikátov a reštartov a tie cykly sa stretávajú podľa vlastného rozvrhu. V každom prípade nechajte v odovzdávacej poznámke kontrolu počúvania, cestu v registri a zvolený port.