Ein port i Windows VPN-adressefelt verkar berre for SSTP

Ein VPN-server svarar på TCP 10443, den innebygde Windows-klienten har rette påloggingsdata, og tilkoplinga døyr likevel etter ein pause som ser ut som ein DNS-tidsavbrot. Årsaka er vanlegvis adressefeltet: skriv du vpn.example.com:10443 i Servernamn eller adresse, les Windows heile strengen som eit vertsnamn, fordi feltet ikkje er eit generelt host:port-innfelt. Om ein port i det heile kan uttrykkjast der, avheng av tunneltypen profilen brukar, og berre éin av dei fire typane handsamar verdien som noko han kan tolke.

Kvifor adressefeltet ikkje er eit host:port-felt

Profileigenskapen bak feltet er ServerAddress, og kvar tunneltype avgjer kva han gjer med strengen. Tre av dei har ingen portparameter å fylle ut, så eit kolon og eit tal er berre teikn i eit namn som aldri vil bli slått opp. Den fjerde går over HTTPS, der ein port er ein del av URL-en, så verdien må skrivast i ei form som blir tolka som ein.

Difor ser feilen ut som namneoppslag og ikkje som ei avvist tilkopling. Det er ingen dårleg port å rapportere, berre eit vertsnamn som ikkje finst, og feilen kjem etter at oppslagaren gir opp. Før du rører serveren, sjekk kva tunneltype profilen hevdar å bruke.

Dei tre typane med fast port

PPTP koplar til TCP 1723 og ber deretter tunnelen i GRE, IP-protokoll 47. L2TP/IPsec brukar UDP 1701 for tunnelen og UDP 500 pluss 4500 for IPsec, der 4500 er NAT-gjennomføringsporten. IKEv2 brukar òg UDP 500 og 4500. Ingen av desse profilane viser eit portfelt nokon stad i grensesnittet, og ingen vil forhandle om ein ikkje-standard port.

Ein server som lyttar på ein eigendefinert port er difor utilgjengeleg for desse profilane, uansett korleis adressa er skriven. Dei praktiske svara er snevre: publiser standardporten på serveren, eller omset standardporten til den eigendefinerte på rutaren framfor han. Begge lèt klientprofilen vere urørt, noko som er verdt mykje når profilen blir distribuert via policy i staden for å bli skriven for hand.

SSTP treng ein URL, ikkje eit namn

SSTP er unntaket fordi det køyrer inne i ein TLS-økt. Feltet må tolkast som ein URL: først https://-skjemaet, deretter verten, deretter eit kolon og porten. Utan skjemaet held Windows fram med å handsame verdien som eit vanleg namn, og tilkoplinga feilar før noka TLS-utveksling skjer.

Grunnen til at dette overraskar folk, er at standardporten godtek det bare vertsnamnet. Ein profil som aldri trong ein eigendefinert port lærer aldri regelen, og den første som legg til ein, oppdagar han ved å feile. Etter at du har lagra, les den lagra verdien tilbake i staden for å stole på dialogen:

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

ServerAddress viser nøyaktig det som vart lagra. Om han blir lesen som eit bart vertsnamn med eit kolon i, fekk profilen aldri ein URL, og inga mengd nye forsøk vil rette det.

Leverandørsyntaks som blir limt inn i same felt

Nokre gateways dokumenterer ekstra konvensjonar for det feltet, som eit realm som blir lagt til etter porten eller spørjeparameterar som endrar sertifikathandteringa. Dei blir forstått av serveren til den leverandøren og, i nokre bygg, av hans eigen klient. Dei er ikkje ein del av Windows-profilformatet, og å lime dei inn i ein innebygd profil gir vanlegvis same stille namnefeilen.

Handsam ein parameter som slår av sertifikatvalidering som ei åtvaring og ikkje som ei retting. Om ein profil berre koplar til med den parameteren, passar ikkje sertifikatet til namnet som blir brukt, og den rette reparasjonen er på gatewayen, ikkje i klienten. Eit realm etter porten har same eigenskapen: det gjer noko berre om serveren på den andre sida ventar det.

Prov porten, og les deretter det feilande trinnet

Stadfest at noko godtek TCP på den porten frå nettverket til klienten før du klandrar profilen:

Test-NetConnection vpn.example.com -Port 10443

Suksess provar ein lyttar, ikkje SSTP. Ein webserver, ein omvend proxy eller ein lastbalansar kan fullføre TCP-handtrykket og framleis ikkje snakke SSTP, så ein grøn test med ein raud VPN er ein reell kombinasjon. Samanlikn sertifikatemnet med namnet i profilen, og sjekk RasClient-loggen i bygg som leverer han, fordi han registrerer trinnet som feila i staden for eit generisk tidsavbrot.

Vurder deretter alternativet som fjernar problemet i staden for å dokumentere det: vidaresend TCP 443 frå utsida til 10443 på VPN-serveren. Klienten brukar då standardprofilen utan nokon port, noko som vanlegvis er den reinaste ordninga for ein administrert flåte og lèt den eigendefinerte porten vere ein intern detalj.