Порт в поле адреса VPN Windows работает только с 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-сервере. Тогда клиент использует профиль по умолчанию вообще без порта, что обычно является самым чистым решением для управляемого парка и оставляет нестандартный порт внутренней деталью.