VPN в Windows забирает весь трафик? Удалите его маршрут по умолчанию

Вы подключаетесь к офисному VPN, и каждая страница в браузере начинает идти через эту сеть: файловый сервер быстрый, всё остальное медленное, отфильтрованное или исчезло. Клиент не ведёт себя неправильно; профиль запросил полный туннель. Переключатель, который это останавливает, — один флажок в диалоге, который современное приложение «Параметры» не показывает, и шлюз снова получает слово при каждом подключении. Это руководство идёт в том порядке, который интерфейс Windows действительно предлагает, а затем разбирает проверки, которые всё ещё не проходят, когда таблица маршрутов выглядит правильной.

Начните со свойств адаптера, а не с «Параметров»

Приложение «Параметры» перечисляет профиль в разделе «Сеть и Интернет», затем VPN, но показывает только общие параметры. Решение о шлюзе по умолчанию живёт на адаптере. Откройте классический список адаптеров с помощью Win+R и ncpa.cpl, щёлкните правой кнопкой по подключению VPN, выберите «Свойства», выберите «Протокол Интернета версии 4», снова «Свойства», затем «Дополнительно». Снимите флажок Использовать основной шлюз в удаленной сети и подтвердите выход из всех трёх диалогов.

Переподключитесь перед проверкой, потому что флажок применяется при установке туннеля, а существующий сеанс сохраняет построенную таблицу. Если адаптер отсутствует, пока клиент отключён, подключитесь один раз и снова откройте окно. Клиент поставщика, который устанавливает адаптер TAP или Wintun без страницы свойств IPv4, вообще не имеет этого диалога; для них то же решение — параметр раздельного туннелирования в собственных настройках клиента, а флажок адаптера — неправильное место для поиска.

То же изменение из PowerShell

Для профиля, созданного в хранилище VPN Windows, параметр можно задать скриптом, что и нужно, если машину часто пересобирают:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

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

Когда шлюз снова навязывает маршрут по умолчанию

Сначала прочитайте таблицу. Две записи по умолчанию с разными метриками означают, что изменение профиля сработало и навязанный маршрут всё равно его заменил:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

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

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

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

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

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

Проверьте DNS, IPv6 и метрики ещё раз после одного переподключения

Удаление маршрута по умолчанию IPv4 ничего не доказывает о другом семействе или о разрешении имён. Туннель может нести IPv6, пока маршрут по умолчанию IPv4 остаётся локальным, а навязанный список резолверов может поддерживать внутренние имена в работе, пока запросы, которые его используют, идут другим путём. Проверьте все три, прежде чем считать дело сделанным:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

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

Решите, от чего вы отказались

Локальный интернет-трафик больше не проверяется и не фильтруется офисом, и всё, что публикуется только через туннель, теперь нуждается в собственном маршруте. Некоторые организации считают раздельное туннелирование нарушением политики, поэтому подтвердите это перед изменением управляемого устройства; навязанный маршрут по умолчанию иногда является механизмом принуждения, а не случайностью. В документации Set-VpnConnection перечислены параметр раздельного туннелирования и типы профилей, к которым он применяется.

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