SSTP tog port 443: varför Apache inte startar

Apache slutar svara på 443 den eftermiddag någon aktiverar inkommande VPN-anslutningar, och felloggen skyller på bind i stället för reservationen bakom. Windows Routing and Remote Access slår på SSTP i det ögonblicket, och SSTP-lyssnaren gör anspråk på TCP 443 via HTTP-stacken innan någon klient autentiseras. Anspråket gäller även när certifikatet saknas, namnet är fel eller varje handskakning avvisas, så en VPN som ingen kommer in i ockuperar fortfarande porten. Läs lyssningstabellen först; PID:n som äger 443 avgör vilken av åtgärderna nedan som ens är öppen för dig.

Reservationen överlever ett trasigt certifikat

SSTP bäddar in PPP i en TLS-session, därför behöver den 443 och därför går den genom proxyservrar som släpper andra tunnlar. Lyssnaren är inte en socket som VPN-tjänsten öppnar för sig själv: SstpSvc registrerar den hos kärnans HTTP-drivrutin, så porten förblir reserverad så länge tjänsten körs. Den registreringen rådfrågar aldrig certifikatet, vilket innebär att ett utgånget namn, ett opassande subject eller inget certifikat alls lämnar 443 upptagen. Felen delar sig sedan i två riktningar: avvisade handskakningar hamnar i System-loggen under RasSstp, medan webbservern bara kan rapportera att den inte kunde binda.

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

Den första raden returnerar den ägande PID:n; den andra namnger tjänsten bakom den, och svaret är oftast HTTP-tjänsten eller RRAS-stacken. När tasklist svarar med en delad värdprocess, läs tjänstekolumnen i stället för att gissa utifrån processnamnet.

RasSstp-varningar är bara värda att läsa efteråt, eftersom de beskriver en handskakning som misslyckades och inte säger något om reservationen som orsakade kollisionen. En VPN-slutpunkt som avvisar varje klient äger fortfarande porten. Behandla loggen som den andra frågan, inte den första.

IIS delar drivrutinen, Apache öppnar en socket

IIS lämnar sina bindings till samma kärndrivrutin som SSTP använder, och den drivrutinen skiljer inkommande anslutningar efter värdnamn och URL-prefix, så båda tjänsterna kan ombedjas att vilja ha 443 utan att någon av dem misslyckas. Apache och nginx gör det motsatta: de anropar bind på sin egen socket, och operativsystemet vägrar eftersom adressen redan är tagen. Inget i någon av konfigurationerna är fel; skillnaden ligger i vilket API som äger porten. Det är också därför aktiveringen av VPN välter en webbplats på en värd och lämnar en identisk webbplats på en annan värd orörd.

Denna asymmetri avgör reparationens form. Om IIS redan är ytterdörren blir kollisionen en fråga om prefix, bindings och certifikat. Om Apache är ytterdörren flyttar antingen den bort från 443 eller SSTP-lyssnaren, och nästa avsnitt täcker båda dragen.

Välj vilken tjänst som behåller 443

Lyssnarporten bor i ett enda registervärde, ett decimalt DWORD under parameternyckeln för Sstpsvc. Ändra värdet, starta om Routing and Remote Access och bekräfta från lyssningstabellen att den gamla porten är 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älj en port som inget annat på värden vill ha, och skriv in den i decimal: reg add lagrar DWORD:n exakt som den skrivs, så ett värde som var tänkt som hexadecimalt landar som en annan port. Om frågan säger att värdet inte finns skapar den andra raden det. Restart-Service RemoteAccess kastar ut alla som är anslutna, vilket är värt att planera. Kör lyssningskontrollen igen efteråt, för en inaktuell post på 443 betyder att tjänsten behöll sin gamla registrering.

Att flytta lyssnaren har ett pris som registerändringen inte visar. Vanliga SSTP-klienter ringer 443, så varje klientprofil behöver den nya porten, och flödet slutar likna en webbförfrågan för allt som inspekterar sökvägen. I ett nätverk som bara tolererar trafik som ser ut som HTTPS tar det bort det mesta av skälet till att SSTP valdes. En liten, hanterad klientpopulation absorberar detta; en offentlig eller BYOD-användarbas gör det inte.

Det andra draget behåller 443 hos IIS och behandlar Apache som en backend som proxyn vidarebefordrar till. Det bevarar SSTP-standardvärdet och lämnar en ägare för porten, till priset av vidarebefordrade rubriker, en klientadress som applikationen inte längre ser direkt, och en backend som måste tala det protokoll proxyn faktiskt skickar.

Bevisa ägaren, certifikatet och handskakningen i ordning

En fullbordad TCP-anslutning bevisar att en lyssnare finns och inget annat, därför kan en portskanning se frisk ut medan tunneln fortfarande misslyckas. De fyra stegen misslyckas på olika sätt, och en reparation riktad mot steget du inte bröt fördjupar vanligen kollisionen. Arbeta igenom dem i ordning och stanna där svaret delar sig.

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

Den första raden namnger PID:n som håller 443, och det bör vara tjänsten du just konfigurerade. Den andra listar maskincertifikat med deras subjects, så ett namn som inte stämmer med adressen i klientprofilen sticker omedelbart ut. Händelsefrågan returnerar färska SSTP-poster, och en handskakning som aldrig når PPP-autentisering lämnar en annan post än den som autentiseras och sedan avvisas. Det sista steget syns bara på klienten, där posten antingen rapporterar ansluten eller namnger PPP-felet.

När en enda värd måste göra båda jobben, välj ägaren av 443 medvetet och skriv ned valet, för annars återupptäcker nästa person som aktiverar en funktion denna kollision. Att dela upp rollerna är fortfarande det renare svaret: en offentlig webbserver och en slutpunkt för fjärråtkomst bär separata cykler för patchning, certifikat och omstart, och de cyklerna möts enligt sitt eget schema. Låt i vilket fall som helst lyssningskontrollen, registervägen och den valda porten stå i överlämningsnoten.