DNS гостя VirtualBox ломается, когда хост подключается к VPN
У гостя свой резолвер, и NAT может отвечать на DNS двумя способами. Четыре проверки: режим адаптера, путь резолвера, режим резолвера хоста и переподключение VPN.
Внутреннее приложение разрешается на хосте Windows в тот момент, когда подключается VPN, а гость Ubuntu за NAT VirtualBox по-прежнему его не находит. У гостя свой резолвер, и NAT-адаптер может обрабатывать DNS более чем одним способом. Замена резолвера гостя публичным сервером заставляет обычные сайты работать, а частные имена — нет, что переносит проблему, а не решает её. Выполните четыре проверки по порядку и остановитесь на первой, которая не подтвердится.
Подтвердите, какой режим адаптера вы отлаживаете
Только адаптер в простом режиме NAT ведёт себя так, как описано в этой статье. Мостовой адаптер находится в физической сети со своей идентичностью, сеть NAT — это именованный виртуальный коммутатор со своими настройками DHCP и DNS, а VPN-клиент внутри гостя добавляет полностью второй резолвер. Подтвердите режим, прежде чем читать дальше, потому что исправление различается в каждом из этих случаев.
Одна виртуальная машина может нести два адаптера в разных режимах, и пострадавший не всегда первый.
Также подтвердите, что хост вообще разрешает имя. Откройте то же приложение на хосте с поднятым туннелем, используя то же полное имя, которое будет использовать гость. Если хост тоже не справляется, гость не виноват, и никакое изменение виртуальной сети это не исправит.
Проследите одно имя через резолвер гостя
Выберите одно внутреннее имя и одно публичное контрольное имя, затем проверьте оба в обоих местах. Публичное имя, которое разрешается, тогда как частное нет, локализует неисправность на частном пути, а не в разрешении имён вообще. Проверка только частного имени не позволит отличить сломанный резолвер от сломанного маршрута.
Внутри гостя посмотрите, для чего резолвер действительно настроен. На госте Ubuntu с systemd-resolved состояние по соединению показывает пришедшие серверы, а файл resolv.conf может содержать только заглушечный адрес, и это правильно, а не подозрительно. Файл, отредактированный вручную, или отдельный клиент зашифрованного DNS может отправлять запросы совсем в другое место. Запишите найденное, прежде чем что-то менять.
resolvectl status
resolvectl query app.internal.exampleЗдесь отделите разрешение от доступности. Адрес, который приходит, пока служба остаётся недоступной, — это вопрос маршрутизации или политики, а не DNS.
Попробуйте режим резолвера хоста на этом адаптере
Параметры NAT DNS в VirtualBox описывают разные механизмы, и разница важна, когда собственный резолвер хоста меняется вместе с туннелем. DNS-прокси пересылает запросы гостя серверам, которые ему передали. Режим резолвера хоста перехватывает запросы и вызывает DNS API хоста, и это тот режим, который следует за резолвером Windows, перенастроенным VPN-клиентом.
Включите неверный механизм, и команда всё равно завершится успешно, а поведение не изменится, что является запутанным способом потерять полдня.
VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 onЗапишите текущие настройки виртуальной машины, выключите её и нацельтесь на адаптер, который вы подтвердили ранее. Последняя цифра в параметре — это номер адаптера, а не константа, поэтому применение его к машине, у которой пострадавший адаптер второй, — тихая операция без эффекта. Запустите гостя и проверьте конфигурацию резолвера, которую он действительно получил, потому что ручная настройка в госте перекрывает всё, что предлагает уровень NAT. Помните, что режим резолвера хоста также предполагает, что собственный DNS-путь хоста — это тот, которым вы хотели поделиться.
Повторите те же тесты при переподключении VPN
Повторите оба запроса в госте, затем откройте настоящее приложение и дайте ему самому проверить сертификат. Тест только по адресу полезен для изоляции разрешения имён и не эквивалентен рабочей сессии TLS, поэтому не останавливайтесь на ping. Затем в согласованное окно отключите и снова подключите туннель хоста и повторите ещё раз. Поведение, которое держится только при первом соединении после загрузки, — это проблема жизненного цикла, о которой нужно сообщить, а не DNS-загадка, за которой стоит гнаться с другим резолвером.
То, что публичное разрешение работает, не доказывает, что частные запросы остались на пути, которого требует ваша политика.
Когда режим резолвера хоста ничего не меняет, верните записанную конфигурацию и сохраните четыре наблюдения: что вернул хост, что вернул гость, режим адаптера и состояние резолвера. Недоступный внутренний сервер, фильтр, исключающий трафик гипервизора и переопределение на стороне гостя требуют каждый своей правки. Превращение адаптера в мост меняет проект сети и не является сбросом DNS.