DNS гостя VirtualBox NAT ломается после подключения хоста к VPN

На хосте Windows внутреннее имя приложения разрешается, как только подключается VPN, а внутри гостя Ubuntu — нет. Гость сохраняет собственные настройки резолвера, а NAT-адаптер перед ним может отвечать на DNS-запросы двумя разными способами. Если направить гостя на публичный резолвер, сайты снова загружаются, а частные имена остаются сломанными. Поэтому путь резолвера прослеживается до любых изменений.

Проследите один запрос через NAT-адаптер

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

Прежде чем идти дальше, убедитесь, что адаптер действительно обычный NAT. Мостовой адаптер, именованная сеть NAT и второй VPN-клиент внутри гостя имеют каждый свою конфигурацию и своё объяснение. Догадки на этом этапе тратят остаток расследования.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Первая команда показывает режим адаптера и любую сеть NAT, привязанную к нему. Внутри гостя Ubuntu вторая перечисляет настройки DNS для каждого подключения, а третья часто показывает только локальный stub-адрес, то есть настоящий upstream находится в другом месте.

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

Режим прокси и режим резолвера хоста — разные механизмы

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

Это различие — вся проблема в одном предложении. Дать гостю список адресов серверов — не то же самое, что попросить Windows разрешить имя через настроенный резолвер, а в VPN с разделённым DNS два ответа различаются. Опция адаптера касается механизма, а не разрешения.

Ни один из режимов не даёт доступа ни к чему. Авторизация живёт в политике VPN и в службе, а работающий запрос означает лишь, что имя превратилось в адрес.

Переключите адаптер, затем проверьте, что получает гость

Сначала запишите сетевые настройки и настройки DNS виртуальной машины, затем выключите её, чтобы вы редактировали постоянную конфигурацию. Для ВМ с именем work-ubuntu, чей первый адаптер несёт NAT, опция для конкретного адаптера задаётся с хоста, пока ВМ выключена. Затем запустите её снова и изучите результат, вместо того чтобы доверять коду выхода.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Последняя цифра выбирает номер адаптера, поэтому это не универсальное значение; настройка для адаптера 2 несла бы 2 на этом месте. Используйте бинарный файл VBoxManage, принадлежащий установленной версии VirtualBox, потому что более старый в пути может записать настройки, которые работающая версия игнорирует.

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

Тестируйте на протяжении всего жизненного цикла VPN, а не только один раз

Повторите оба запроса в госте, затем откройте настоящее приложение и дайте ему проверить имя хоста TLS. Тест соединения только по IP хорошо изолирует DNS, но это не проверка сертификата и о ней не следует сообщать как о таковой. Запишите имя, адрес и результат приложения вместе.

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

Когда режим резолвера хоста ничего не меняет, верните записанное значение и сохраните наблюдения. VPN-клиент, исключающий трафик гипервизора, недоступный внутренний резолвер и закреплённая настройка гостя требуют каждый своей правки, а объединение адаптера в мост меняет проект сети, а не сбрасывает DNS.