En port i Windows VPN-adressefeltet virker kun for SSTP

En VPN-server svarer på TCP 10443, den indbyggede Windows-klient har de rigtige legitimationsoplysninger, og forbindelsen dør stadig efter en pause, der ligner en DNS-timeout. Årsagen er normalt adressefeltet: hvis du skriver vpn.example.com:10443 i Servernavn eller adresse, læser Windows hele strengen som et værtsnavn, fordi feltet ikke er et generelt host:port-input. Om en port overhovedet kan udtrykkes der, afhænger af den tunneltype, profilen bruger, og kun én af de fire typer behandler værdien som noget, den kan fortolke.

Hvorfor adressefeltet ikke er et host:port-felt

Profilegenskaben bag feltet er ServerAddress, og hver tunneltype bestemmer, hvad den gør med strengen. Tre af dem har ingen portparameter at udfylde, så et kolon og et tal er blot tegn i et navn, der aldrig vil blive opløst. Den fjerde kører over HTTPS, hvor en port er en del af URL’en, så værdien skal skrives i en form, der fortolkes som en.

Det er derfor, fejlen ligner navneopløsning i stedet for en afvist forbindelse. Der er ingen dårlig port at rapportere, kun et værtsnavn, der ikke findes, og fejlen kommer, efter at resolveren giver op. Før du rører ved serveren, skal du kontrollere, hvilken tunneltype profilen hævder at bruge.

De tre typer med en fast port

PPTP opretter forbindelse til TCP 1723 og bærer derefter tunnelen i GRE, IP-protokol 47. L2TP/IPsec bruger UDP 1701 til tunnelen og UDP 500 plus 4500 til IPsec, hvor 4500 er NAT-traversalporten. IKEv2 bruger også UDP 500 og 4500. Ingen af disse profiler eksponerer et portfelt nogen steder i grænsefladen, og ingen vil forhandle om en ikke-standard port.

En server, der lytter på en brugerdefineret port, er derfor uopnåelig for disse profiler, uanset hvordan adressen skrives. De praktiske svar er snævre: udgiv standardporten på serveren, eller oversæt standardporten til den brugerdefinerede på routeren foran den. Begge holder klientprofilen urørt, hvilket er værdifuldt, når profilen udrulles via politik i stedet for at blive skrevet i hånden.

SSTP kræver en URL, ikke et navn

SSTP er undtagelsen, fordi det kører inde i en TLS-session. Feltet skal fortolkes som en URL: først https://-skemaet, derefter værten, derefter et kolon og porten. Uden skemaet bliver Windows ved med at behandle værdien som et almindeligt navn, og forbindelsen fejler, før nogen TLS-udveksling sker.

Grunden til, at det overrasker folk, er, at standardporten accepterer det bare værtsnavn. En profil, der aldrig har haft brug for en brugerdefineret port, lærer aldrig reglen, og den første, der tilføjer en, opdager det ved at fejle. Når du har gemt, skal du læse den gemte værdi tilbage i stedet for at stole på dialogen:

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

ServerAddress viser præcis, hvad der blev gemt. Hvis den læses som et bart værtsnavn med et kolon i, har profilen aldrig modtaget en URL, og ingen mængde gentagne forsøg vil rette det.

Leverandørsyntaks, der indsættes i det samme felt

Nogle gateways dokumenterer ekstra konventioner for det felt, såsom et realm tilføjet efter porten eller forespørgselsparametre, der ændrer certifikathåndtering. De forstås af den leverandørs server og i nogle builds af dens egen klient. De er ikke en del af Windows-profilformatet, og hvis de indsættes i en indbygget profil, giver det normalt den samme lydløse navnefejl.

Behandl en parameter, der deaktiverer certifikatvalidering, som en advarsel i stedet for en rettelse. Hvis en profil kun opretter forbindelse med den parameter, matcher certifikatet ikke det navn, der bruges, og den korrekte reparation er på gatewayen, ikke i klienten. Et realm efter porten har samme egenskab: det gør noget, kun hvis serveren på den anden side forventer det.

Bevis porten, og læs derefter det fejlende trin

Bekræft, at noget accepterer TCP på den port fra klientens netværk, før du bebrejder profilen:

Test-NetConnection vpn.example.com -Port 10443

Succes beviser en lytter, ikke SSTP. En webserver, en omvendt proxy eller en load balancer kan fuldføre TCP-handshaket og stadig ikke tale SSTP, så en grøn test med en rød VPN er en reel kombination. Sammenlign certifikatets emne med navnet i profilen, og tjek RasClient-loggen i builds, der leverer den, fordi den registrerer det trin, der fejlede, i stedet for en generisk timeout.

Overvej derefter den mulighed, der fjerner problemet i stedet for at dokumentere det: videresend TCP 443 udefra til 10443 på VPN-serveren. Klienten bruger så standardprofilen uden nogen port, hvilket normalt er det reneste arrangement for en administreret flåde og lader den brugerdefinerede port være en intern detalje.