DNS för VirtualBox NAT-gästen bryts när värden ansluter till ett VPN

På en Windows-värd löses det interna applikationsnamnet så snart VPN:t ansluter, men i en Ubuntu-gäst inte. Gästen behåller sina egna resolverinställningar, och NAT-adaptern framför kan svara på DNS-frågor på två olika sätt. Att peka gästen mot en offentlig resolver får webbplatser att laddas igen, medan privata namn förblir trasiga. Därför spåras resolvervägen innan något redigeras.

Följ en uppslagning genom NAT-adaptern

Välj ett internt fullt kvalificerat namn och ett offentligt namn som kontroll. Med tunneln uppe, bekräfta på värden att det interna namnet löses och att applikationen bakom öppnas. Kör sedan samma två uppslagningar inuti gästen och jämför svaren, inte verktygen.

Bekräfta att adaptern verkligen är vanlig NAT innan du går vidare. En bryggadapter, ett namngivet NAT-nätverk och en andra VPN-klient inuti gästen har var sin konfiguration och sin egen förklaring. Att gissa här slösar bort resten av utredningen.

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

Det första kommandot visar adapterns läge och eventuella NAT-nätverk kopplade till den. I en Ubuntu-gäst listar det andra DNS-inställningar per länk, och det tredje avslöjar ofta bara en lokal stubadress, vilket betyder att den riktiga upstreamen finns någon annanstans.

Håll uppslagning och nåbarhet åtskilda. En gäst som får rätt adress men inte kan öppna en anslutning har ett routing-, filtrerings- eller tjänstbehörighetsproblem, och ytterligare DNS-ändringar kommer aldrig att röra det. Testa adressen separat och skriv ner vilken av de två som misslyckades.

Proxy-läge och värdens resolverläge är olika mekanismer

I proxy-läge vidarebefordrar NAT-motorn gästens frågor till DNS-servrar som den redan känner till. I värdens resolverläge fångar den upp frågan och ber värdens operativsystem lösa namnet med det värden använder just nu. Bara den andra följer en VPN-klient som skriver om värdens uppslagning när tunneln kommer upp. Därför ger de två inställningarna olika svar på samma maskin.

Den skillnaden är hela problemet i en mening. Att ge gästen en lista med serveradresser är inte samma sak som att be Windows lösa ett namn via sin konfigurerade resolver, och på ett VPN med delad DNS skiljer sig de två svaren. Adapteralternativet handlar om mekanism, inte om tillstånd.

Inget av lägena ger åtkomst till något. Auktoriseringen lever i VPN-policyn och i tjänsten, och en fungerande uppslagning betyder bara att ett namn blev en adress.

Byt adapter och verifiera sedan vad gästen tar emot

Anteckna först VM:ens nätverks- och DNS-inställningar och stäng sedan av maskinen så att det är den beständiga konfigurationen du redigerar. För en VM som heter work-ubuntu där den första adaptern bär NAT ställs alternativet per adapter in från värden medan VM:en är avstängd. Starta den igen efteråt och granska resultatet i stället för att lita på slutstatusen.

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

Den sista siffran väljer adapternumret, så det är inte ett universellt värde; en inställning för adapter 2 skulle bära en 2 på den platsen. Använd VBoxManage-binärfilen som hör till den installerade VirtualBox-versionen, eftersom en äldre i sökvägen kan skriva inställningar som den körande versionen ignorerar.

Att i stället aktivera proxyalternativet väljer en annan mekanism och ger dig inte värdens resolverbeteende. När gästen har startat, kontrollera den DNS-konfiguration den faktiskt har, eftersom en fäst resolver eller en krypterad DNS-inställning inuti gästen håller applikationer på en annan väg oavsett vad adaptern erbjuder.

Testa under hela VPN:ets livscykel, inte bara en gång

Upprepa båda uppslagningarna i gästen, öppna sedan den riktiga applikationen och låt den validera TLS-värdnamnet. Ett anslutningstest med bara IP isolerar DNS bra, men det är inte en certifikatkontroll och bör inte rapporteras som en. Anteckna namnet, adressen och applikationsresultatet tillsammans.

Under ett godkänt fönster, koppla från och återanslut värdens VPN och upprepa testet. Resultatet bör stämma med åtkomstpolicyn, och att offentlig uppslagning fungerar igen säger ingenting om huruvida privata frågor stannade på den avsedda vägen.

När värdens resolverläge inte ändrar något, sätt tillbaka det registrerade värdet och behåll observationerna. En VPN-klient som utesluter hypervisor-trafik, en onåbar intern resolver och en fäst gästinställning kräver var sin rättelse, och att brygga adaptern ändrar nätverksdesignen i stället för att återställa DNS.