VirtualBox-gæstens DNS går i stykker, når værten kobler på en VPN

En intern applikation slår op på Windows-værten i samme øjeblik, VPN'et forbinder, og Ubuntu-gæsten bag VirtualBox NAT kan stadig ikke finde den. Gæsten har sin egen resolver, og NAT-adapteren kan håndtere DNS på mere end én måde. At erstatte gæstens resolver med en offentlig server får almindelige websteder til at virke og private navne til at fejle, hvilket flytter problemet i stedet for at løse det. Tag de fire kontroller i rækkefølge og stop ved den første, der ikke holder.

Bekræft, hvilken adaptertilstand du fejlretter

Kun en adapter i almindelig NAT-tilstand opfører sig, som denne artikel beskriver. En broet adapter sidder på det fysiske netværk med sin egen identitet, et NAT-netværk er en navngivet virtuel switch med sine egne DHCP- og DNS-indstillinger, og en VPN-klient inde i gæsten tilføjer en helt anden resolver. Bekræft tilstanden, før du læser videre, fordi reparationen er forskellig i hvert af disse tilfælde.

Én VM kan bære to adaptere i forskellige tilstande, og den påvirkede er ikke altid den første.

Bekræft også, at værten overhovedet slår navnet op. Åbn samme applikation på værten med tunnelen oppe, og brug det samme fuldt kvalificerede navn, som gæsten vil bruge. Hvis værten også fejler, er gæsten ikke skylden, og ingen ændring af virtuelt netværk vil reparere det.

Følg ét navn gennem gæstens resolver

Vælg ét internt navn og ét offentligt kontrolnavn, og test derefter begge begge steder. Et offentligt navn, der slår op, mens det private ikke gør, lokaliserer fejlen til den private sti frem for til navneopslag generelt. Tester du kun det private navn, kan du ikke skelne en ødelagt resolver fra en ødelagt rute.

Se inde i gæsten, hvad resolveren faktisk er konfigureret til at bruge. På en Ubuntu-gæst med systemd-resolved vis status per link de servere, der er ankommet, og filen resolv.conf kan indeholde intet andet end en stub-adresse, hvilket er korrekt og ikke mistænkeligt. En håndredigeret fil eller en separat krypteret DNS-klient kan sende opslag helt andre steder hen. Skriv ned, hvad du finder, før du ændrer det.

resolvectl status
resolvectl query app.internal.example

Adskil opslag fra tilgængelighed her. En adresse, der ankommer, mens tjenesten forbliver utilgængelig, er et routing- eller politikspørgsmål, ikke et DNS-spørgsmål.

Prøv værtsresolvertilstand på den adapter

VirtualBox' NAT DNS-indstillinger beskriver forskellige mekanismer, og forskellen betyder noget, når værtens egen resolver ændrer sig med tunnelen. DNS-proxyen videresender gæstens anmodninger til servere, den har fået. Værtsresolvertilstand opfanger anmodningerne og kalder værtens DNS-API, og det er den tilstand, der følger en Windows-resolver, som er omkonfigureret af en VPN-klient.

Aktiver den forkerte mekanisme, og kommandoen lykkes stadig, mens adfærden ikke ændrer sig, hvilket er en forvirrende måde at miste en eftermiddag.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Noter VM'ets nuværende indstillinger, luk den ned, og målret den adapter, du bekræftede tidligere. Det sidste ciffer i indstillingen er et adapternummer og ikke en konstant, så at anvende den på en VM, hvis påvirkede adapter er den anden, er en stille handling uden effekt. Start gæsten, og kontroller den resolverkonfiguration, den faktisk modtog, fordi en manuel indstilling i gæsten tilsidesætter alt, hvad NAT-laget tilbyder. Husk, at værtsresolvertilstand også forudsætter, at værtens egen DNS-sti er den, du mente at dele.

Gentag de samme tests hen over en VPN-genopkobling

Gentag begge opslag i gæsten, åbn derefter den rigtige applikation, og lad den selv validere certifikatet. En test, der kun bruger adresser, er nyttig til at isolere navneopslag og svarer ikke til en fungerende TLS-session, så stop ikke ved en ping. Afbryd og genopret derefter værtens tunnel i et godkendt vindue, og gentag én gang mere. Adfærd, der kun holder ved den første forbindelse efter opstart, er et livscyklusproblem, der skal rapporteres, ikke et DNS-mysterium, der skal jagtes med en anden resolver.

At offentligt opslag virker beviser ikke, at private forespørgsler blev på den sti, din politik kræver.

Når værtsresolvertilstand ikke ændrer noget, skal du føre den registrerede konfiguration tilbage og beholde de fire observationer: hvad værten returnerede, hvad gæsten returnerede, adaptertilstanden og resolverens tilstand. En utilgængelig intern server, et filter, der udelukker hypervisor-trafik og en tilsidesættelse på gæstesiden kræver hver sin rettelse. At konvertere adapteren til en bro ændrer netværksdesignet og er ikke en DNS-nulstilling.