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

Wewnętrzna aplikacja rozwiązuje się na hoście Windows w chwili, gdy VPN się łączy, a gość Ubuntu za NAT VirtualBox nadal jej nie znajduje. Gość ma własny resolver, a adapter NAT może obsługiwać DNS na więcej niż jeden sposób. Zastąpienie resolvera gościa publicznym serwerem sprawia, że zwykłe strony działają, a prywatne nazwy zawodzą, co przenosi problem zamiast go rozwiązywać. Wykonaj cztery kontrole po kolei i zatrzymaj się na pierwszej, która nie zachodzi.

Potwierdź, który tryb adaptera debugujesz

Tylko adapter w zwykłym trybie NAT zachowuje się tak, jak opisuje ten artykuł. Adapter mostkowy siedzi w sieci fizycznej z własną tożsamością, sieć NAT to nazwany przełącznik wirtualny z własnymi ustawieniami DHCP i DNS, a klient VPN wewnątrz gościa dodaje całkiem drugi resolver. Potwierdź tryb, zanim przejdziesz dalej, bo naprawa różni się w każdym z tych przypadków.

Jedna maszyna wirtualna może mieć dwa adaptery w różnych trybach, a dotknięty nie zawsze jest pierwszy.

Potwierdź też, że host w ogóle rozwiązuje nazwę. Otwórz tę samą aplikację na hoście z podniesionym tunelem, używając tej samej w pełni kwalifikowanej nazwy, której użyje gość. Jeśli host też zawodzi, wina nie leży po stronie gościa i żadna zmiana sieci wirtualnej tego nie naprawi.

Prześledź jedną nazwę przez resolver gościa

Wybierz jedną nazwę wewnętrzną i jedną publiczną nazwę kontrolną, a następnie przetestuj obie w obu miejscach. Nazwa publiczna, która się rozwiązuje, gdy prywatna nie, lokalizuje usterkę na ścieżce prywatnej, a nie w rozwiązywaniu nazw w ogóle. Testowanie tylko nazwy prywatnej nie pozwala odróżnić zepsutego resolvera od zepsutej trasy.

Wewnątrz gościa sprawdź, do czego resolver jest naprawdę skonfigurowany. Na gościu Ubuntu z systemd-resolved status na łącze pokazuje serwery, które dotarły, a plik resolv.conf może zawierać tylko adres stub, co jest poprawne, a nie podejrzane. Ręcznie edytowany plik lub osobny klient szyfrowanego DNS może wysyłać zapytania zupełnie gdzie indziej. Zapisz, co znajdziesz, zanim to zmienisz.

resolvectl status
resolvectl query app.internal.example

Oddziel tu rozwiązywanie od osiągalności. Adres, który dociera, gdy usługa pozostaje nieosiągalna, to kwestia trasowania lub polityki, a nie DNS.

Wypróbuj tryb resolvera hosta na tym adapterze

Opcje NAT DNS w VirtualBox opisują różne mechanizmy, a różnica ma znaczenie, gdy własny resolver hosta zmienia się wraz z tunelem. Proxy DNS przekazuje żądania gościa do serwerów, które otrzymał. Tryb resolvera hosta przechwytuje żądania i wywołuje API DNS hosta, i to jest tryb, który podąża za resolverem Windows przeksięgowanym przez klienta VPN.

Włącz niewłaściwy mechanizm, a polecenie nadal się powiedzie, podczas gdy zachowanie się nie zmieni, co jest mylącym sposobem utraty popołudnia.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Zapisz bieżące ustawienia maszyny wirtualnej, wyłącz ją i wyceluj w adapter, który potwierdziłeś wcześniej. Ostatnia cyfra w opcji to numer adaptera, a nie stała, więc zastosowanie jej do maszyny, której dotknięty adapter jest drugi, to cicha operacja bez skutku. Uruchom gościa i sprawdź konfigurację resolvera, którą naprawdę otrzymał, bo ręczne ustawienie w gościu przewyższa wszystko, co oferuje warstwa NAT. Pamiętaj, że tryb resolvera hosta zakłada też, że własna ścieżka DNS hosta jest tą, którą chciałeś udostępnić.

Powtórz te same testy podczas ponownego połączenia VPN

Powtórz oba zapytania w gościu, a potem otwórz prawdziwą aplikację i pozwól jej samej zweryfikować certyfikat. Test oparty tylko na adresie jest przydatny do wyizolowania rozwiązywania nazw i nie jest równoważny działającej sesji TLS, więc nie zatrzymuj się na ping. Następnie w zatwierdzonym oknie odłącz i ponownie podłącz tunel hosta i powtórz jeszcze raz. Zachowanie utrzymujące się tylko przy pierwszym połączeniu po starcie to problem cyklu życia do zgłoszenia, a nie tajemnica DNS do gonienia innym resolverem.

To, że publiczne rozwiązywanie działa, nie dowodzi, że prywatne zapytania pozostały na ścieżce wymaganej przez twoją politykę.

Gdy tryb resolvera hosta niczego nie zmienia, przywróć zapisaną konfigurację i zachowaj cztery obserwacje: co zwrócił host, co zwrócił gość, tryb adaptera i stan resolvera. Nieosiągalny serwer wewnętrzny, filtr wykluczający ruch hiperwizora i nadpisanie po stronie gościa wymagają każdy innej poprawki. Przekształcenie adaptera w mostek zmienia projekt sieci i nie jest resetem DNS.