DNS de la VirtualBox-NAT-gasto rompiĝas post kiam la gastiganto aliĝas al VPN

Sur Windows-gastiganto la interna aplikaĵa nomo solviĝas tuj kiam la VPN konektiĝas, kaj ene de Ubuntu-gasto ĝi ne solviĝas. La gasto konservas siajn proprajn solvilajn agordojn, kaj la NAT-adaptilo antaŭ ĝi povas respondi DNS-demandojn laŭ du malsamaj manieroj. Montri la gaston al publika solvilo denove ŝarĝas retejojn dum privataj nomoj restas rompitaj. Tial la solvila vojo spuriĝas antaŭ ol io ajn estas redaktata.

Spuru unu serĉon tra la NAT-adaptilo

Elektu unu internan plene kvalifikitan nomon kaj unu publikan nomon kiel kontrolon. Kun la tunelo supre, konfirmu sur la gastiganto ke la interna nomo solviĝas kaj ke la aplikaĵo malantaŭ ĝi malfermiĝas. Poste rulu la samajn du serĉojn ene de la gasto kaj komparu la respondojn, ne la ilojn.

Konfirmu ke la adaptilo vere estas ordinara NAT antaŭ ol iri plu. Ponta adaptilo, nomita NAT-reto kaj dua VPN-kliento ene de la gasto ĉiu havas sian propran agordon kaj sian propran klarigon. Diveni ĉi-punkte malŝparas la reston de la esploro.

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

La unua komando montras la adaptilan reĝimon kaj ajnan NAT-reton alligitan al ĝi. Ene de Ubuntu-gasto la du listigas DNS-agordojn laŭ ligilo, kaj la tria ofte malkaŝas nur lokan stub-adreson, kio signifas ke la vera upstream sidas aliloke.

Tenu solvon kaj atingeblon aparte. Gasto kiu ricevas la ĝustan adreson sed ne povas malfermi konekton havas enkursigan, filtradan aŭ servo-permesan problemon, kaj pliaj DNS-ŝanĝoj neniam tuŝos ĝin. Testu la adreson aparte kaj notu kiun el la du malsukcesis.

Prokura reĝimo kaj gastiganta solvilo-reĝimo estas malsamaj mekanismoj

En prokura reĝimo la NAT-motoro plusendas gastajn demandojn al DNS-serviloj kiujn ĝi jam konas. En gastiganta solvilo-reĝimo ĝi interkaptas la demandon kaj petas la gastigantan operaciumon solvi la nomon per tio, kion la gastiganto uzas nun. Nur la dua sekvas VPN-klienton kiu reskribas gastigantan solvon kiam la tunelo ekleviĝas. Tial la du agordoj produktas malsamajn respondojn sur la sama maŝino.

Tiu distingo estas la tuta problemo en unu frazo. Doni al la gasto liston da servilaj adresoj ne samas al peti Windows solvi nomon per sia agordita solvilo, kaj ĉe VPN kun dividita DNS la du respondoj malsamas. La adaptila opcio temas pri mekanismo, ne pri permeso.

Neniu el la reĝimoj donas aliron al io ajn. Rajtigo vivas en la VPN-politiko kaj en la servo, kaj funkcianta serĉo nur signifas ke nomo fariĝis adreso.

Ŝanĝu la adaptilon, poste kontrolu kion la gasto ricevas

Unue notu la retajn kaj DNS-agordojn de la VM, poste malŝaltu la maŝinon por ke la daŭra agordo estu tio, kion vi redaktas. Por VM nomita work-ubuntu kies unua adaptilo portas NAT, la opcio laŭ adaptilo agordiĝas de la gastiganto dum la VM estas malŝaltita. Restartigu ĝin poste kaj inspektu la rezulton anstataŭ fidi la eliran statuson.

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

La fina cifero elektas la adaptilan numeron, do ĝi ne estas universala valoro; agordo por adaptilo 2 portus 2 en tiu pozicio. Uzu la VBoxManage-binarion kiu apartenas al la instalita VirtualBox-versio, ĉar pli malnova en la vojo povas skribi agordojn kiujn la kuranta versio ignoras.

Ebligi la prokuran opcion anstataŭe elektas alian mekanismon kaj ne donas al vi gastigantan solvilan konduton. Post kiam la gasto startas, kontrolu la DNS-agordon kiun ĝi efektive tenas, ĉar fiksita solvilo aŭ ĉifrita-DNS-agordo ene de la gasto tenas aplikaĵojn sur alia vojo sendepende de tio, kion la adaptilo proponas.

Testu tra la tuta VPN-vivociklo, ne nur unufoje

Ripetu ambaŭ serĉojn en la gasto, poste malfermu la veran aplikaĵon kaj lasu ĝin validigi la TLS-gastigantan nomon. Konekta testo nur per IP bone izolas DNS, sed ĝi ne estas atestila kontrolo kaj ne raportindas kiel tia. Notu la nomon, la adreson kaj la aplikaĵan rezulton kune.

Dum aprobita fenestro, malkonektu kaj rekonektu la gastigantan VPN kaj ripetu la teston. La rezulto devus kongrui kun la alirpolitiko, kaj tio ke publika solvo denove funkcias diras nenion pri tio, ĉu privataj demandoj restis sur la celita vojo.

Kiam gastiganta solvilo-reĝimo ŝanĝas nenion, remetu la notitan valoron kaj konservu la observojn. VPN-kliento kiu ekskludas hipervizoran trafikon, malatingebla interna solvilo kaj fiksita gasta agordo ĉiu bezonas malsaman korekton, kaj pontigi la adaptilon ŝanĝas la retan dezajnon anstataŭ restarigi DNS.