SSTP obsadil port 443: proč Apache nenastartuje

Apache přestane odpovídat na 443 ono odpoledne, kdy někdo zapne příchozí VPN připojení, a jeho chybový log viní bind místo rezervace, která za ním stojí. Windows Routing and Remote Access v tu chvíli zapne SSTP a SSTP listener si nárokuje TCP 443 přes HTTP zásobník dříve, než se jakýkoli klient autentizuje. Nárok platí i tehdy, když chybí certifikát, jméno je špatné nebo je každý handshake odmítnut, takže VPN, do které se nikdo nepřihlásí, přesto port drží. Přečtěte si nejdřív tabulku naslouchání; PID, který 443 vlastní, rozhoduje o tom, která z níže uvedených oprav je pro vás vůbec otevřená.

Rezervace přežije i rozbitý certifikát

SSTP zabalí PPP do TLS relace, proto potřebuje 443 a proto prochází proxy, které jiné tunely zahazují. Listener není socket, který by si VPN služba otevírala sama: SstpSvc ho registruje u jaderného HTTP ovladače, takže port zůstává rezervovaný, dokud služba běží. Ta registrace certifikát nikdy nekonzultuje, což znamená, že prošlé jméno, neodpovídající subject nebo žádný certifikát nechají 443 obsazený. Selhání se pak dělí dvěma směry: odmítnuté handshaky končí v System logu pod RasSstp, zatímco webový server může jen hlásit, že se nemohl navázat.

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

První řádek vrací vlastnící PID; druhý pojmenovává službu za ním, a odpovědí je obvykle HTTP služba nebo stoh RRAS. Když tasklist odpoví sdíleným hostitelským procesem, čtěte sloupec služby, místo abyste hádali z názvu procesu.

Varování RasSstp stojí za přečtení až potom, protože popisují handshake, který selhal, a neříkají nic o rezervaci, jež srážku způsobila. VPN endpoint, který odmítá každého klienta, port stále vlastní. Berte log jako druhou otázku, ne první.

IIS sdílí ovladač, Apache otevírá socket

IIS předává svá bindings stejnému jadernému ovladači, který používá SSTP, a ten ovladač rozděluje příchozí spojení podle jména hostitele a prefixu URL, takže oběma službám lze říct, aby chtěly 443, aniž by jedna selhala. Apache a nginx dělají opak: volají bind na svém vlastním socketu a operační systém to odmítne, protože adresa je už obsazená. V žádné z těch konfigurací není nic špatně; rozdíl je v tom, které API port vlastní. To je také důvod, proč zapnutí VPN srazí jeden web na jednom hostiteli a identický web na jiném hostiteli nechá nedotčený.

Tato asymetrie určuje podobu opravy. Pokud jsou IIS už vstupními dveřmi, stává se srážka otázkou prefixů, bindings a certifikátů. Pokud jsou vstupními dveřmi Apache, buď se posunou z 443, nebo to udělá SSTP listener, a následující část pokrývá oba pohyby.

Vyberte, která služba si 443 ponechá

Port listeneru žije v jediné hodnotě registru, desítkovém DWORDu pod klíčem parametrů Sstpsvc. Změňte hodnotu, restartujte Routing and Remote Access a z tabulky naslouchání potvrďte, že starý port je volný.

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, který na hostiteli nikdo jiný nechce, a napište ho desítkově: reg add uloží DWORD přesně tak, jak je napsaný, takže hodnota zamýšlená jako hexadecimální skončí jako jiný port. Pokud dotaz říká, že hodnota neexistuje, druhý řádek ji vytvoří. Restart-Service RemoteAccess odpojí všechny, kdo jsou připojení, což stojí za naplánování. Potom znovu spusťte kontrolu naslouchání, protože zastaralý záznam na 443 znamená, že služba si ponechala starou registraci.

Přesun listeneru má cenu, kterou úprava registru neukazuje. Běžní SSTP klienti volají 443, takže každý klientský profil potřebuje nový port a tok přestane připomínat webový požadavek pro cokoli, co zkoumá cestu. V síti, která toleruje jen provoz vypadající jako HTTPS, to odstraní většinu důvodu, proč bylo SSTP zvoleno. Malá řízená klientská populace to absorbuje; veřejná nebo BYOD uživatelská základna ne.

Druhý pohyb ponechá 443 u IIS a Apache bere jako backend, na který proxy přeposílá. Zachová výchozí hodnotu SSTP a nechá portu jednoho vlastníka, za cenu přeposílaných hlaviček, adresy klienta, kterou aplikace už nevidí přímo, a backendu, který musí mluvit protokolem, jenž proxy skutečně posílá.

Dokažte vlastníka, certifikát a handshake v tomto pořadí

Dokončené TCP spojení dokazuje, že listener existuje, a nic víc, proto může sken portů vypadat zdravě, zatímco tunel stále selhává. Čtyři fáze selhávají různě a oprava zaměřená na fázi, kterou jste nerozbili, obvykle srážku prohloubí. Projděte je popořadě a zastavte se tam, kde se odpověď rozchází.

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

První řádek pojmenovává PID držící 443 a měla by to být služba, kterou jste právě nastavili. Druhý vypisuje strojové certifikáty s jejich subjekty, takže jméno, které neodpovídá adrese v klientském profilu, okamžitě vystoupí. Dotaz na události vrací nedávné SSTP záznamy a handshake, který nikdy nedojde k PPP autentizaci, zanechá jiný záznam než ten, který se autentizuje a pak je odmítnut. Poslední fáze je vidět jen na klientu, kde záznam buď hlásí připojeno, nebo pojmenovává chybu PPP.

Když musí jeden hostitel dělat obě práce, vyberte vlastníka 443 vědomě a volbu zapište, protože další člověk, který zapne nějakou funkci, jinak tuto srážku znovu objeví. Rozdělení rolí zůstává čistější odpovědí: veřejný webový server a endpoint pro vzdálený přístup nesou oddělené cykly záplat, certifikátů a restartů a ty cykly se potkávají podle vlastního rozvrhu. Ať tak či tak, nechte v předávacím záznamu kontrolu naslouchání, cestu v registru a zvolený port.