DNS gościa VirtualBox NAT psuje się, gdy host dołącza do VPN

Na hoście Windows wewnętrzna nazwa aplikacji jest rozwiązywana, gdy tylko połączy się VPN, a wewnątrz gościa Ubuntu nie. Gość zachowuje własne ustawienia resolvera, a adapter NAT przed nim może odpowiadać na zapytania DNS na dwa różne sposoby. Wskazanie gościa na publiczny resolver ponownie ładuje witryny, ale nazwy prywatne pozostają zepsute. Dlatego ścieżka resolvera jest śledzona, zanim cokolwiek zostanie zmienione.

Prześledź jedno zapytanie przez adapter NAT

Wybierz jedną wewnętrzną nazwę w pełni kwalifikowaną i jedną nazwę publiczną jako kontrolę. Przy podniesionym tunelu potwierdź na hoście, że nazwa wewnętrzna jest rozwiązywana i że aplikacja za nią się otwiera. Następnie uruchom te same dwa zapytania wewnątrz gościa i porównaj odpowiedzi, a nie narzędzia.

Przed kontynuowaniem potwierdź, że adapter to naprawdę zwykły NAT. Adapter mostkowy, nazwana sieć NAT i drugi klient VPN wewnątrz gościa mają każdy własną konfigurację i własne wyjaśnienie. Zgadywanie na tym etapie marnuje resztę dochodzenia.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Pierwsze polecenie pokazuje tryb adaptera i każdą podłączoną do niego sieć NAT. Wewnątrz gościa Ubuntu drugie wylicza ustawienia DNS na połączenie, a trzecie często ujawnia tylko lokalny adres stub, co oznacza, że prawdziwy upstream znajduje się gdzie indziej.

Trzymaj rozwiązywanie i osiągalność osobno. Gość, który otrzymuje poprawny adres, ale nie może otworzyć połączenia, ma problem z routingiem, filtrowaniem lub uprawnieniami usługi, a dalsze zmiany DNS nigdy go nie dotkną. Przetestuj adres osobno i zapisz, która z dwóch rzeczy zawiodła.

Tryb proxy i tryb resolvera hosta to różne mechanizmy

W trybie proxy silnik NAT przekazuje zapytania gościa do serwerów DNS, które już zna. W trybie resolvera hosta przechwytuje zapytanie i prosi system operacyjny hosta o rozwiązanie nazwy tym, czego host używa w tej chwili. Tylko drugi podąża za klientem VPN, który przepisuje rozwiązywanie nazw na hoście, gdy tunel się podnosi. Dlatego dwa ustawienia dają różne odpowiedzi na tej samej maszynie.

Ta różnica to cały problem w jednym zdaniu. Podanie gościowi listy adresów serwerów nie jest tym samym co poproszenie Windows o rozwiązanie nazwy przez jego skonfigurowany resolver, a w VPN z rozdzielonym DNS obie odpowiedzi się różnią. Opcja adaptera dotyczy mechanizmu, a nie uprawnienia.

Żaden tryb nie daje dostępu do czegokolwiek. Autoryzacja żyje w polityce VPN i w usłudze, a działające zapytanie oznacza tylko, że nazwa stała się adresem.

Przełącz adapter, a następnie sprawdź, co otrzymuje gość

Najpierw zanotuj ustawienia sieci i DNS maszyny wirtualnej, potem wyłącz maszynę, aby edytować konfigurację trwałą. Dla maszyny o nazwie work-ubuntu, której pierwszy adapter nosi NAT, opcję na adapter ustawia się z hosta, gdy maszyna jest wyłączona. Uruchom ją ponownie i sprawdź wynik, zamiast ufać kodowi wyjścia.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Ostatnia cyfra wybiera numer adaptera, więc nie jest to wartość uniwersalna; ustawienie dla adaptera 2 niosłoby 2 w tym miejscu. Użyj pliku binarnego VBoxManage należącego do zainstalowanej wersji VirtualBox, ponieważ starszy w ścieżce może zapisać ustawienia, które działająca wersja ignoruje.

Włączenie zamiast tego opcji proxy wybiera inny mechanizm i nie daje zachowania resolvera hosta. Po uruchomieniu gościa sprawdź konfigurację DNS, którą naprawdę trzyma, ponieważ przypięty resolver lub ustawienie szyfrowanego DNS wewnątrz gościa utrzymuje aplikacje na innej ścieżce niezależnie od tego, co oferuje adapter.

Testuj przez cały cykl życia VPN, nie tylko raz

Powtórz oba zapytania w gościu, następnie otwórz prawdziwą aplikację i pozwól jej zweryfikować nazwę hosta TLS. Test połączenia tylko po IP dobrze izoluje DNS, ale nie jest kontrolą certyfikatu i nie powinien być tak zgłaszany. Zapisz nazwę, adres i wynik aplikacji razem.

W zatwierdzonym oknie odłącz i ponownie podłącz VPN hosta i powtórz test. Wynik powinien odpowiadać polityce dostępu, a to, że publiczne rozwiązywanie znów działa, nic nie mówi o tym, czy prywatne zapytania pozostały na zamierzonej ścieżce.

Gdy tryb resolvera hosta niczego nie zmienia, przywróć zapisaną wartość i zachowaj obserwacje. Klient VPN, który wyklucza ruch hypervisora, nieosiągalny wewnętrzny resolver i przypięte ustawienie gościa wymagają każdy innej poprawki, a mostkowanie adaptera zmienia projekt sieci, zamiast resetować DNS.