Az SSTP elvitte a 443-as portot: miért nem indul az Apache

Az Apache azon a délutánon hagy fel a 443-on adott válasszal, amikor valaki engedélyezi a bejövő VPN-kapcsolatokat, és a hibalóg a bindra fogja a hibát, nem a mögötte lévő foglalásra. A Windows Routing and Remote Access ebben a pillanatban kapcsolja be SSTP-t, és az SSTP-figyelő az HTTP-verem révén igényli a TCP 443-at, mielőtt bármely ügyfél hitelesítést kapna. Az igénylés akkor is érvényben marad, ha hiányzik a tanúsítvány, rossz a név, vagy minden handshake elutasításra kerül, így egy VPN, amelybe senki nem tud bejelentkezni, mégis a porton marad. Először a figyelési táblát olvassa el; a 443-at birtokló PID dönti el, melyik alábbi javítás egyáltalán nyitva áll Ön előtt.

A foglalás túléli a törött tanúsítványt

Az SSTP PPP-t csomagol TLS-munkamenetbe, ezért kell neki a 443, és ezért halad át olyan proxykon, amelyek más alagutakat eldobnak. A figyelő nem olyan socket, amelyet a VPN-szolgáltatás magának nyit: az SstpSvc a kernel HTTP-illesztőprogramjánál regisztrálja, így a port mindaddig foglalt marad, amíg a szolgáltatás fut. Ez a regisztráció soha nem kérdezi a tanúsítványt, ami azt jelenti, hogy a lejárt név, a nem megfelelő subject vagy a teljesen hiányzó tanúsítvány is foglaltan hagyja a 443-at. A hibák aztán két irányba válnak szét: az elutasított handshake-ek a System naplóba kerülnek a RasSstp alatt, míg a webszerver csak azt jelentheti, hogy nem tudott bindolni.

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

Az első sor a birtokló PID-et adja vissza; a második a mögötte lévő szolgáltatást nevezi meg, és a válasz általában a HTTP-szolgáltatás vagy az RRAS-verem. Amikor tasklist megosztott gazdafolyamattal válaszol, a szolgáltatásoszlopot olvassa, ne a folyamat nevéből találgasson.

A RasSstp-figyelmeztetések csak ezután érdemesek olvasásra, mert egy meghiúsult handshake-et írnak le, és semmit sem mondanak az ütközést okozó foglalásról. Egy VPN-végpont, amely minden ügyfelet elutasít, még mindig birtokolja a portot. Kezelje a naplót a második kérdésként, nem az elsőként.

Az IIS megosztja az illesztőprogramot, az Apache socketet nyit

Az IIS ugyanannak a kernel-illesztőprogramnak adja át a bindings-eit, amelyet az SSTP használ, és az az illesztőprogram a bejövő kapcsolatokat gazdanév és URL-előtag szerint választja szét, így mindkét szolgáltatást meg lehet kérni, hogy akarja a 443-at, anélkül hogy bármelyik elbukna. Az Apache és az nginx ennek ellenkezőjét teszi: a saját socketjükön hívják a bindot, és az operációs rendszer megtagadja, mert a cím már foglalt. Egyik konfigurációban sincs semmi hiba; a különbség abban rejlik, melyik API birtokolja a portot. Ezért is dönti le a VPN engedélyezése az egyik gazdagépen az egyik oldalt, és hagyja érintetlenül a másik gazdagépen a vele azonos oldalt.

Ez az aszimmetria határozza meg a javítás formáját. Ha az IIS már az előajtó, az ütközés előtagok, bindings-ek és tanúsítványok kérdésévé válik. Ha az Apache az előajtó, vagy az mozdul el a 443-ról, vagy az SSTP-figyelő, és a következő szakasz mindkét lépést lefedi.

Válassza ki, melyik szolgáltatás tartsa a 443-at

A figyelő portja egyetlen beállításjegyzék-értékben él, egy decimális DWORD-ban az Sstpsvc paraméterkulcsa alatt. Módosítsa az értéket, indítsa újra a Routing and Remote Access-t, és a figyelési táblából erősítse meg, hogy a régi port szabad.

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

Válasszon olyan portot, amelyet semmi más nem akar a gazdagépen, és írja be decimálisan: reg add pontosan úgy tárolja a DWORD-ot, ahogy beírták, ezért a hexadecimálisként szánt érték másik portként landol. Ha a lekérdezés azt mondja, hogy az érték nem létezik, a második sor létrehozza. Restart-Service RemoteAccess mindenkit eldob, aki kapcsolódva van, amit érdemes megtervezni. Utána futtassa újra a figyelési ellenőrzést, mert a 443-on maradt elavult bejegyzés azt jelenti, hogy a szolgáltatás megtartotta a régi regisztrációját.

A figyelő áthelyezésének ára van, amelyet a beállításjegyzék módosítása nem mutat meg. A közönséges SSTP-ügyfelek a 443-at tárcsázzák, ezért minden ügyfélprofilnak kell az új port, és a folyamat megszűnik webkérésnek látszani minden olyan számára, ami az útvonalat vizsgálja. Olyan hálózaton, amely csak a HTTPS-re hasonlító forgalmat tűri, ez eltávolítja az SSTP választásának legtöbb okát. Egy kis, kezelt ügyfélpopuláció elviseli ezt; egy nyilvános vagy BYOD-felhasználói bázis nem.

A másik lépés az IIS-nél tartja a 443-at, és az Apache-ot olyan backendként kezeli, ahová a proxy továbbít. Megőrzi az SSTP alapértelmezését, és egy tulajdonost hagy a portnak, a továbbított fejlécek, az alkalmazás által már közvetlenül nem látott ügyfélcím és az olyan backend árán, amelynek azt a protokollt kell beszélnie, amelyet a proxy valóban küld.

Bizonyítsa a tulajdonost, a tanúsítványt és a handshake-et sorrendben

Egy befejezett TCP-kapcsolat azt bizonyítja, hogy létezik figyelő, és semmi mást, ezért tűnhet egészségesnek egy portszkennelés, miközben az alagút még mindig elbukik. A négy szakasz különböző módon bukik el, és a nem törött szakaszra irányuló javítás általában elmélyíti az ütközést. Dolgozza végig őket sorrendben, és álljon meg ott, ahol a válasz szétválik.

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

Az első sor megnevezi a 443-at tartó PID-et, és ennek az imént beállított szolgáltatásnak kell lennie. A második a gépi tanúsítványokat listázza a subjectjeikkel, így az ügyfélprofilban szereplő címmel nem egyező név azonnal szembetűnik. Az eseménylekérdezés a közelmúlt SSTP-rekordjait adja vissza, és az a handshake, amely soha nem éri el a PPP-hitelesítést, más rekordot hagy maga után, mint amelyik hitelesítődik, majd elutasítják. Az utolsó szakasz csak az ügyfélen látható, ahol a bejegyzés vagy kapcsolódott állapotot jelent, vagy megnevezi a PPP-hibát.

Amikor egy gazdagépnek mindkét feladatot el kell látnia, tudatosan válassza ki a 443 tulajdonosát, és írja le a döntést, mert különben a következő ember, aki engedélyez egy funkciót, újra felfedezi ezt az ütközést. A szerepek szétválasztása marad a tisztább válasz: egy nyilvános webszerver és egy távoli hozzáférési végpont külön javítási, tanúsítvány- és újraindítási ciklust hordoz, és ezek a ciklusok a saját ütemtervük szerint találkoznak. Mindenképp hagyja ott az átadási jegyzetben a figyelési ellenőrzést, a beállításjegyzék útvonalát és a választott portot.