Локальная сеть недоступна при подключённом VPN? Четыре проверки

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

Сначала посмотрите на таблицу маршрутов, установленную клиентом

Откройте таблицу маршрутов клиента, пока VPN подключён. В Linux используйте ip route, в Windows — route print или Get-NetRoute, а в macOS — netstat -rn. Вы ищете маршрут по умолчанию через туннель и то, что случилось с физическим маршрутом по умолчанию.

Клиент с полным туннелем часто добавляет два полумаршрута по умолчанию, 0.0.0.0/1 и 128.0.0.0/1, вместо замены 0.0.0.0/0. Исходный маршрут по умолчанию остаётся видимым, но проигрывает каждый поиск, поэтому таблица может выглядеть целой, пока весь трафик за пределами подсети смещается. Если клиент VPN предлагает режим раздельного туннеля и политика это разрешает, это самое чистое исправление.

Если туннель должен остаться маршрутом по умолчанию, закрепите вместо этого локальную подсеть. В Linux маршрут называет физический интерфейс и шлюз; в Windows добавьте -p, чтобы сделать его постоянным, и прочитайте номер интерфейса из route print, а не угадывайте его:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

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

Во-вторых, убедитесь, что адрес изначально был локальным

Если назначение находится внутри подключённой подсети, маршрут по умолчанию через туннель никогда не применяется и VPN ни при чём. Принтер на 192.168.1.40 у клиента с 192.168.1.0/24 использует подключённый маршрут; если этот адрес не работает, смотрите на устройство, коммутатор или межсетевой экран клиента, а не на VPN.

Случай, который вводит людей в заблуждение, — публичный адрес локального сервера. Изнутри локальной сети добраться до WAN-адреса роутера и вернуться обратно позволяет только hairpin NAT, а многие роутеры его просто не реализуют для проброса портов. Проверьте частный адрес рядом с публичным. Если частный работает, а публичный нет, VPN лишь обнажил ограничение NAT, которое было и раньше.

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

В-третьих, посмотрите, кто теперь отвечает на имена

Корпоративный резолвер знает интранет и обычно ничего не знает об имени хоста NAS, имени Bonjour принтера или локальном псевдониме роутера. Когда VPN проталкивает свои DNS-серверы, эти имена перестают разрешаться, хотя их адреса по-прежнему доступны. Запросите имя напрямую и сравните ответ с адресом, который, как вы знаете, есть у устройства.

В Linux resolvectl query nas.local показывает, какой резолвер ответил. В Windows nslookup nas.local называет сервер, а ipconfig /all показывает порядок резолверов. Если локальным суффиксом теперь управляет корпоративный резолвер, либо направьте этот суффикс обратно к локальному резолверу, либо используйте для устройства IP-адрес.

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

В-четвёртых, проверьте, не подключена ли к VPN и другая машина

Если машина, до которой вы хотите добраться, тоже запускает клиент VPN, ваш сеанс может прийти, а ответ уйти через другой туннель. Получается соединение, которое устанавливается и затем зависает, или попытка RDP и SSH, которая на вашей стороне истекает по времени без ошибки. Проверьте таблицу маршрутов и путь по умолчанию у другого хоста, прежде чем винить свой клиент.

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

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

Примените исправление, соответствующее проваленной проверке

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

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

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