DNS-en til VirtualBox-gjesten bryt saman når verten koplar til ein VPN

Ein intern applikasjon slår opp på Windows-verten i det augneblunken VPN koplar til, og Ubuntu-gjesten bak VirtualBox NAT finn han framleis ikkje. Gjesten har sin eigen resolver, og NAT-adapteren kan handsame DNS på meir enn éin måte. Å byta ut resolveren til gjesten med ein offentleg tenar får vanlege nettstadar til å verke og private namn til å feila, noko som flyttar problemet i staden for å løyse det. Gå gjennom dei fire kontrollane i rekkjefølgje og stopp ved den første som ikkje held.

Stadfest kva adaptermodus du feilsøkjer

Berre ein adapter i vanleg NAT-modus oppfører seg slik denne artikkelen skildrar. Ein briggja adapter sit på det fysiske nettet med sin eigen identitet, eit NAT-nett er ein namngjeven virtuell svitsj med eigne DHCP- og DNS-innstillingar, og ein VPN-klient inne i gjesten legg til ein heilt annan resolver. Stadfest modusen før du les vidare, fordi reparasjonen er ulik i kvart av desse tilfella.

Éin VM kan bera to adapterar i ulike modusar, og den råka er ikkje alltid den første.

Stadfest òg at verten i det heile slår opp namnet. Opne same applikasjon på verten med tunnelen oppe, og bruk det same fullt kvalifiserte namnet som gjesten vil bruke. Viss verten òg feilar, er ikkje gjesten skulda, og inga endring av virtuelt nett vil reparere det.

Følg eitt namn gjennom resolveren til gjesten

Vel eitt internt namn og eitt offentleg kontrollnamn, og test deretter begge begge stader. Eit offentleg namn som slår opp medan det private ikkje gjer det, lokaliserer feilen til den private stien og ikkje til namneoppslag generelt. Testar du berre det private namnet, kan du ikkje skilje ein øydelagd resolver frå ein øydelagd rute.

Sjå inne i gjesten kva resolveren faktisk er konfigurert til å bruke. På ein Ubuntu-gjest med systemd-resolved viser statusen per kopling kva tenarar som kom inn, og fila resolv.conf kan innehalde berre ei stub-adresse, som er rett og ikkje mistenkeleg. Ei handredigert fil eller ein eigen klient for kryptert DNS kan senda oppslag heilt andre stader. Skriv ned det du finn før du endrar det.

resolvectl status
resolvectl query app.internal.example

Skil oppslag frå tilgjenge her. Ei adresse som kjem inn medan tenesta blir utilgjengeleg, er eit rutings- eller policyspørsmål, ikkje eit DNS-spørsmål.

Prøv resolvermodusen til verten på den adapteren

NAT DNS-alternativa i VirtualBox skildrar ulike mekanismar, og skillnaden tel når den eigenlege resolveren til verten endrar seg med tunnelen. DNS-proxyen sender førespurnadene til gjesten vidare til tenarar han har fått. Resolvermodusen til verten fangar opp førespurnadene og kallar DNS-API-et til verten, og det er modusen som følgjer ein Windows-resolver som er rekonfigurert av ein VPN-klient.

Aktiver den gale mekanismen, og kommandoen lukkast framleis medan åtferda ikkje endrar seg, noko som er ein forvirrande måte å miste ein ettermiddag.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Noter dei gjeldande innstillingane til VM-en, slå han av, og mål mot adapteren du stadfesta tidlegare. Det siste sifferet i alternativet er eit adapternummer og ikkje ein konstant, så å bruke det på ein VM der den råka adapteren er den andre, er ei stille handling utan verknad. Start gjesten og kontroller resolverkonfigurasjonen han faktisk fekk, fordi ei manuell innstilling i gjesten overstyrer alt NAT-laget byr på. Hugs at resolvermodusen til verten òg føreset at den eigenlege DNS-stien til verten er den du meinte å dele.

Gjenta dei same testane gjennom ei VPN-atilkopling

Gjenta begge oppslaga i gjesten, og opne deretter den ekte applikasjonen og la han validere sertifikatet sjølv. Ein test berre på adresse er nyttig for å isolere namneoppslag og er ikkje jamgod med ein fungerande TLS-økt, så ikkje stopp ved ein ping. Kopla deretter frå og til tunnelen til verten att i eit godkjent vindauge, og gjenta ein gong til. Åtferd som berre held ved den første koplinga etter oppstart, er eit livssyklusproblem som skal rapporterast, ikkje eit DNS-mysterium å jage med ein annan resolver.

At offentleg oppslag verkar, beviser ikkje at private spørjingar vart verande på stien retningslinjene dine krev.

Når resolvermodusen til verten ikkje endrar noko, set du den registrerte konfigurasjonen tilbake og held på dei fire observasjonane: kva verten returnerte, kva gjesten returnerte, adaptermodusen og tilstanden til resolveren. Ein utilgjengeleg intern tenar, eit filter som utelukkar hypervisor-trafikk og ei overstyring på gjestesida treng kvar si retting. Å konvertere adapteren til ei bru endrar nettverksdesignet og er ikkje ei DNS-tilbakestilling.