Ein Port im Windows-VPN-Adressfeld funktioniert nur bei SSTP

Ein VPN-Server antwortet auf TCP 10443, der integrierte Windows-Client hat die richtigen Anmeldeinformationen, und die Verbindung bricht trotzdem nach einer Pause ab, die wie ein DNS-Timeout aussieht. Die Ursache ist meistens das Adressfeld: Wenn man vpn.example.com:10443 in Servername oder Adresse eingibt, liest Windows die ganze Zeichenkette als Hostnamen, weil dieses Feld keine allgemeine host:port-Eingabe ist. Ob sich ein Port dort überhaupt ausdrücken lässt, hängt vom Tunneltyp ab, den das Profil verwendet, und nur einer der vier Typen behandelt den Wert als etwas, das er parsen kann.

Warum das Adressfeld kein host:port-Feld ist

Die Profileigenschaft hinter diesem Feld ist ServerAddress, und jeder Tunneltyp entscheidet, was er mit der Zeichenkette macht. Drei von ihnen haben keinen Portparameter zum Ausfüllen, sodass ein Doppelpunkt und eine Zahl einfach Zeichen in einem Namen sind, der niemals aufgelöst wird. Der vierte läuft über HTTPS, wo ein Port Teil der URL ist, sodass der Wert in einer Form geschrieben werden muss, die als URL geparst wird.

Deshalb sieht der Fehler wie eine Namensauflösung aus und nicht wie eine abgelehnte Verbindung. Es gibt keinen falschen Port zu melden, nur einen Hostnamen, den es nicht gibt, und der Fehler kommt, nachdem der Resolver aufgibt. Bevor Sie den Server anfassen, prüfen Sie, welchen Tunneltyp das Profil laut eigener Angabe verwendet.

Die drei Typen mit festem Port

PPTP verbindet sich mit TCP 1723 und trägt den Tunnel dann in GRE, IP-Protokoll 47. L2TP/IPsec verwendet UDP 1701 für den Tunnel und UDP 500 plus 4500 für IPsec, wobei 4500 der NAT-Traversal-Port ist. IKEv2 verwendet ebenfalls UDP 500 und 4500. Keines dieser Profile zeigt irgendwo in der Oberfläche ein Portfeld an, und keines handelt einen nicht standardmäßigen Port aus.

Ein Server, der auf einem eigenen Port lauscht, ist für diese Profile daher unerreichbar, egal wie die Adresse geschrieben wird. Die praktischen Antworten sind eng: den Standardport auf dem Server veröffentlichen oder den Standardport auf dem davorstehenden Router auf den eigenen Port übersetzen. Beides lässt das Clientprofil unangetastet, was viel wert ist, wenn das Profil per Richtlinie bereitgestellt und nicht von Hand eingetippt wird.

SSTP braucht eine URL, keinen Namen

SSTP ist die Ausnahme, weil es in einer TLS-Sitzung läuft. Das Feld muss als URL geparst werden: zuerst das https://-Schema, dann der Host, dann ein Doppelpunkt und der Port. Ohne das Schema behandelt Windows den Wert weiterhin als einfachen Namen, und die Verbindung scheitert, bevor irgendein TLS-Austausch stattfindet.

Der Grund, warum das Leute überrascht, ist, dass der Standardport den bloßen Hostnamen akzeptiert. Ein Profil, das nie einen eigenen Port brauchte, lehrt die Regel nie, und die erste Person, die einen hinzufügt, entdeckt sie durch Scheitern. Lesen Sie nach dem Speichern den gespeicherten Wert zurück, statt dem Dialog zu vertrauen:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress zeigt genau das, was gespeichert wurde. Wenn es als bloßer Hostname mit einem Doppelpunkt darin gelesen wird, hat das Profil nie eine URL erhalten, und kein noch so häufiges Wiederholen wird das beheben.

Herstellersyntax, die in dasselbe Feld eingefügt wird

Manche Gateways dokumentieren zusätzliche Konventionen für dieses Feld, etwa ein Realm, das nach dem Port angehängt wird, oder Abfrageparameter, die die Zertifikatsbehandlung ändern. Sie werden vom Server dieses Herstellers und in manchen Builds von seinem eigenen Client verstanden. Sie sind nicht Teil des Windows-Profilformats, und wenn man sie in ein integriertes Profil einfügt, entsteht meist derselbe stille Namensfehler.

Behandeln Sie einen Parameter, der die Zertifikatsprüfung deaktiviert, als Warnung und nicht als Lösung. Wenn ein Profil nur mit diesem Parameter eine Verbindung herstellt, passt das Zertifikat nicht zum verwendeten Namen, und die richtige Reparatur liegt am Gateway, nicht im Client. Ein Realm nach dem Port hat dieselbe Eigenschaft: Er bewirkt nur etwas, wenn der Server auf der anderen Seite ihn erwartet.

Beweisen Sie den Port, dann lesen Sie die fehlschlagende Stufe

Bestätigen Sie, dass etwas TCP auf diesem Port aus dem Netz des Clients annimmt, bevor Sie das Profil beschuldigen:

Test-NetConnection vpn.example.com -Port 10443

Erfolg beweist einen Listener, nicht SSTP. Ein Webserver, ein Reverse-Proxy oder ein Load Balancer kann den TCP-Handshake abschließen und trotzdem kein SSTP sprechen, sodass ein grüner Test mit einem roten VPN eine echte Kombination ist. Vergleichen Sie den Zertifikatsbetreff mit dem Namen im Profil und prüfen Sie das RasClient-Protokoll in Builds, die es mitbringen, denn es zeichnet die fehlgeschlagene Stufe auf statt eines allgemeinen Timeouts.

Erwägen Sie dann die Option, die das Problem beseitigt, statt es zu dokumentieren: Leiten Sie TCP 443 von außen auf 10443 auf dem VPN-Server weiter. Der Client verwendet dann das Standardprofil ganz ohne Port, was für eine verwaltete Flotte meist die sauberste Lösung ist und den eigenen Port als internes Detail belässt.