Port v poli adresy Windows VPN funguje jen u SSTP

Server VPN odpovídá na TCP 10443, vestavěný klient Windows má správné přihlašovací údaje a spojení přesto padá po pauze, která vypadá jako časový limit DNS. Příčinou bývá obvykle pole adresy: když do pole Název serveru nebo adresa napíšete vpn.example.com:10443, Windows přečte celý řetězec jako název hostitele, protože toto pole není obecný vstup host:port. Zda v něm lze port vůbec vyjádřit, závisí na typu tunelu, který profil používá, a jen jeden ze čtyř typů hodnotu považuje za něco, co dokáže analyzovat.

Proč pole adresy není polem host:port

Vlastnost profilu za tímto polem je ServerAddress a každý typ tunelu rozhoduje, co s řetězcem udělá. Tři z nich nemají žádný parametr portu k vyplnění, takže dvojtečka a číslo jsou jen znaky v názvu, který se nikdy nepřeloží. Čtvrtý běží přes HTTPS, kde je port součástí URL, takže hodnota musí být zapsána ve tvaru, který se jako URL analyzuje.

Proto selhání vypadá jako překlad jmen, a ne jako odmítnuté spojení. Není žádný špatný port, který by šel nahlásit, pouze název hostitele, který neexistuje, a chyba přijde poté, co překladač to vzdá. Než sáhnete na server, zkontrolujte, jaký typ tunelu profil tvrdí, že používá.

Tři typy s pevným portem

PPTP se připojuje na TCP 1723 a potom nese tunel v GRE, IP protokolu 47. L2TP/IPsec používá UDP 1701 pro tunel a UDP 500 plus 4500 pro IPsec, přičemž 4500 je port pro průchod NAT. IKEv2 používá také UDP 500 a 4500. Žádný z těchto profilů nikde v rozhraní neodhaluje pole portu a žádný nevyjedná nestandardní port.

Server, který naslouchá na vlastním portu, je proto pro tyto profily nedostupný bez ohledu na to, jak je adresa napsaná. Praktické odpovědi jsou úzké: zveřejněte standardní port na serveru, nebo přeložte standardní port na vlastní na routeru před ním. Obě varianty nechávají klientský profil nedotčený, což má velkou cenu, když se profil nasazuje zásadou, a ne ručním psaním.

SSTP potřebuje URL, ne název

SSTP je výjimka, protože běží uvnitř relace TLS. Pole se musí analyzovat jako URL: nejprve schéma https://, potom hostitel, potom dvojtečka a port. Bez schématu Windows hodnotu dál považuje za obyčejný název a spojení selže dřív, než dojde k jakékoli výměně TLS.

Důvod, proč to lidi překvapuje, je ten, že výchozí port přijímá holý název hostitele. Profil, který nikdy vlastní port nepotřeboval, pravidlo nikdy nenaučí, a první člověk, který nějaký přidá, to zjistí tak, že selže. Po uložení si uloženou hodnotu přečtěte, místo abyste věřili dialogu:

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

ServerAddress ukazuje přesně to, co bylo uloženo. Pokud se čte jako holý název hostitele s dvojtečkou, profil nikdy nedostal URL a žádné opakované pokusy to nespraví.

Syntaxe dodavatele, která se vkládá do stejného pole

Některé brány dokumentují pro toto pole další konvence, například realm připojený za portem nebo parametry dotazu, které mění zacházení s certifikáty. Rozumí jim server daného dodavatele a v některých sestaveních i jeho vlastní klient. Nejsou součástí formátu profilu Windows a jejich vložení do vestavěného profilu obvykle vede ke stejné tiché chybě názvu.

Parametr, který vypíná ověřování certifikátů, berte jako varování, ne jako opravu. Pokud se profil připojuje jen s tímto parametrem, certifikát neodpovídá použitému názvu a správná oprava patří na bránu, ne do klienta. Realm za portem má stejnou vlastnost: něco dělá jen tehdy, když ho server na druhé straně očekává.

Dokažte port a pak čtěte selhávající fázi

Než obviníte profil, ověřte, že něco přijímá TCP na tomto portu ze sítě klienta:

Test-NetConnection vpn.example.com -Port 10443

Úspěch dokazuje naslouchající proces, ne SSTP. Webový server, reverzní proxy nebo load balancer mohou dokončit TCP handshake a přesto nemluvit SSTP, takže zelený test s červenou VPN je skutečná kombinace. Porovnejte subjekt certifikátu s názvem v profilu a podívejte se do protokolu RasClient v sestaveních, která ho dodávají, protože zaznamenává fázi, která selhala, místo obecného časového limitu.

Potom zvažte možnost, která problém odstraní, místo aby ho dokumentovala: přesměrujte TCP 443 zvenčí na 10443 na serveru VPN. Klient pak používá výchozí profil úplně bez portu, což je obvykle nejčistší uspořádání pro spravovanou flotilu a vlastní port zůstane interním detailem.