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

På en Windows-vert løses det interne applikasjonsnavnet når VPN-en kobler til, men inne i en Ubuntu-gjest gjør det ikke. Gjesten beholder sine egne resolverinnstillinger, og NAT-adapteren foran den kan svare på DNS-spørringer på to forskjellige måter. Å peke gjesten mot en offentlig resolver får nettsteder til å laste igjen, mens private navn forblir ødelagte. Derfor spores resolverbanen før noe redigeres.

Følg ett oppslag gjennom NAT-adapteren

Velg ett internt fullt kvalifisert navn og ett offentlig navn som kontroll. Med tunnelen oppe, bekreft på verten at det interne navnet løses og at applikasjonen bak åpnes. Kjør deretter de samme to oppslagene inne i gjesten og sammenlign svarene, ikke verktøyene.

Bekreft at adapteren virkelig er vanlig NAT før du går videre. En broadapter, et navngitt NAT-nettverk og en annen VPN-klient inne i gjesten har hver sin konfigurasjon og sin egen forklaring. Å gjette på dette punktet sløser bort resten av undersøkelsen.

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

Den første kommandoen viser adaptermodusen og eventuelle NAT-nettverk knyttet til den. Inne i en Ubuntu-gjest viser den andre DNS-innstillinger per lenke, og den tredje avslører ofte bare en lokal stubadresse, noe som betyr at den ekte upstreamen ligger et annet sted.

Hold oppslag og tilgjengelighet fra hverandre. En gjest som mottar riktig adresse men ikke kan åpne en forbindelse, har et ruting-, filtrerings- eller tjenestetillatelsesproblem, og flere DNS-endringer vil aldri berøre det. Test adressen separat og skriv ned hvilken av de to som feilet.

Proxy-modus og vertsresolver-modus er forskjellige mekanismer

I proxy-modus videresender NAT-motoren gjestens spørringer til DNS-servere den allerede kjenner. I vertsresolver-modus fanger den opp spørringen og ber vertens operativsystem løse navnet med det verten bruker akkurat nå. Bare den andre følger en VPN-klient som skriver om vertsoppslaget når tunnelen kommer opp. Derfor gir de to innstillingene forskjellige svar på samme maskin.

Den forskjellen er hele problemet i én setning. Å gi gjesten en liste med serveradresser er ikke det samme som å be Windows løse et navn gjennom sin konfigurerte resolver, og på en VPN med delt DNS er de to svarene forskjellige. Adaptervalget handler om mekanisme, ikke om tillatelse.

Ingen av modusene gir tilgang til noe. Autorisasjon ligger i VPN-policyen og i tjenesten, og et fungerende oppslag betyr bare at et navn ble en adresse.

Bytt adapter, og verifiser deretter hva gjesten mottar

Noter først nettverks- og DNS-innstillingene til VM-en, og slå deretter av maskinen slik at det er den vedvarende konfigurasjonen du redigerer. For en VM kalt work-ubuntu der den første adapteren har NAT, settes innstillingen per adapter fra verten mens VM-en er av. Start den igjen etterpå og undersøk resultatet i stedet for å stole på utgangsstatusen.

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

Det siste sifferet velger adapternummeret, så det er ikke en universell verdi; en innstilling for adapter 2 ville bære et 2 på den plassen. Bruk VBoxManage-binæren som hører til den installerte VirtualBox-versjonen, fordi en eldre i banen kan skrive innstillinger som den kjørende versjonen ignorerer.

Å aktivere proxy-valget i stedet velger en annen mekanisme og gir deg ikke vertsresolveratferd. Etter at gjesten starter, kontroller DNS-konfigurasjonen den faktisk har, siden en festet resolver eller en kryptert DNS-innstilling inne i gjesten holder applikasjoner på en annen bane uansett hva adapteren tilbyr.

Test gjennom hele VPN-ens livssyklus, ikke bare én gang

Gjenta begge oppslagene i gjesten, åpne deretter den ekte applikasjonen og la den validere TLS-vertsnavnet. En tilkoblingstest med bare IP isolerer DNS godt, men det er ikke en sertifikatkontroll og bør ikke rapporteres som en. Noter navnet, adressen og applikasjonsresultatet sammen.

I et godkjent vindu, koble fra og tilbake til vertens VPN og gjenta testen. Resultatet bør samsvare med tilgangspolicyen, og at offentlig oppslag virker igjen sier ingenting om hvorvidt private spørringer ble værende på den tiltenkte banen.

Når vertsresolver-modus ikke endrer noe, sett den registrerte verdien tilbake og behold observasjonene. En VPN-klient som utelukker hypervisor-trafikk, en utilgjengelig intern resolver og en festet gjesteinnstilling trenger hver sin rettelse, og å bro adapteren endrer nettverksdesignet i stedet for å nullstille DNS.