DNS:en i VirtualBox-gästen går sönder när värden ansluter till en VPN

Ett internt program löses upp på Windows-värden i samma ögonblick som VPN:et ansluter, och Ubuntu-gästen bakom VirtualBox NAT hittar det fortfarande inte. Gästen har en egen resolver, och NAT-adaptern kan hantera DNS på mer än ett sätt. Att byta ut gästens resolver mot en offentlig server får vanliga webbplatser att fungera och privata namn att misslyckas, vilket flyttar problemet i stället för att lösa det. Arbeta igenom de fyra kontrollerna i ordning och stanna vid den första som inte håller.

Bekräfta vilket adapterläge du felsöker

Bara en adapter i vanligt NAT-läge beter sig som den här artikeln beskriver. En bryggad adapter sitter på det fysiska nätet med egen identitet, ett NAT-nät är en namngiven virtuell switch med egna DHCP- och DNS-inställningar, och en VPN-klient inne i gästen lägger till en helt annan resolver. Bekräfta läget innan du läser vidare, eftersom reparationen skiljer sig i vart och ett av dessa fall.

En virtuell maskin kan bära två adaptrar i olika lägen, och den drabbade är inte alltid den första.

Bekräfta också att värden alls löser upp namnet. Öppna samma program på värden med tunneln uppe och använd samma fullständigt kvalificerade namn som gästen kommer att använda. Om värden också misslyckas är gästen inte orsaken och ingen ändring av det virtuella nätet reparerar det.

Följ ett namn genom gästens resolver

Välj ett internt namn och ett offentligt kontrollnamn och testa sedan båda på båda ställena. Ett offentligt namn som löses upp medan det privata inte gör det lokaliserar felet till den privata vägen och inte till namnmatchning i allmänhet. Att bara testa det privata namnet gör att du inte kan skilja en trasig resolver från en trasig rutt.

Inne i gästen, titta på vad resolvern faktiskt är inställd på att använda. På en Ubuntu-gäst med systemd-resolved visar statusen per länk vilka servrar som anlänt, och filen resolv.conf kan innehålla bara en stub-adress, vilket är korrekt och inte misstänkt. En handredigerad fil eller en separat klient för krypterad DNS kan skicka uppslag helt någon annanstans. Skriv ner vad du hittar innan du ändrar något.

resolvectl status
resolvectl query app.internal.example

Skilj uppslag från nåbarhet här. En adress som anländer medan tjänsten förblir onåbar är en routing- eller policyfråga, inte en DNS-fråga.

Prova värdens resolverläge på den adaptern

VirtualBox NAT DNS-alternativ beskriver olika mekanismer, och skillnaden spelar roll när värdens egen resolver ändras med tunneln. DNS-proxyn vidarebefordrar gästens förfrågningar till servrar den har fått. Värdens resolverläge fångar upp förfrågningarna och anropar värdens DNS-API, och det är det läge som följer en Windows-resolver som konfigurerats om av en VPN-klient.

Aktivera fel mekanism och kommandot lyckas ändå medan beteendet inte ändras, vilket är ett förvirrande sätt att förlora en eftermiddag.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Anteckna den virtuella maskinens nuvarande inställningar, stäng av den och rikta in dig på adaptern du bekräftade tidigare. Den sista siffran i alternativet är ett adapternummer och inte en konstant, så att tillämpa det på en maskin vars drabbade adapter är den andra är en tyst operation utan effekt. Starta gästen och kontrollera den resolverkonfiguration som den faktiskt fick, eftersom en manuell inställning i gästen åsidosätter allt som NAT-lagret erbjuder. Kom ihåg att värdens resolverläge också förutsätter att värdens egen DNS-väg är den du menade att dela.

Upprepa samma tester under en VPN-återanslutning

Upprepa båda uppslagen i gästen, öppna sedan det riktiga programmet och låt det validera certifikatet själv. Ett test enbart på adress är användbart för att isolera namnmatchning och motsvarar inte en fungerande TLS-session, så stanna inte vid en ping. Koppla sedan från och till värdens tunnel igen i ett godkänt fönster och upprepa en gång till. Ett beteende som bara håller vid den första anslutningen efter start är ett livscykelproblem att rapportera, inte ett DNS-mysterium att jaga med en annan resolver.

Att offentlig uppslagning fungerar bevisar inte att privata frågor stannade på den väg din policy kräver.

När värdens resolverläge inte ändrar något, sätt tillbaka den antecknade konfigurationen och behåll de fyra observationerna: vad värden returnerade, vad gästen returnerade, adapterläget och resolverens tillstånd. En onåbar intern server, ett filter som utesluter hypervisor-trafik och en åsidosättning på gästsidan behöver var sin åtgärd. Att göra om adaptern till en brygga ändrar nätverksdesignen och är inte en DNS-återställning.