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.