DNS i VirtualBox NAT-gæsten bryder sammen, når værten går på en VPN

På en Windows-vært opløses det interne applikationsnavn, når VPN'et forbinder, men inde i en Ubuntu-gæst gør det ikke. Gæsten beholder sine egne resolverindstillinger, og NAT-adapteren foran den kan besvare DNS-forespørgsler på to forskellige måder. At pege gæsten mod en offentlig resolver får websteder til at indlæse igen, mens private navne forbliver ødelagte. Derfor spores resolverstien, før noget redigeres.

Følg et opslag gennem NAT-adapteren

Vælg et internt fuldt kvalificeret navn og et offentligt navn som kontrol. Med tunnelen oppe skal du på værten bekræfte, at det interne navn opløses, og at applikationen bag det åbner. Kør derefter de samme to opslag inde i gæsten, og sammenlign svarene i stedet for værktøjerne.

Bekræft, at adapteren virkelig er almindelig NAT, før du går videre. En broadapter, et navngivet NAT-netværk og en anden VPN-klient inde i gæsten har hver deres konfiguration og deres egen forklaring. At gætte på dette tidspunkt spilder resten af undersøgelsen.

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

Den første kommando viser adapterens tilstand og eventuelle NAT-netværk knyttet til den. Inde i en Ubuntu-gæst viser den anden DNS-indstillinger for hvert link, og den tredje afslører ofte kun en lokal stubadresse, hvilket betyder, at den rigtige upstream ligger et andet sted.

Hold opløsning og tilgængelighed adskilt. En gæst, der modtager den korrekte adresse, men ikke kan åbne en forbindelse, har et rute-, filtrerings- eller tjenestetilladelsesproblem, og yderligere DNS-ændringer vil aldrig røre det. Test adressen separat, og skriv ned, hvilken af de to der fejlede.

Proxy-tilstand og værtsresolver-tilstand er forskellige mekanismer

I proxy-tilstand videresender NAT-motoren gæstens forespørgsler til DNS-servere, den allerede kender. I værtsresolver-tilstand opfanger den forespørgslen og beder værtsstyresystemet opløse navnet med det, værten bruger lige nu. Kun den anden følger en VPN-klient, der omskriver værtsopløsningen, når tunnelen kommer op. Derfor giver de to indstillinger forskellige svar på samme maskine.

Den forskel er hele problemet i én sætning. At give gæsten en liste af serveradresser er ikke det samme som at bede Windows opløse et navn gennem sin konfigurerede resolver, og på en VPN med delt DNS er de to svar forskellige. Adapterindstillingen handler om mekanisme, ikke om tilladelse.

Ingen af tilstandene giver adgang til noget. Autorisation ligger i VPN-politikken og i tjenesten, og et fungerende opslag betyder kun, at et navn blev til en adresse.

Skift adapteren, og verificér derefter, hvad gæsten modtager

Notér først VM'ets netværks- og DNS-indstillinger, og luk derefter maskinen ned, så det er den vedvarende konfiguration, du redigerer. For en VM med navnet work-ubuntu, hvis første adapter bærer NAT, sættes indstillingen for hver adapter fra værten, mens VM'en er slukket. Start den igen bagefter, og undersøg resultatet i stedet for at stole på exitstatus.

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

Det sidste ciffer vælger adapternummeret, så det er ikke en universel værdi; en indstilling for adapter 2 ville bære et 2 på den plads. Brug VBoxManage-binæren, der hører til den installerede VirtualBox-version, fordi en ældre i stien kan skrive indstillinger, som den kørende version ignorerer.

At aktivere proxyindstillingen i stedet vælger en anden mekanisme og giver dig ikke værtsresolver-adfærd. Når gæsten er startet, skal du kontrollere den DNS-konfiguration, den faktisk har, da en låst resolver eller en krypteret DNS-indstilling inde i gæsten holder applikationer på en anden vej, uanset hvad adapteren tilbyder.

Test gennem hele VPN'ets livscyklus, ikke kun én gang

Gentag begge opslag i gæsten, og åbn derefter den rigtige applikation, og lad den validere TLS-værtsnavnet. En forbindelsestest med kun IP isolerer DNS fint, men det er ikke en certifikatkontrol og bør ikke rapporteres som en. Notér navnet, adressen og applikationsresultatet sammen.

I et godkendt vindue skal du afbryde og gentilslutte værtens VPN og gentage testen. Resultatet bør matche adgangspolitikken, og at offentlig opløsning virker igen, siger intet om, hvorvidt private forespørgsler blev på den tilsigtede sti.

Når værtsresolver-tilstand ikke ændrer noget, skal du sætte den registrerede værdi tilbage og beholde observationerne. En VPN-klient, der udelukker hypervisor-trafik, en utilgængelig intern resolver og en låst gæsteindstilling kræver hver sin rettelse, og at bro adapteren ændrer netværksdesignet i stedet for at nulstille DNS.