Порт в полето за адрес на Windows VPN работи само със SSTP

VPN сървър отговаря на TCP 10443, вграденият клиент на Windows има правилните идентификационни данни, а връзката все пак умира след пауза, която изглежда като изтичане на времето за DNS. Причината обикновено е полето за адрес: въвеждането на vpn.example.com:10443 в Име на сървъра или адрес кара Windows да прочете целия низ като име на хост, защото това поле не е общ вход host:port. Дали порт може да бъде изразен там изобщо зависи от типа тунел, който използва профилът, и само един от четирите типа третира стойността като нещо, което може да анализира.

Защо полето за адрес не е поле host:port

Свойството на профила зад това поле е ServerAddress и всеки тип тунел решава какво прави с низа. Три от тях нямат параметър за порт, който да се попълни, така че двоеточието и числото са просто знаци в име, което никога няма да се разреши. Четвъртият работи през HTTPS, където портът е част от URL, така че стойността трябва да бъде написана във форма, която се анализира като URL.

Затова отказът изглежда като разрешаване на имена, а не като отказана връзка. Няма лош порт, за който да се съобщи, има само име на хост, което не съществува, и грешката идва след като резолверът се откаже. Преди да пипате сървъра, проверете какъв тип тунел твърди профилът, че използва.

Трите типа с фиксиран порт

PPTP се свързва с TCP 1723 и след това носи тунела в GRE, IP протокол 47. L2TP/IPsec използва UDP 1701 за тунела и UDP 500 плюс 4500 за IPsec, като 4500 е портът за преминаване през NAT. IKEv2 също използва UDP 500 и 4500. Никой от тези профили не показва поле за порт никъде в интерфейса и никой няма да преговаря за нестандартен порт.

Сървър, който слуша на персонализиран порт, следователно е недостъпен за тези профили, независимо как е написан адресът. Практичните отговори са тесни: публикувайте стандартния порт на сървъра или преобразувайте стандартния порт в персонализирания на рутера пред него. И двете оставят клиентския профил недокоснат, което е много ценно, когато профилът се разгръща чрез политика, а не се въвежда на ръка.

SSTP се нуждае от URL, не от име

SSTP е изключението, защото работи в TLS сесия. Полето трябва да се анализира като URL: първо схемата https://, после хостът, после двоеточие и портът. Без схемата Windows продължава да третира стойността като обикновено име и връзката се проваля преди какъвто и да е обмен на TLS.

Причината това да изненадва хората е, че портът по подразбиране приема голото име на хост. Профил, който никога не е имал нужда от персонализиран порт, никога не научава правилото, и първият човек, който добави такъв, го открива чрез провал. След запазване прочетете запазената стойност обратно, вместо да се доверявате на диалога:

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

ServerAddress показва точно това, което е било запазено. Ако се чете като голо име на хост с двоеточие в него, профилът никога не е получил URL и никакъв брой повторни опити няма да го поправи.

Синтаксис на производителя, който се поставя в същото поле

Някои шлюзове документират допълнителни конвенции за това поле, като realm, добавен след порта, или параметри на заявката, които променят обработката на сертификати. Те се разбират от сървъра на този производител и в някои сборки от собствения му клиент. Не са част от формата на профила на Windows и поставянето им във вграден профил обикновено води до същия тих отказ на име.

Третирайте параметър, който изключва проверката на сертификата, като предупреждение, а не като поправка. Ако даден профил се свързва само с този параметър, сертификатът не съответства на използваното име и правилната поправка е на шлюза, а не в клиента. Realm след порта има същото свойство: прави нещо само ако сървърът от другата страна го очаква.

Докажете порта, след което прочетете етапа, който се проваля

Преди да обвините профила, потвърдете, че нещо приема TCP на този порт от мрежата на клиента:

Test-NetConnection vpn.example.com -Port 10443

Успехът доказва слушател, а не SSTP. Уеб сървър, обратен прокси или балансиращ товара могат да завършат TCP ръкостискането и въпреки това да не говорят SSTP, така че зелен тест с червен VPN е реална комбинация. Сравнете субекта на сертификата с името в профила и проверете дневника RasClient в сборките, които го доставят, защото той записва етапа, който се е провалил, вместо общо изтичане на времето.

След това обмислете варианта, който премахва проблема, вместо да го документира: пренасочете TCP 443 отвън към 10443 на VPN сървъра. Тогава клиентът използва профила по подразбиране без никакъв порт, което обикновено е най-чистата подредба за управляван парк и оставя персонализирания порт като вътрешна подробност.