SSTP nam poort 443: waarom Apache niet start
De site die faalt is niet degene die 443 vasthoudt. Windows SSTP reserveert de poort via de HTTP-stack: verplaats de listener, zet IIS ervoor of verplaats de site.
Apache stopt met antwoorden op 443 op de middag dat iemand inkomende VPN-verbindingen inschakelt, en het foutenlogboek geeft de bind de schuld in plaats van de reservering erachter. Windows Routing and Remote Access schakelt dan SSTP in, en de SSTP-listener claimt TCP 443 via de HTTP-stack voordat er ook maar een client authenticeert. De claim blijft gelden, zelfs als het certificaat ontbreekt, de naam verkeerd is of elke handshake wordt geweigerd, dus een VPN waar niemand in kan, bezet de poort nog steeds. Lees eerst de luistertabel; de PID die 443 bezit bepaalt welke van de oplossingen hieronder überhaupt voor u openstaat.
De reservering overleeft een kapot certificaat
SSTP verpakt PPP in een TLS-sessie, daarom heeft het 443 nodig en daarom gaat het door proxies die andere tunnels laten vallen. De listener is geen socket die de VPN-dienst voor zichzelf opent: SstpSvc registreert hem bij de HTTP-driver van de kernel, zodat de poort gereserveerd blijft zolang de dienst draait. Die registratie raadpleegt nooit het certificaat, wat betekent dat een verlopen naam, een niet-passend subject of helemaal geen certificaat 443 bezet laten. Fouten splitsen zich dan in twee richtingen: geweigerde handshakes belanden in het System-log onder RasSstp, terwijl de webserver alleen kan melden dat hij niet kon binden.
netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"
De eerste regel geeft de bezittende PID terug; de tweede noemt de dienst erachter, en het antwoord is meestal de HTTP-dienst of de RRAS-stack. Wanneer tasklist antwoordt met een gedeeld hostproces, lees dan de dienstkolom in plaats van te gokken op de procesnaam.
RasSstp-waarschuwingen zijn pas daarna de moeite van het lezen waard, omdat ze een mislukte handshake beschrijven en niets zeggen over de reservering die de botsing veroorzaakte. Een VPN-eindpunt dat elke client weigert, bezit de poort nog steeds. Behandel het log als de tweede vraag, niet de eerste.
IIS deelt de driver, Apache opent een socket
IIS geeft zijn bindings aan dezelfde kerneldriver die SSTP gebruikt, en die driver splitst inkomende verbindingen op hostnaam en URL-voorvoegsel, zodat beide diensten gevraagd kan worden 443 te willen zonder dat een van beide faalt. Apache en nginx doen het omgekeerde: ze roepen bind aan op hun eigen socket, en het besturingssysteem weigert omdat het adres al bezet is. Niets in beide configuraties is fout; het verschil zit in welke API de poort bezit. Daarom zet het inschakelen van de VPN ook de ene site op een host omver en laat een identieke site op een andere host ongemoeid.
Deze asymmetrie bepaalt de vorm van de reparatie. Als IIS al de voordeur is, wordt de botsing een kwestie van voorvoegsels, bindings en certificaten. Als Apache de voordeur is, wijkt ofwel die van 443, ofwel de SSTP-listener, en de volgende sectie behandelt beide zetten.
Kies welke dienst 443 houdt
De luisterpoort woont in één registerwaarde, een decimale DWORD onder de parametersleutel van Sstpsvc. Wijzig de waarde, herstart Routing and Remote Access en bevestig aan de hand van de luistertabel dat de oude poort vrij is.
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
Kies een poort die niets anders op de host wil, en typ hem decimaal in: reg add slaat de DWORD precies op zoals hij geschreven is, dus een waarde die als hexadecimaal bedoeld was, komt als een andere poort terecht. Zegt de query dat de waarde niet bestaat, dan maakt de tweede regel hem aan. Restart-Service RemoteAccess gooit iedereen die verbonden is eruit, wat het plannen waard is. Draai daarna de luistercontrole opnieuw, want een verouderde vermelding op 443 betekent dat de dienst zijn oude registratie heeft behouden.
Het verplaatsen van de listener heeft een prijs die de registerwijziging niet laat zien. Gewone SSTP-clients kiezen 443, dus elk clientprofiel heeft de nieuwe poort nodig, en de stroom gaat niet langer op een webverzoek lijken voor alles wat het pad inspecteert. Op een netwerk dat alleen verkeer tolereert dat op HTTPS lijkt, haalt dat het grootste deel van de reden weg waarom voor SSTP is gekozen. Een kleine, beheerde clientpopulatie vangt dit op; een openbare of BYOD-gebruikersbasis niet.
De andere zet houdt 443 bij IIS en behandelt Apache als een backend waar de proxy naartoe doorstuurt. Dat bewaart de SSTP-standaard en laat één eigenaar voor de poort, tegen de prijs van doorgestuurde headers, een clientadres dat de applicatie niet meer direct ziet, en een backend die het protocol moet spreken dat de proxy werkelijk stuurt.
Bewijs de eigenaar, het certificaat en de handshake in volgorde
Een voltooide TCP-verbinding bewijst dat er een listener is en niets anders, daarom kan een poortscan gezond lijken terwijl de tunnel nog steeds faalt. De vier fasen falen op verschillende manieren, en een reparatie gericht op de fase die u niet hebt gebroken, verdiept meestal de botsing. Werk ze op volgorde af en stop waar het antwoord uiteenloopt.
netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20
De eerste regel noemt de PID die 443 houdt, en dat zou de dienst moeten zijn die u net hebt geconfigureerd. De tweede somt machinacertificaten met hun subjects op, zodat een naam die niet bij het adres in het clientprofiel past meteen opvalt. De gebeurtenisquery geeft recente SSTP-records terug, en een handshake die nooit de PPP-authenticatie bereikt, laat een ander record achter dan een die authenticeert en dan wordt geweigerd. De laatste fase is alleen op de client zichtbaar, waar de vermelding ofwel verbonden meldt ofwel de PPP-fout noemt.
Wanneer één host beide taken moet doen, kies dan bewust de eigenaar van 443 en schrijf de keuze op, want anders herontdekt de volgende persoon die een functie inschakelt deze botsing. De rollen scheiden blijft het schonere antwoord: een openbare webserver en een eindpunt voor externe toegang dragen aparte cycli voor patches, certificaten en herstarts, en die cycli ontmoeten elkaar volgens hun eigen schema. Laat in ieder geval de luistercontrole, het registerpad en de gekozen poort in de overdrachtsnotitie staan.