DNS гостьової системи VirtualBox ламається, коли хост підключається до 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.