DNS через VPN перехватывает каждый запрос: исправьте dns-priority в NetworkManager

Подключите офисный VPN, и внезапно каждый запрос имени уходит корпоративному resolver. Публичные имена всё ещё разрешаются, поэтому ничто не выглядит сломанным, пока не откажет имя локального принтера или запись split-horizon не вернёт адрес офиса. В некоторых установках Fedora происходит обратное: resolver провайдера продолжает отвечать после поднятия туннеля. И то и другое — один вопрос: какой resolver владеет этим запросом, — а в системах NetworkManager ответ живёт в свойствах DNS каждого подключения.

Два подключения, один победивший resolver

Каждое подключение объявляет приоритет DNS. Обычные подключения по умолчанию имеют 50, а VPN-подключения — 0, и побеждает меньшее значение. Именно из-за этого VPN-подключение молча обгоняет проводное для каждого домена, на который оно претендует: ноль побеждает пятьдесят без чьего-либо выбора.

Приоритет упорядочивает кандидатов. Он не ограничивает, о чём спрашивают победителя. VPN-подключение без домена поиска претендует на всё, поэтому его предпочтение отправляет и публичные запросы в туннель, а при разделённом туннеле — туда, куда перенаправляет корпоративный resolver.

Приоритет задаёт порядок, список поиска — владение

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Список поиска — это заявление о владении. Голый домен вроде corp.example становится суффиксом поиска и доменом маршрутизации. Форма только для маршрутизации ~corp.example отправляет запросы под этим суффиксом на это подключение, не добавляя домен к коротким именам. Эта тильда — разница между «спроси этот сервер» и «спроси этот сервер и допиши за меня».

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

Затем сделайте предпочтение явным и активируйте подключение заново:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Отрицательный приоритет — документированный способ сказать «предпочитай это подключение», а установка для обоих семейств адресов сохраняет единообразное поведение на хосте с подключением IPv6. Изменение свойства без повторной активации подключения не меняет ничего из того, что работает сейчас, поэтому последовательность заканчивается явной командой up.

Пусть разделение держит systemd-resolved

Плагин dnsmasq по умолчанию сливает запросы в один локальный resolver, поэтому разделение по соединениям остаётся грубым. systemd-resolved показывает разделение по каждому соединению, а resolvectl query называет соединение, которое ответило.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

После этого корпоративное соединение несёт corp.example, а публичный resolver обслуживает остальное. Когда запрос попадает на неправильное соединение, команда называет соединение, ответившее на него, и знать это лучше, чем знать только адрес.

Согласуйте проект DNS с типом туннеля

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

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

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

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

Спросите одно внутреннее и одно публичное имя и посмотрите, куда запрос действительно идёт. Страница проверки утечек говорит, какой resolver ответил, а не какое соединение выбрала система, поэтому она ничего не говорит о порядке, который вы только что настроили.

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