SSTP tog port 443: hvorfor Apache ikke starter

Apache holder op med at svare på 443 den eftermiddag, nogen aktiverer indgående VPN-forbindelser, og fejlloggen giver bind skylden i stedet for reservationen bag det. Windows Routing and Remote Access slår SSTP til i det øjeblik, og SSTP-lytteren gør krav på TCP 443 gennem HTTP-stakken, før nogen klient godkendes. Kravet holder, selv når certifikatet mangler, navnet er forkert, eller hver handshake afvises, så en VPN, som ingen kan logge ind på, stadig optager porten. Læs lytte-tabellen først; den PID, der ejer 443, afgør, hvilken af rettelserne nedenfor der overhovedet er åben for dig.

Reservationen overlever et ødelagt certifikat

SSTP pakker PPP ind i en TLS-session, og derfor har den brug for 443, og derfor rejser den gennem proxyer, der dropper andre tunneller. Lytteren er ikke en socket, VPN-tjenesten åbner for sig selv: SstpSvc registrerer den hos kernens HTTP-driver, så porten forbliver reserveret, så længe tjenesten kører. Den registrering konsulterer aldrig certifikatet, hvilket betyder, at et udløbet navn, et uoverensstemmende subject eller slet intet certifikat efterlader 443 optaget. Fejl deler sig derefter i to retninger: afviste handshakes lander i System-loggen under RasSstp, mens webserveren kun kan rapportere, at den ikke kunne binde.

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

Den første linje returnerer den ejende PID; den anden navngiver tjenesten bag den, og svaret er normalt HTTP-tjenesten eller RRAS-stakken. Når tasklist svarer med en delt værtproces, skal du læse tjenestekolonnen i stedet for at gætte ud fra procesnavnet.

RasSstp-advarsler er først værd at læse derefter, fordi de beskriver en handshake, der mislykkedes, og intet siger om den reservation, der forårsagede sammenstødet. Et VPN-endepunkt, der afviser hver klient, ejer stadig porten. Behandl loggen som det andet spørgsmål, ikke det første.

IIS deler driveren, Apache åbner en socket

IIS overdrager sine bindings til den samme kernedriver, som SSTP bruger, og den driver fordeler indgående forbindelser efter værtsnavn og URL-præfiks, så begge tjenester kan få besked om at ville have 443, uden at nogen af dem fejler. Apache og nginx gør det modsatte: de kalder bind på deres egen socket, og operativsystemet afviser, fordi adressen allerede er optaget. Intet i nogen af konfigurationerne er forkert; forskellen ligger i, hvilken API der ejer porten. Det er også derfor, at aktivering af VPN’en vælter et websted på én vært og lader et identisk websted på en anden vært være urørt.

Denne asymmetri bestemmer reparationens form. Hvis IIS allerede er fordøren, bliver sammenstødet et spørgsmål om præfikser, bindings og certifikater. Hvis Apache er fordøren, flytter enten den væk fra 443, eller SSTP-lytteren gør, og næste afsnit dækker begge flytninger.

Vælg, hvilken tjeneste der beholder 443

Lytterporten bor i en enkelt registreringsværdi, en decimal DWORD under Sstpsvc-parameternøglen. Skift værdien, genstart Routing and Remote Access, og bekræft ud fra lytte-tabellen, at den gamle port er fri.

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ælg en port, som intet andet på værten vil have, og skriv den i decimal: reg add gemmer DWORD’en nøjagtigt som skrevet, så en værdi, der var ment som hexadecimal, lander som en anden port. Hvis forespørgslen siger, at værdien ikke findes, opretter den anden linje den. Restart-Service RemoteAccess dropper alle, der er forbundet, hvilket er værd at planlægge. Kør lytte-tjekket igen bagefter, fordi en forældet post på 443 betyder, at tjenesten beholdt sin gamle registrering.

At flytte lytteren har en pris, som registreringsændringen ikke viser. Almindelige SSTP-klienter ringer til 443, så hver klientprofil skal have den nye port, og flowet holder op med at ligne en webforespørgsel for noget, der inspicerer stien. På et netværk, der kun tolererer trafik, der ligner HTTPS, fjerner det det meste af grunden til, at SSTP blev valgt. En lille, styret klientpopulation absorberer dette; en offentlig eller BYOD-brugerbase gør ikke.

Den anden flytning beholder 443 hos IIS og behandler Apache som en backend, som proxyen videresender til. Det bevarer SSTP-standarden og efterlader én ejer af porten, på bekostning af videresendte headere, en klientadresse, som applikationen ikke længere ser direkte, og en backend, der skal tale den protokol, proxyen faktisk sender.

Bevis ejeren, certifikatet og handshaken i rækkefølge

En fuldført TCP-forbindelse beviser, at der findes en lytter, og intet andet, hvorfor en portscan kan se sund ud, mens tunnellen stadig fejler. De fire faser fejler på forskellige måder, og en reparation rettet mod den fase, du ikke brød, gør normalt sammenstødet dybere. Arbejd dem igennem i rækkefølge, og stop, hvor svaret divergerer.

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

Den første linje navngiver den PID, der holder 443, og det bør være den tjeneste, du netop har konfigureret. Den anden viser maskincertifikater med deres subjects, så et navn, der ikke matcher adressen i klientprofilen, springer straks i øjnene. Hændelsesforespørgslen returnerer nyere SSTP-poster, og en handshake, der aldrig når PPP-godkendelse, efterlader en anden post end en, der godkendes og derefter afvises. Den sidste fase er kun synlig på klienten, hvor posten enten rapporterer forbundet eller navngiver PPP-fejlen.

Når én vært skal klare begge job, skal du bevidst vælge ejeren af 443 og skrive valget ned, fordi den næste person, der aktiverer en funktion, ellers genopdager dette sammenstød. At dele rollerne op er fortsat det renere svar: en offentlig webserver og et fjernadgangsendepunkt har separate cyklusser for patches, certifikater og genstarter, og de cyklusser mødes efter deres egen tidsplan. Under alle omstændigheder skal du efterlade lytte-tjekket, registreringsstien og den valgte port i overdragelsesnoten.