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 на хоста, а това е режимът, който следва преконфигуриран от VPN клиент Windows резолвер.

Включете грешния механизъм и командата все още успява, докато поведението не се променя, което е объркващ начин да загубите следобеда.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

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

Повторете същите тестове при повторно свързване на VPN

Повторете двете търсения в госта, след което отворете истинското приложение и го оставете само да провери сертификата. Тест само по адрес е полезен за изолиране на разрешаването на имена и не е равносилен на работеща TLS сесия, така че не спирайте на ping. След това, в одобрен прозорец, прекъснете и свържете отново тунела на хоста и повторете още веднъж. Поведение, което се задържа само при първата връзка след зареждане, е проблем на жизнения цикъл за докладване, а не DNS мистерия за гонене с друг резолвер.

Работещото публично разрешаване не доказва, че частните заявки са останали по пътя, който изисква вашата политика.

Когато режимът на резолвера на хоста не променя нищо, върнете записаната конфигурация и запазете четирите наблюдения: какво е върнал хостът, какво е върнал гостът, режимът на адаптера и състоянието на резолвера. Недостъпен вътрешен сървър, филтър, който изключва трафика на хипервизора и настройка от страна на госта всяко от тях изисква различна корекция. Превръщането на адаптера в мост променя мрежовия дизайн и не е нулиране на DNS.