SSTP tok port 443: kvifor Apache ikkje startar

Apache sluttar å svare på 443 den ettermiddagen nokon slår på innkomande VPN-tilkoplingar, og feilloggen gir bind skulda i staden for reservasjonen bak. Windows Routing and Remote Access slår på SSTP i det augneblunket, og SSTP-lyttaren gjer krav på TCP 443 gjennom HTTP-stakken før nokon klient blir autentisert. Kravet står sjølv når sertifikatet manglar, namnet er feil eller kvar handshake blir avvist, så ein VPN som ingen kjem inn i, okkuperer framleis porten. Les lyttetabellen først; PID-en som eig 443 avgjer kva av rettingane nedanfor som i det heile er open for deg.

Reservasjonen overlever eit øydelagt sertifikat

SSTP pakkar PPP inn i ein TLS-økt, difor treng han 443 og difor går han gjennom proxyar som droppar andre tunnelar. Lyttaren er ikkje ein socket som VPN-tenesta opnar for seg sjølv: SstpSvc registrerer han hos HTTP-drivaren i kjernen, så porten blir verande reservert så lenge tenesta køyrer. Den registreringa spør aldri sertifikatet, noko som tyder på at eit utløpt namn, eit upassande subject eller ingen sertifikat i det heile lèt 443 stå okkupert. Feila deler seg så i to retningar: avviste handshakes hamnar i System-loggen under RasSstp, medan webserveren berre kan melde at han ikkje klarte å binde.

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

Den første lina returnerer den eigande PID-en; den andre nemner tenesta bak han, og svaret er vanlegvis HTTP-tenesta eller RRAS-stakken. Når tasklist svarar med ein delt vertsprosess, les tenestekolonnen i staden for å gjette ut frå prosessnamnet.

RasSstp-åtvaringar er berre verdt å lese etterpå, fordi dei skildrar ein handshake som mislukkast og seier ingenting om reservasjonen som årsaka kollisjonen. Eit VPN-endepunkt som avviser kvar klient eig framleis porten. Handsame loggen som det andre spørsmålet, ikkje det første.

IIS deler drivaren, Apache opnar ein socket

IIS overlèt bindings sine til den same kjernedrivaren som SSTP brukar, og den drivaren skil innkomande tilkoplingar etter vertsnamn og URL-prefiks, så begge tenestene kan bli bedne om å vilje ha 443 utan at nokon av dei feilar. Apache og nginx gjer det motsette: dei kallar bind på sin eigen socket, og operativsystemet nektar fordi adressa alt er teken. Ingenting i nokon av konfigurasjonane er gale; skilnaden ligg i kva API som eig porten. Det er òg difor aktivering av VPN-en velter ein nettstad på éin vert og lèt ein identisk nettstad på ein annan vert vere urørt.

Denne asymmetrien avgjer forma på reparasjonen. Viss IIS alt er framdøra, blir kollisjonen eit spørsmål om prefiks, bindings og sertifikat. Viss Apache er framdøra, flyttar anten han vekk frå 443, eller SSTP-lyttaren gjer det, og neste avsnitt dekkjer begge trekka.

Vel kva teneste som held 443

Lyttarporten bur i éin enkelt registerverdi, ein desimal DWORD under parameteren Sstpsvc. Endre verdien, start Routing and Remote Access på nytt, og stadfest frå 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

Vel ein port som ingenting anna på verten vil ha, og skriv han inn i desimal: reg add lagrar DWORD-en nøyaktig slik han er skriven, så ein verdi som var meint som heksadesimal landar som ein annan port. Viss spørjinga seier at verdien ikkje finst, lagar den andre lina han. Restart-Service RemoteAccess droppar alle som er tilkopla, noko som er verdt å planleggje. Køyr lyttetesten på nytt etterpå, fordi ei utdatert oppføring på 443 tyder på at tenesta heldt på den gamle registreringa si.

Å flytte lyttaren har ein pris som registerendringa ikkje viser. Vanlege SSTP-klientar ringer 443, så kvar klientprofil treng den nye porten, og flyten sluttar å likne ein webførespurnad for alt som granskar banen. På eit nettverk som berre toler trafikk som ser ut som HTTPS, fjernar det meste av grunnen til at SSTP blei valt. Ein liten, styrt klientpopulasjon absorberer dette; ein offentleg eller BYOD-brukar base gjer det ikkje.

Det andre trekket held 443 hos IIS og handsamar Apache som ein backend som proxyen videresender til. Det bevarar SSTP-standardverdien og lèt det vere éin eigar av porten, mot prisen av videresende headarar, ei klientadresse som applikasjonen ikkje lenger ser direkte, og ein backend som må snakke protokollen proxyen faktisk sender.

Prov eigaren, sertifikatet og handshaken i rekkjefølgje

Ein fullført TCP-tilkopling provar at det finst ein lyttar og ingenting anna, difor kan ein portskann sjå sunn ut medan tunnelen framleis feilar. Dei fire trinna feilar på ulike måtar, og ein reparasjon retta mot trinnet du ikkje braut, gjer vanlegvis kollisjonen djupare. Arbeid deg gjennom dei i rekkjefølgje og stopp der svaret deler seg.

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

Den første lina nemner PID-en som held 443, og det bør vere tenesta du nettopp konfigurerte. Den andre listar maskinsertifikat med subjecta sine, så eit namn som ikkje stemmer med adressa i klientprofilen stikk seg straks ut. Hendingsspørjinga returnerer ferske SSTP-postar, og ein handshake som aldri når PPP-autentisering etterlèt ein annan post enn den som blir autentisert og deretter avvist. Det siste trinnet er berre synleg på klienten, der oppføringa anten rapporterer tilkopla eller nemner PPP-feilen.

Når éin vert må gjere begge jobbane, vel eigaren av 443 med overlegg og skriv valet ned, fordi neste person som slår på ein funksjon elles oppdagar denne kollisjonen på nytt. Å dele rollene er framleis det reinare svaret: ein offentleg webserver og eit endepunkt for ekstern tilgang har separate syklusar for oppdateringar, sertifikat og omstart, og dei syklusane møtest etter sin eigen plan. Uansett bør du la lyttetesten, registerbanen og den valde porten stå i overleveringsnotatet.