Внутренние имена не работают через VPN, а публичные сайты открываются

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

Два симптома, которые не одна неисправность

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

Ловушка в том, что добавление офисного резолвера повсюду исправляет первое и гарантирует второе. Добавление публичного резолвера повсюду делает наоборот.

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

Резолвер какого адаптера получает вопрос

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

Порядок привязки — только первая половина. Клиент также должен знать, какие имена принадлежат этому адаптеру, а это вопрос суффикса, а не порядка.

Положите ipconfig /all рабочей машины рядом с выводом ноутбука, сняв оба при поднятом туннеле. Рабочая машина покажет DNS-суффикс, специфичный для подключения, на своём офисном адаптере, а ноутбук может не показать никакого на туннеле. Это различие объясняет целый класс сообщений вида сервер прямо здесь, а имя всё равно не разрешается, потому что без суффикса короткое имя никогда не дополняется до зоны, которую обслуживает офисный резолвер.

Короткому имени нужен суффикс раньше, чем маршрут

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

Скопируйте суффикс рабочей машины в свойства IPv4 адаптера VPN на вкладке DNS, затем переподключитесь. В Linux эквивалент — домен поиска на канале туннеля, который systemd-resolved показывает для каждого канала, а не глобально.

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

Спросите резолвер напрямую, затем имя

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

В Linux VPN-клиент, перезаписывающий /etc/resolv.conf, полностью заменяет локальные резолверы. vpnc предоставляет DNSUpdate no, чтобы это остановить, а systemd-resolved может направлять в канал туннеля только перечисленные домены. Оба подхода оставляют публичные имена локальному резолверу, отправляя внутренние имена в офис.

Утечки — это правило, а не галочка

Разрешение имён — это обмен UDP на порт 53, поэтому туннель, несущий веб-трафик, но не UDP, оставляет запрос на физическом пути. Докажите это, захватив трафик на физической сетевой карте во время разрешения публичного имени. Запрос, видимый на этом интерфейсе в читаемом виде, означает, что туннель его не несёт.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Если запрос появляется на этом интерфейсе в читаемом виде, туннель его не транспортирует. Лечение — правило, разрешающее порт 53 только резолверу, выданному VPN, и отбрасывающее прочие назначения, плюс конфигурация клиента, которая не отбрасывает выданную опцию молча.

Последняя часть важнее, чем кажется. Запустите OpenVPN с route-nopull, и выданная опция DNS исчезнет вместе с маршрутами, если фильтр pull не расширен, чтобы её сохранить. А клиент, игнорирующий dhcp-option DNS, продолжит использовать то, что было раньше. Любое изменение на стороне сервера требует новой сессии, поскольку список резолверов доставляется при поднятии туннеля, а устаревшая сессия продолжает показывать старое состояние.

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