Почему ваш VPN в Windows убивает локальный принтер и как это остановить

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

Сначала прочитайте таблицу маршрутов

Прежде чем что-то менять, снимите таблицу IPv4 с помощью route print -4 и сохраните вывод. Подключитесь, снимите снова и сравните строки 0.0.0.0: активный маршрут по умолчанию называет интерфейс, и если этот интерфейс — туннель, локальная печать и просмотр отправляются сначала в офис.

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

Уберите маршрут по умолчанию, тремя способами

В встроенном профиле Windows управление — это флажок. Откройте свойства подключения, IPv4, затем Дополнительно и снимите Use default gateway on remote network; более новое приложение Параметры прячет тот же диалог на уровень глубже. Из командной строки с повышенными правами то же изменение — одна команда cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Профиль OpenVPN работает иначе, поэтому его поведение сбивает тех, кто ждёт флажок. Его директива redirect-gateway def1 вообще не заменяет маршрут по умолчанию: она устанавливает два маршрута половинного диапазона, 0.0.0.0/1 и 128.0.0.0/1, которые вместе побеждают маршрут по умолчанию, не удаляя его. Поскольку исходный маршрут по умолчанию выживает, добавление префикса, направленного на net_gateway, возвращает локальному маршрутизатору только этот префикс. Эта деталь объясняет, почему исправление для профиля def1 — это маршрут префикса, а не флажок, который никто не находит.

Верните только то, что относится к работе

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

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

Старый способ всё ещё работает и всё ещё есть в каждом чек-листе: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, с собственным индексом интерфейса и адресом шлюза туннеля. Он сохраняется между перезагрузками, в чём и смысл, и опасность: при следующей загрузке индекс может принадлежать чему-то другому.

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

Когда сервер решает за вас

Клиент, который игнорирует ваш флажок, обычно подчиняется политике. Профили Cisco несут настройку Allow Local LAN Access, и headend может прислать политику tunnel-all, которая отменяет всё, что клиент предпочёл бы; при принудительном туннеле локального переключателя нет. Читайте журнал клиента о присланных маршрутах и строках политики вместо повторной проверки того же диалога.

Затем посмотрите на разрешение имён — это отдельный переключатель от маршрутизации. Разделённый туннель всё ещё может получать внутренний resolver и суффикс поиска, поэтому локальное устройство доступно по адресу и не находится по имени, пока сторона DNS тоже не исправлена.

Перекрытия — другая проблема

Если домашняя LAN и офисная LAN делят префикс вроде 192.168.0.0/24, никакой маршрут их не различит. У каждого пакета этого диапазона один результат поиска, и исправление — перенумеровать одну сторону или добраться до офиса через транслированный адрес из пула. Добавление более конкретных маршрутов лишь сдвигает, какая половина сети ломается.

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