Een poort in het adresveld van Windows VPN werkt alleen voor SSTP

Een VPN-server antwoordt op TCP 10443, de ingebouwde Windows-client heeft de juiste inloggegevens, en de verbinding sterft toch na een pauze die op een DNS-time-out lijkt. De oorzaak is meestal het adresveld: vpn.example.com:10443 in Servernaam of adres typen laat Windows de hele tekenreeks als hostnaam lezen, omdat dat vak geen algemene host:port-invoer is. Of een poort daar überhaupt kan worden uitgedrukt, hangt af van het tunneltype dat het profiel gebruikt, en slechts één van de vier typen behandelt de waarde als iets wat het kan parseren.

Waarom het adresveld geen host:port-vak is

De profieleigenschap achter dat veld is ServerAddress, en elk tunneltype beslist wat het met de tekenreeks doet. Drie ervan hebben geen poortparameter om in te vullen, dus een dubbele punt en een getal zijn gewoon tekens in een naam die nooit wordt opgelost. Het vierde loopt over HTTPS, waar een poort deel uitmaakt van de URL, dus de waarde moet in een vorm worden geschreven die als URL wordt geparseerd.

Daarom lijkt de fout op naamresolutie en niet op een geweigerde verbinding. Er is geen verkeerde poort om te melden, alleen een hostnaam die niet bestaat, en de fout komt pas nadat de resolver het opgeeft. Controleer voordat u de server aanraakt welk tunneltype het profiel zegt te gebruiken.

De drie typen met een vaste poort

PPTP verbindt met TCP 1723 en draagt de tunnel daarna in GRE, IP-protocol 47. L2TP/IPsec gebruikt UDP 1701 voor de tunnel en UDP 500 plus 4500 voor IPsec, waarbij 4500 de NAT-traversalpoort is. IKEv2 gebruikt ook UDP 500 en 4500. Geen van die profielen toont ergens in de interface een poortveld, en geen ervan onderhandelt over een niet-standaard poort.

Een server die op een aangepaste poort luistert, is dus onbereikbaar voor die profielen, hoe het adres ook is geschreven. De praktische antwoorden zijn smal: publiceer de standaardpoort op de server, of vertaal de standaardpoort naar de aangepaste op de router ervoor. Beide laten het clientprofiel ongemoeid, wat veel waard is wanneer het profiel via beleid wordt uitgerold in plaats van met de hand getypt.

SSTP heeft een URL nodig, geen naam

SSTP is de uitzondering omdat het in een TLS-sessie draait. Het veld moet als URL worden geparseerd: eerst het https://-schema, dan de host, dan een dubbele punt en de poort. Zonder het schema blijft Windows de waarde als een gewone naam behandelen en mislukt de verbinding voordat er enige TLS-uitwisseling plaatsvindt.

De reden dat dit mensen verrast, is dat de standaardpoort de kale hostnaam accepteert. Een profiel dat nooit een aangepaste poort nodig had, leert de regel nooit, en de eerste persoon die er een toevoegt, ontdekt het door te falen. Lees na het opslaan de opgeslagen waarde terug in plaats van de dialoog te vertrouwen:

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

ServerAddress toont precies wat er is opgeslagen. Als het wordt gelezen als een kale hostnaam met een dubbele punt erin, heeft het profiel nooit een URL gekregen en geen enkele hoeveelheid opnieuw proberen zal dat repareren.

Leverancierssyntaxis die in hetzelfde vak wordt geplakt

Sommige gateways documenteren extra conventies voor dat veld, zoals een realm die na de poort wordt toegevoegd of queryparameters die de certificaatverwerking veranderen. Ze worden begrepen door de server van die leverancier en, in sommige builds, door zijn eigen client. Ze maken geen deel uit van het Windows-profielformaat, en ze in een ingebouwd profiel plakken levert meestal dezelfde stille naamfout op.

Behandel een parameter die certificaatvalidatie uitschakelt als een waarschuwing en niet als een oplossing. Als een profiel alleen met die parameter verbinding maakt, past het certificaat niet bij de gebruikte naam, en de juiste reparatie is op de gateway, niet in de client. Een realm na de poort heeft dezelfde eigenschap: het doet iets alleen als de server aan de andere kant het verwacht.

Bewijs de poort en lees dan de fase die faalt

Bevestig dat iets TCP op die poort accepteert vanuit het netwerk van de client voordat u het profiel de schuld geeft:

Test-NetConnection vpn.example.com -Port 10443

Succes bewijst een luisteraar, niet SSTP. Een webserver, een reverse proxy of een load balancer kan de TCP-handshake voltooien en toch geen SSTP spreken, dus een groene test met een rode VPN is een echte combinatie. Vergelijk het certificaatonderwerp met de naam in het profiel en controleer het RasClient-log in builds die het meeleveren, want dat legt de fase vast die mislukte in plaats van een generieke time-out.

Overweeg dan de optie die het probleem weghaalt in plaats van het te documenteren: stuur TCP 443 van buiten door naar 10443 op de VPN-server. De client gebruikt dan het standaardprofiel zonder enige poort, wat meestal de schoonste opzet is voor een beheerde vloot en de aangepaste poort als intern detail laat.