En port i Windows VPN-adressfältet fungerar bara för SSTP

En VPN-server svarar på TCP 10443, den inbyggda Windows-klienten har rätt inloggningsuppgifter, och anslutningen dör ändå efter en paus som ser ut som en DNS-timeout. Orsaken är oftast adressfältet: att skriva vpn.example.com:10443 i Servernamn eller adress gör att Windows läser hela strängen som ett värdnamn, eftersom fältet inte är en allmän host:port-inmatning. Om en port alls kan uttryckas där beror på vilken tunneltyp profilen använder, och bara en av de fyra typerna behandlar värdet som något den kan tolka.

Varför adressfältet inte är ett host:port-fält

Profilegenskapen bakom fältet är ServerAddress, och varje tunneltyp bestämmer vad den gör med strängen. Tre av dem har ingen portparameter att fylla i, så ett kolon och en siffra är bara tecken i ett namn som aldrig kommer att slås upp. Den fjärde går över HTTPS, där en port är en del av URL:en, så värdet måste skrivas i en form som tolkas som en.

Därför ser felet ut som namnmatchning och inte som en avvisad anslutning. Det finns ingen dålig port att rapportera, bara ett värdnamn som inte finns, och felet kommer efter att matcharen ger upp. Innan du rör servern, kontrollera vilken tunneltyp profilen säger sig använda.

De tre typerna med fast port

PPTP ansluter till TCP 1723 och bär sedan tunneln i GRE, IP-protokoll 47. L2TP/IPsec använder UDP 1701 för tunneln och UDP 500 plus 4500 för IPsec, där 4500 är NAT-genomträngningsporten. IKEv2 använder också UDP 500 och 4500. Ingen av dessa profiler visar ett portfält någonstans i gränssnittet, och ingen kommer att förhandla fram en icke-standardport.

En server som lyssnar på en anpassad port är därför oåtkomlig för dessa profiler, oavsett hur adressen skrivs. De praktiska svaren är snäva: publicera standardporten på servern, eller översätt standardporten till den anpassade på routern framför den. Båda lämnar klientprofilen orörd, vilket är värt mycket när profilen distribueras via policy i stället för att skrivas för hand.

SSTP behöver en URL, inte ett namn

SSTP är undantaget eftersom det körs inne i en TLS-session. Fältet måste tolkas som en URL: först https://-schemat, sedan värden, sedan ett kolon och porten. Utan schemat fortsätter Windows att behandla värdet som ett vanligt namn och anslutningen misslyckas innan något TLS-utbyte sker.

Anledningen till att detta förvånar folk är att standardporten accepterar det bara värdnamnet. En profil som aldrig behövde en anpassad port lär sig aldrig regeln, och den första personen som lägger till en upptäcker den genom att misslyckas. Efter att ha sparat, läs tillbaka det sparade värdet i stället för att lita på dialogen:

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

ServerAddress visar exakt det som sparades. Om det läses som ett bart värdnamn med ett kolon i, har profilen aldrig fått en URL och ingen mängd nya försök kommer att rätta det.

Leverantörssyntax som klistras in i samma fält

Vissa gateways dokumenterar extra konventioner för det fältet, som en realm som läggs till efter porten eller frågeparametrar som ändrar certifikathanteringen. De förstås av den leverantörens server och, i vissa byggen, av dess egen klient. De är inte en del av Windows-profilformatet, och att klistra in dem i en inbyggd profil ger vanligtvis samma tysta namnfel.

Behandla en parameter som stänger av certifikatvalidering som en varning och inte som en rättelse. Om en profil bara ansluter med den parametern matchar certifikatet inte namnet som används, och den korrekta reparationen är på gatewayen, inte i klienten. En realm efter porten har samma egenskap: den gör något bara om servern på andra sidan förväntar sig det.

Bevisa porten och läs sedan det misslyckade steget

Bekräfta att något accepterar TCP på den porten från klientens nätverk innan du skyller på profilen:

Test-NetConnection vpn.example.com -Port 10443

Framgång bevisar en lyssnare, inte SSTP. En webbserver, en omvänd proxy eller en lastbalanserare kan slutföra TCP-handskakningen och ändå inte tala SSTP, så ett grönt test med en röd VPN är en verklig kombination. Jämför certifikatets ämne med namnet i profilen och kontrollera RasClient-loggen i byggen som levererar den, eftersom den registrerar steget som misslyckades i stället för en allmän timeout.

Överväg sedan alternativet som tar bort problemet i stället för att dokumentera det: vidarebefordra TCP 443 utifrån till 10443 på VPN-servern. Klienten använder då standardprofilen utan någon port alls, vilket oftast är den renaste lösningen för en hanterad flotta och lämnar den anpassade porten som en intern detalj.