En port i Windows VPN-adressefelt virker bare for SSTP

En VPN-server svarer på TCP 10443, den innebygde Windows-klienten har riktige påloggingsdata, og tilkoblingen dør likevel etter en pause som ser ut som en DNS-tidsavbrudd. Årsaken er vanligvis adressefeltet: skriver du vpn.example.com:10443 i Servernavn eller adresse, leser Windows hele strengen som et vertsnavn, fordi feltet ikke er et generelt host:port-innfelt. Om en port i det hele tatt kan uttrykkes der, avhenger av tunneltypen profilen bruker, og bare én av de fire typene behandler verdien som noe den kan tolke.

Hvorfor adressefeltet ikke er et host:port-felt

Profilegenskapen bak feltet er ServerAddress, og hver tunneltype bestemmer hva den gjør med strengen. Tre av dem har ingen portparameter å fylle ut, så et kolon og et tall er bare tegn i et navn som aldri vil bli slått opp. Den fjerde går over HTTPS, der en port er en del av URL-en, så verdien må skrives i en form som tolkes som en.

Derfor ser feilen ut som navneoppslag og ikke som en avvist tilkobling. Det er ingen dårlig port å rapportere, bare et vertsnavn som ikke finnes, og feilen kommer etter at oppslageren gir opp. Før du rører serveren, sjekk hvilken tunneltype profilen hevder å bruke.

De tre typene med fast port

PPTP kobler til TCP 1723 og bærer deretter tunnelen i GRE, IP-protokoll 47. L2TP/IPsec bruker UDP 1701 for tunnelen og UDP 500 pluss 4500 for IPsec, der 4500 er NAT-gjennomføringsporten. IKEv2 bruker også UDP 500 og 4500. Ingen av disse profilene viser et portfelt noe sted i grensesnittet, og ingen vil forhandle om en ikke-standard port.

En server som lytter på en egendefinert port er derfor utilgjengelig for disse profilene, uansett hvordan adressen skrives. De praktiske svarene er snevre: publiser standardporten på serveren, eller oversett standardporten til den egendefinerte på ruteren foran den. Begge lar klientprofilen være urørt, noe som er verdt mye når profilen distribueres via policy i stedet for å skrives for hånd.

SSTP trenger en URL, ikke et navn

SSTP er unntaket fordi det kjører inne i en TLS-økt. Feltet må tolkes som en URL: først https://-skjemaet, deretter verten, deretter et kolon og porten. Uten skjemaet fortsetter Windows å behandle verdien som et vanlig navn, og tilkoblingen feiler før noen TLS-utveksling skjer.

Grunnen til at dette overrasker folk, er at standardporten godtar det bare vertsnavnet. En profil som aldri trengte en egendefinert port lærer aldri regelen, og den første som legger til en, oppdager den ved å feile. Etter at du har lagret, les den lagrede verdien tilbake i stedet for å stole på dialogen:

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

ServerAddress viser nøyaktig det som ble lagret. Hvis den leses som et bart vertsnavn med et kolon i, har profilen aldri fått en URL, og ingen mengde med nye forsøk vil rette det.

Leverandørsyntaks som limes inn i samme felt

Noen gateways dokumenterer ekstra konvensjoner for det feltet, som et realm som legges til etter porten eller spørreparametere som endrer sertifikathåndteringen. De forstås av den leverandørens server og, i noen bygg, av dens egen klient. De er ikke en del av Windows-profilformatet, og å lime dem inn i en innebygd profil gir vanligvis samme stille navnefeil.

Behandle en parameter som deaktiverer sertifikatvalidering som en advarsel og ikke som en rettelse. Hvis en profil bare kobler til med den parameteren, passer ikke sertifikatet til navnet som brukes, og den riktige reparasjonen er på gatewayen, ikke i klienten. Et realm etter porten har samme egenskap: det gjør noe bare hvis serveren på den andre siden forventer det.

Bevis porten, og les deretter det feilende trinnet

Bekreft at noe godtar TCP på den porten fra klientens nettverk før du klandrer profilen:

Test-NetConnection vpn.example.com -Port 10443

Suksess beviser en lytter, ikke SSTP. En webserver, en omvendt proxy eller en lastbalanserer kan fullføre TCP-håndtrykket og fortsatt ikke snakke SSTP, så en grønn test med en rød VPN er en reell kombinasjon. Sammenlign sertifikatets emne med navnet i profilen, og sjekk RasClient-loggen i bygg som leverer den, fordi den registrerer trinnet som feilet i stedet for en generisk tidsavbrudd.

Vurder deretter alternativet som fjerner problemet i stedet for å dokumentere det: videresend TCP 443 fra utsiden til 10443 på VPN-serveren. Klienten bruker da standardprofilen uten noen port, noe som vanligvis er den reneste ordningen for en administrert flåte og lar den egendefinerte porten være en intern detalj.