Встроенный VPN Windows не доходит до SSL-шлюза поставщика: почему

В Windows встроено четыре типа туннелей, и шлюза поставщика SSL среди них нет. Всё равно направьте встроенный профиль на такой шлюз, и соединение сорвётся ещё до запроса учётных данных, обычно с сообщением о том, что соединение разорвано локальной системой. Этот текст — признак несовпадения, а не диагноз. Тип профиля и клиент, владеющий протоколом, должны совпадать, и одного из них нет.

Четыре типа и одно окно

Каждый сохранённый профиль несёт тип туннеля. Встроенный клиент принимает PPTP, L2TP, IKEv2 и SSTP, а также автоматический режим, который пробует их по порядку. Общей записи SSL VPN нет, и добавить её через диалог нельзя. Шлюз поставщика говорит собственным прикладным протоколом поверх TLS, который реализует только клиент этого поставщика.

Список находится в одной команде, и его стоит выполнить до любого другого разбора, потому что он занимает секунду и убирает целый класс неверных допущений:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Если профиль говорит SSTP, а шлюз не является сервером RRAS, несовпадение уже установлено. Никакая работа с сертификатами или брандмауэром этого не меняет.

SSTP и TLS поставщика выглядят одинаково на порту 443

SSTP заворачивает сеанс PPP в TLS и идёт по TCP 443. В стеке Microsoft его завершает RRAS, который предъявляет сертификат сервера, проверяемый клиентом. Устройство Fortinet, Citrix или Pulse тоже завершает TLS на 443, и его портал открывается в любом браузере без жалоб.

Эта проверка в браузере доказывает доступность, а не совместимость. Протокол сеанса за порталом принадлежит поставщику, и во встроенном клиенте его реализации нет. Поставляет ли поставщик собственный клиент — это подсказывает, с какой половиной несовпадения вы имеете дело.

Бывает и обратная путаница. Профиль, настроенный как SSTP против настоящего сервера RRAS, может не пройти проверку сертификата, хотя портал в порядке, и это проблема сертификата, а не протокола.

Ошибки, которые появляются до создания туннеля

Коды серии 800 сообщаются до установления любого туннеля, поэтому правила брандмауэра редко их сдвигают. Ошибка 812 — это серверная политика, отклоняющая предложенный клиентом метод проверки подлинности. Остальные в этом диапазоне приходят от локального диспетчера подключений, а не от сети.

Включите трассировку, прежде чем что-то перестраивать. Трассировка называет отказавший этап, а имя этапа ценнее текста в диалоге:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Трассировки попадают в каталог трассировки и остаются там, пока вы их не очистите, поэтому потом отключите трассировку, а не оставляйте её работать неделями.

Подключённый профиль всё равно может всё сломать

Профиль, который подключается и затем ломает просмотр, локальную папку или движок контейнеров, имеет проблему маршрутизации, а не туннеля. Шлюз по умолчанию переехал в туннель, поэтому каждый адресат теперь идёт через узел, который может его не маршрутизировать.

Это решают две настройки. Одна — свойство split tunneling в профиле. Другая — опция для каждого адаптера использовать шлюз по умолчанию в удалённой сети, которая находится в дополнительных параметрах IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Включение split tunneling без добавления маршрутов даёт туннель, который подключается и никуда не попадает. Отключение без проверки DNS даёт внутренние имена, разрешающиеся в публичные ответы, потому что собственный суффикс и серверы адаптера не используются.

Проверьте обвязку, затем тип

Работайте в этом порядке и останавливайтесь, когда шаг не удался, вместо того чтобы править всё сразу:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

Первая команда отделяет доступность от протокола. Вторая подтверждает, чем профиль себя объявляет. Таблица маршрутов показывает, захватил ли туннель маршрут по умолчанию. Команда вызова сообщает собственную ошибку диспетчера подключений, которая часто яснее диалога.

Запишите в заявке тип туннеля, продукт шлюза и точную ошибку. Тогда следующий человек за минуту поймёт, это несовпадение протокола, отказ сертификата или решение о маршрутизации, вместо того чтобы начинать с «VPN не работает».