SSTP nahm Port 443: warum Apache nicht startet

Apache antwortet an dem Nachmittag nicht mehr auf 443, an dem jemand eingehende VPN-Verbindungen aktiviert, und sein Fehlerprotokoll beschuldigt das Binden statt der Reservierung dahinter. Windows Routing and Remote Access schaltet SSTP in diesem Moment ein, und der SSTP-Listener beansprucht TCP 443 über den HTTP-Stack, bevor irgendein Client sich authentifiziert. Der Anspruch bleibt bestehen, selbst wenn das Zertifikat fehlt, der Name falsch ist oder jeder Handshake zurückgewiesen wird, sodass ein VPN, in das sich niemand einloggen kann, den Port trotzdem belegt. Lesen Sie zuerst die Lausch-Tabelle; die PID, der 443 gehört, entscheidet, welche der folgenden Korrekturen für Sie überhaupt offen ist.

Die Reservierung überlebt ein kaputtes Zertifikat

SSTP verpackt PPP in eine TLS-Sitzung, deshalb braucht es 443 und deshalb passiert es Proxys, die andere Tunnel verwerfen. Der Listener ist kein Socket, den der VPN-Dienst für sich selbst öffnet: SstpSvc registriert ihn beim HTTP-Treiber des Kerns, sodass der Port reserviert bleibt, solange der Dienst läuft. Diese Registrierung konsultiert nie das Zertifikat, was bedeutet, dass ein abgelaufener Name, ein unpassender Subject oder gar kein Zertifikat 443 belegt lassen. Fehler teilen sich dann in zwei Richtungen: zurückgewiesene Handshakes landen im System-Protokoll unter RasSstp, während der Webserver nur melden kann, dass er nicht binden konnte.

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

Die erste Zeile liefert die besitzende PID; die zweite benennt den Dienst dahinter, und die Antwort ist meist der HTTP-Dienst oder der RRAS-Stack. Wenn tasklist mit einem gemeinsam genutzten Hostprozess antwortet, lesen Sie die Dienstspalte, statt aus dem Prozessnamen zu raten.

RasSstp-Warnungen lohnen sich erst danach, weil sie einen fehlgeschlagenen Handshake beschreiben und nichts über die Reservierung sagen, die die Kollision verursacht hat. Ein VPN-Endpunkt, der jeden Client abweist, besitzt den Port trotzdem. Behandeln Sie das Protokoll als zweite Frage, nicht als erste.

IIS teilt den Treiber, Apache öffnet einen Socket

IIS übergibt seine Bindings an denselben Kerntreiber, den SSTP nutzt, und dieser Treiber verteilt eingehende Verbindungen nach Hostname und URL-Präfix, sodass beide Dienste 443 wollen dürfen, ohne dass einer von ihnen scheitert. Apache und nginx machen das Gegenteil: Sie rufen bind auf ihrem eigenen Socket auf, und das Betriebssystem lehnt ab, weil die Adresse bereits belegt ist. An keiner der beiden Konfigurationen ist etwas falsch; der Unterschied liegt darin, welche API den Port besitzt. Das ist auch der Grund, warum das Aktivieren des VPN eine Site auf einem Host umwirft und eine identische Site auf einem anderen Host unberührt lässt.

Diese Asymmetrie bestimmt die Form der Reparatur. Ist IIS bereits die Eingangstür, wird die Kollision zu einer Frage von Präfixen, Bindings und Zertifikaten. Ist Apache die Eingangstür, weicht entweder sie von 443 oder der SSTP-Listener, und der nächste Abschnitt behandelt beide Züge.

Wählen Sie, welcher Dienst 443 behält

Der Listener-Port lebt in einem einzigen Registrierungswert, einem dezimalen DWORD unter dem Parameterschlüssel von Sstpsvc. Ändern Sie den Wert, starten Sie Routing and Remote Access neu und bestätigen Sie anhand der Lausch-Tabelle, dass der alte Port frei ist.

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

Wählen Sie einen Port, den sonst nichts auf dem Host will, und tippen Sie ihn dezimal ein: reg add speichert das DWORD genau so, wie es geschrieben steht, sodass ein als hexadezimal gedachter Wert als anderer Port landet. Sagt die Abfrage, der Wert existiere nicht, legt die zweite Zeile ihn an. Restart-Service RemoteAccess wirft alle hinaus, die verbunden sind, was es wert ist, eingeplant zu werden. Führen Sie danach die Lausch-Prüfung erneut aus, denn ein veralteter Eintrag auf 443 bedeutet, dass der Dienst seine alte Registrierung behalten hat.

Das Verschieben des Listeners hat einen Preis, den die Registrierungsänderung nicht zeigt. Gewöhnliche SSTP-Clients wählen 443, also braucht jedes Clientprofil den neuen Port, und der Fluss ähnelt für alles, was den Pfad inspiziert, keinem Web-Request mehr. In einem Netz, das nur Verkehr duldet, der wie HTTPS aussieht, nimmt das den größten Teil des Grundes weg, aus dem SSTP gewählt wurde. Eine kleine, verwaltete Clientpopulation verkraftet das; eine öffentliche oder BYOD-Nutzerbasis nicht.

Der andere Zug behält 443 bei IIS und behandelt Apache als Backend, an das der Proxy weiterleitet. Er bewahrt den SSTP-Standard und lässt einen Eigentümer für den Port, zum Preis weitergeleiteter Header, einer Clientadresse, die die Anwendung nicht mehr direkt sieht, und eines Backends, das das Protokoll sprechen muss, das der Proxy tatsächlich sendet.

Beweisen Sie Eigentümer, Zertifikat und Handshake in dieser Reihenfolge

Eine abgeschlossene TCP-Verbindung beweist, dass ein Listener existiert, und sonst nichts, weshalb ein Portscan gesund aussehen kann, während der Tunnel weiter scheitert. Die vier Stufen scheitern auf verschiedene Weise, und eine Reparatur, die auf die Stufe zielt, die Sie nicht zerbrochen haben, vertieft die Kollision meist. Arbeiten Sie sie der Reihe nach ab und halten Sie dort an, wo die Antwort auseinandergeht.

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

Die erste Zeile benennt die PID, die 443 hält, und das sollte der Dienst sein, den Sie gerade konfiguriert haben. Die zweite listet Maschinenzertifikate mit ihren Subjects auf, sodass ein Name, der nicht zur Adresse im Clientprofil passt, sofort auffällt. Die Ereignisabfrage liefert aktuelle SSTP-Datensätze, und ein Handshake, der nie die PPP-Authentifizierung erreicht, hinterlässt einen anderen Datensatz als einer, der sich authentifiziert und dann abgelehnt wird. Die letzte Stufe ist nur beim Client sichtbar, wo der Eintrag entweder verbunden meldet oder den PPP-Fehler benennt.

Wenn ein Host beide Aufgaben erledigen muss, wählen Sie den Eigentümer von 443 bewusst und schreiben Sie die Wahl auf, weil die nächste Person, die eine Funktion aktiviert, diese Kollision sonst neu entdeckt. Die Rollen zu trennen bleibt die sauberere Antwort: Ein öffentlicher Webserver und ein Fernzugriffs-Endpunkt tragen getrennte Patch-, Zertifikats- und Neustartzyklen, und diese Zyklen treffen sich nach ihrem eigenen Zeitplan. Lassen Sie in jedem Fall die Lausch-Prüfung, den Registrierungspfad und den gewählten Port in der Übergabenotiz.