Разделённый туннель в Windows: флажок шлюза и пропавший префикс

Туннель сообщает о подключении, и вики всё ещё загружается. Потом загрузка застревает, и общий ресурс на полке перестаёт отвечать. Туннель сделал своё дело, а профиль просто заявил права на каждое назначение.

Windows рассматривает VPN-подключение как решение о маршруте. Пока это решение не сужено, машина ведёт себя так, будто переехала в офис.

Почему работающий туннель ощущается как сбой

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

Симптомы намеренно сбивают с толку. Разрешение имён может ещё работать, пока общий ресурс выходит по тайм-ауту, или наоборот. Пользователь сообщает, что VPN сломан, клиент сообщает, что у него всё в порядке, и оба утверждения точны.

Флажок, спрятанный в диалоге IPv4

Параметр находится несколькими диалогами глубже. Откройте ncpa.cpl, щёлкните правой кнопкой по подключению, затем свойства IPv4, затем Дополнительно, и снимите параметр, который позволяет подключению стать удалённым шлюзом по умолчанию. Этот один флажок решает, является ли профиль полным туннелем. Всё остальное в профиле по-прежнему действует.

Сравните route print -4 до и после переподключения. Запись 0.0.0.0, которая раньше указывала на туннель, должна исчезнуть, а корпоративные префиксы должны остаться.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Изменение метрики интерфейса не заменяет этого. Метрика решает только между двумя конкурирующими маршрутами по умолчанию, и клиент, который при каждом подключении заново устанавливает свой маршрут по умолчанию, выигрывает это состязание независимо от заданного числа.

Префикс, который никто не указал

Разделённый туннель открывает именно те префиксы, что записаны в профиле. Офисная подсеть, добавленная после написания профиля, остаётся недоступной, хотя туннель совершенно здоров. Тогда отчёт приходит как один сломанный сервер, а не как сломанный VPN.

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

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

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

Доказать результат после перезагрузки

Трассируйте в обе стороны и разрешайте по имени. Публичная трассировка должна выходить через провайдера, внутренняя трассировка должна входить в туннель, а внутренний узел должен отвечать по имени, а не только по адресу.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Повторите после отключения, переподключения и одной перезагрузки. Префикс, который переживает ручное переподключение и исчезает после перезагрузки, никогда не сохранялся в профиле.

Оставьте в тесте и принтер, и NAS, потому что разделённый туннель, отрезающий устройства рядом с ноутбуком, решил одну проблему, создав меньшую и более раздражающую. Справочник Microsoft по Add-VpnConnectionRoute — это место, где сверяют написание параметров с версией вашего модуля.