SSTP tok port 443: hvorfor Apache ikke starter

Apache slutter å svare på 443 den ettermiddagen noen aktiverer innkommende VPN-tilkoblinger, og feilloggen gir bind skylden i stedet for reservasjonen bak. Windows Routing and Remote Access slår på SSTP i det øyeblikket, og SSTP-lytteren gjør krav på TCP 443 gjennom HTTP-stakken før noen klient autentiseres. Kravet står selv når sertifikatet mangler, navnet er feil eller hver handshake avvises, så en VPN som ingen kommer inn i, okkuperer fortsatt porten. Les lyttetabellen først; PID-en som eier 443 avgjør hvilken av rettelsene nedenfor som i det hele tatt er åpen for deg.

Reservasjonen overlever et ødelagt sertifikat

SSTP pakker PPP inn i en TLS-økt, derfor trenger den 443 og derfor går den gjennom proxyer som dropper andre tunneler. Lytteren er ikke en socket VPN-tjenesten åpner for seg selv: SstpSvc registrerer den hos kjernens HTTP-driver, så porten forblir reservert så lenge tjenesten kjører. Den registreringen spør aldri sertifikatet, noe som betyr at et utløpt navn, et upassende subject eller ingen sertifikat i det hele tatt lar 443 stå okkupert. Feilene deler seg så i to retninger: avviste handshakes havner i System-loggen under RasSstp, mens webserveren bare kan melde at den ikke klarte å binde.

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

Den første linjen returnerer den eide PID-en; den andre navngir tjenesten bak den, og svaret er vanligvis HTTP-tjenesten eller RRAS-stakken. Når tasklist svarer med en delt vertsprosess, les tjenestekolonnen i stedet for å gjette ut fra prosessnavnet.

RasSstp-advarsler er bare verdt å lese etterpå, fordi de beskriver en handshake som mislyktes og ikke sier noe om reservasjonen som forårsaket kollisjonen. Et VPN-endepunkt som avviser hver klient eier fortsatt porten. Behandle loggen som det andre spørsmålet, ikke det første.

IIS deler driveren, Apache åpner en socket

IIS overlater bindings sine til den samme kjernedriveren som SSTP bruker, og den driveren skiller innkommende tilkoblinger etter vertsnavn og URL-prefiks, så begge tjenestene kan bes om å ville ha 443 uten at noen av dem feiler. Apache og nginx gjør det motsatte: de kaller bind på sin egen socket, og operativsystemet nekter fordi adressen allerede er tatt. Ingenting i noen av konfigurasjonene er galt; forskjellen ligger i hvilken API som eier porten. Det er også derfor aktivering av VPN-en velter ett nettsted på én vert og lar et identisk nettsted på en annen vert være urørt.

Denne asymmetrien bestemmer formen på reparasjonen. Hvis IIS allerede er fordøren, blir kollisjonen et spørsmål om prefikser, bindings og sertifikater. Hvis Apache er fordøren, flytter enten den vekk fra 443, eller SSTP-lytteren gjør det, og neste avsnitt dekker begge trekkene.

Velg hvilken tjeneste som beholder 443

Lytterporten bor i én enkelt registerverdi, en desimal DWORD under parameteren Sstpsvc. Endre verdien, start Routing and Remote Access på nytt, og bekreft fra lyttetabellen at den gamle porten 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

Velg en port som ingenting annet på verten vil ha, og skriv den inn i desimal: reg add lagrer DWORD-en nøyaktig slik den er skrevet, så en verdi som var ment som heksadesimal lander som en annen port. Hvis spørringen sier at verdien ikke finnes, oppretter den andre linjen den. Restart-Service RemoteAccess dropper alle som er tilkoblet, noe som er verdt å planlegge. Kjør lyttetesten på nytt etterpå, fordi en utdatert oppføring på 443 betyr at tjenesten beholdt den gamle registreringen sin.

Å flytte lytteren har en pris som registerendringen ikke viser. Vanlige SSTP-klienter ringer 443, så hver klientprofil trenger den nye porten, og flyten slutter å ligne en webforespørsel for alt som inspiserer banen. På et nettverk som bare tåler trafikk som ser ut som HTTPS, fjerner det det meste av grunnen til at SSTP ble valgt. En liten, styrt klientpopulasjon absorberer dette; en offentlig eller BYOD-brukerbase gjør det ikke.

Det andre trekket beholder 443 hos IIS og behandler Apache som en backend som proxyen videresender til. Det bevarer SSTP-standardverdien og lar det være én eier av porten, mot prisen av videresendte headere, en klientadresse applikasjonen ikke lenger ser direkte, og en backend som må snakke protokollen proxyen faktisk sender.

Bevis eieren, sertifikatet og handshaken i rekkefølge

En fullført TCP-tilkobling beviser at det finnes en lytter og ingenting annet, derfor kan en portskanning se sunn ut mens tunnelen fortsatt feiler. De fire trinnene feiler på ulike måter, og en reparasjon rettet mot trinnet du ikke brøt, gjør vanligvis kollisjonen dypere. Arbeid deg gjennom dem i rekkefølge og stopp der svaret deler seg.

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

Den første linjen navngir PID-en som holder 443, og det bør være tjenesten du nettopp konfigurerte. Den andre lister maskinsertifikater med subjectene sine, så et navn som ikke stemmer med adressen i klientprofilen stikker seg straks ut. Hendelsesspørringen returnerer ferske SSTP-poster, og en handshake som aldri når PPP-autentisering etterlater en annen post enn den som autentiseres og deretter avvises. Det siste trinnet er bare synlig på klienten, der oppføringen enten rapporterer tilkoblet eller navngir PPP-feilen.

Når én vert må gjøre begge jobbene, velg eieren av 443 med overlegg og skriv valget ned, fordi neste person som aktiverer en funksjon ellers gjenoppdager denne kollisjonen. Å dele rollene er fortsatt det renere svaret: en offentlig webserver og et endepunkt for ekstern tilgang har separate sykluser for oppdateringer, sertifikater og omstart, og de syklusene møtes etter sin egen plan. Uansett bør du la lyttetesten, registerbanen og den valgte porten stå i overleveringsnotatet.