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 по връзки, а третата често разкрива само локален адрес-заглушка, което значи, че истинският upstream е другаде.

Дръжте разрешаването и достъпността отделно. Гост, който получава правилния адрес, но не може да отвори връзка, има проблем с маршрутизиране, филтриране или права на услугата и по-нататъшни промени в DNS никога няма да го засегнат. Тествайте адреса отделно и запишете кое от двете се е провалило.

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

В режим прокси NAT машината препраща заявките на госта към DNS сървъри, които вече познава. В режим на резолвера на хоста тя прихваща заявката и иска от операционната система на хоста да разреши името с каквото хостът използва в момента. Само вторият следва VPN клиент, който пренаписва разрешаването на хоста при вдигане на тунела. Затова двете настройки дават различни отговори на една и съща машина.

Тази разлика е целият проблем в едно изречение. Да дадете на госта списък със сървърни адреси не е същото като да помолите Windows да разреши име през конфигурирания си резолвер, а при VPN с разделен DNS двата отговора се различават. Опцията на адаптера е за механизъм, не за разрешение.

Нито един от режимите не дава достъп до каквото и да е. Оторизацията живее в политиката за VPN и в услугата, а работеща заявка значи само, че име се е превърнало в адрес.

Сменете адаптера, после проверете какво получава гостът

Първо запишете мрежовите и DNS настройки на VM, после изключете машината, за да редактирате постоянната конфигурация. За VM с име work-ubuntu, чийто първи адаптер носи NAT, опцията за конкретен адаптер се задава от хоста, докато VM е изключена. След това я стартирайте отново и прегледайте резултата, вместо да вярвате на кода за изход.

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.