DNS-en til VirtualBox-gjesten bryter sammen når verten kobler til en VPN

En intern applikasjon slår opp på Windows-verten i det øyeblikket VPN kobler til, og Ubuntu-gjesten bak VirtualBox NAT finner den fortsatt ikke. Gjesten har sin egen resolver, og NAT-adapteren kan håndtere DNS på mer enn én måte. Å erstatte gjestens resolver med en offentlig server får vanlige nettsteder til å virke og private navn til å feile, noe som flytter problemet i stedet for å løse det. Gå gjennom de fire kontrollene i rekkefølge og stopp ved den første som ikke holder.

Bekreft hvilken adaptermodus du feilsøker

Bare en adapter i vanlig NAT-modus oppfører seg slik denne artikkelen beskriver. En broet adapter sitter på det fysiske nettet med sin egen identitet, et NAT-nett er en navngitt virtuell svitsj med egne DHCP- og DNS-innstillinger, og en VPN-klient inne i gjesten legger til en helt annen resolver. Bekreft modusen før du leser videre, fordi reparasjonen er forskjellig i hvert av disse tilfellene.

Én VM kan bære to adaptere i ulike moduser, og den berørte er ikke alltid den første.

Bekreft også at verten i det hele tatt slår opp navnet. Åpne samme applikasjon på verten med tunnelen oppe, og bruk det samme fullt kvalifiserte navnet som gjesten vil bruke. Hvis verten også feiler, er ikke gjesten skylden, og ingen endring av virtuelt nett vil reparere det.

Følg ett navn gjennom gjestens resolver

Velg ett internt navn og ett offentlig kontrollnavn, og test deretter begge begge steder. Et offentlig navn som slår opp mens det private ikke gjør det, lokaliserer feilen til den private stien og ikke til navneoppslag generelt. Tester du bare det private navnet, kan du ikke skille en ødelagt resolver fra en ødelagt rute.

Se inne i gjesten hva resolveren faktisk er konfigurert til å bruke. På en Ubuntu-gjest med systemd-resolved viser statusen per kobling hvilke servere som ankom, og filen resolv.conf kan inneholde bare en stub-adresse, som er riktig og ikke mistenkelig. En håndredigert fil eller en egen klient for kryptert DNS kan sende oppslag helt andre steder. Skriv ned det du finner før du endrer det.

resolvectl status
resolvectl query app.internal.example

Skill oppslag fra tilgjengelighet her. En adresse som ankommer mens tjenesten forblir utilgjengelig, er et ruting- eller policy spørsmål, ikke et DNS-spørsmål.

Prøv vertens resolvermodus på den adapteren

VirtualBox' NAT DNS-alternativer beskriver forskjellige mekanismer, og forskjellen betyr noe når vertens egen resolver endrer seg med tunnelen. DNS-proxyen videresender gjestens forespørsler til servere den har fått. Vertens resolvermodus fanger opp forespørslene og kaller vertens DNS-API, og det er modusen som følger en Windows-resolver som er rekonfigurert av en VPN-klient.

Aktiver den gale mekanismen, og kommandoen lykkes fortsatt mens oppførselen ikke endres, noe som er en forvirrende måte å miste en ettermiddag.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Noter de gjeldende innstillingene til VM-en, slå den av, og mål mot adapteren du bekreftet tidligere. Det siste sifferet i alternativet er et adapternummer og ikke en konstant, så å bruke det på en VM der den berørte adapteren er den andre, er en stille handling uten effekt. Start gjesten og kontroller resolverkonfigurasjonen den faktisk fikk, fordi en manuell innstilling i gjesten overstyrer alt NAT-laget tilbyr. Husk at vertens resolvermodus også forutsetter at vertens egen DNS-sti er den du mente å dele.

Gjenta de samme testene gjennom en VPN-gjenoppkobling

Gjenta begge oppslagene i gjesten, og åpne deretter den ekte applikasjonen og la den validere sertifikatet selv. En test bare på adresse er nyttig for å isolere navneoppslag og er ikke likeverdig med en fungerende TLS-økt, så ikke stopp ved en ping. Koble deretter fra og til vertens tunnel igjen i et godkjent vindu, og gjenta én gang til. Oppførsel som bare holder ved den første forbindelsen etter oppstart, er et livssyklusproblem som skal rapporteres, ikke et DNS-mysterium å jage med en annen resolver.

At offentlig oppslag virker, beviser ikke at private spørringer ble værende på stien retningslinjene dine krever.

Når vertens resolvermodus ikke endrer noe, setter du den registrerte konfigurasjonen tilbake og beholder de fire observasjonene: hva verten returnerte, hva gjesten returnerte, adaptermodusen og resolverens tilstand. En utilgjengelig intern server, et filter som utelukker hypervisor-trafikk og en overstyring på gjestesiden trenger hver sin rettelse. Å konvertere adapteren til en bro endrer nettverksdesignet og er ikke en DNS-tilbakestilling.