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

Interna aplikaĵo solviĝas sur la Windows-gastiganto en la momento kiam la VPN konektiĝas, kaj la Ubuntu-gasto malantaŭ la NAT de VirtualBox ankoraŭ ne povas trovi ĝin. La gasto havas propran solvilon, kaj la NAT-adaptilo povas pritrakti DNS per pli ol unu maniero. Anstataŭigi la solvilon de la gasto per publika servilo igas ordinarajn retejojn funkcii kaj privatajn nomojn malsukcesi, kio direktas la problemon aliloken anstataŭ solvi ĝin. Trairu la kvar kontrolojn laŭvice kaj haltu ĉe la unua, kiu ne validas.

Konfirmu, kiun adaptilan reĝimon vi sencimigas

Nur adaptilo en ordinara reĝimo NAT kondutas tiel, kiel priskribas ĉi tiu artikolo. Ponta adaptilo sidas sur la fizika reto kun propra identeco, NAT-reto estas nomita virtuala ŝaltilo kun propraj agordoj de DHCP kaj DNS, kaj VPN-kliento ene de la gasto aldonas tute duan solvilon. Konfirmu la reĝimon antaŭ ol legi plu, ĉar la riparo malsamas en ĉiu el tiuj kazoj.

Unu virtuala maŝino povas porti du adaptilojn en malsamaj reĝimoj, kaj la trafita ne ĉiam estas la unua.

Konfirmu ankaŭ, ke la gastiganto entute solvas la nomon. Malfermu la saman aplikaĵon sur la gastiganto kun la tunelo levita, uzante la saman plene kvalifikitan nomon, kiun uzos la gasto. Se ankaŭ la gastiganto malsukcesas, la gasto ne kulpas kaj neniu ŝanĝo de la virtuala reto riparos ĝin.

Sekvu unu nomon tra la solvilo de la gasto

Elektu unu internan nomon kaj unu publikan kontrolnomon, poste provu ambaŭ en ambaŭ lokoj. Publika nomo, kiu solviĝas dum la privata ne, lokigas la kulpon sur la privatan vojon anstataŭ sur la nomosolvadon ĝenerale. Provi nur la privatan nomon lasas vin nekapabla distingi rompitan solvilon de rompita vojo.

Ene de la gasto, rigardu, por kio la solvilo fakte agordiĝis. Sur Ubuntu-gasto kun systemd-resolved, la stato laŭligila montras la servilojn, kiuj alvenis, kaj la dosiero resolv.conf povas enhavi nenion krom stub-adreso, kio estas ĝusta kaj ne suspektinda. Mane redaktita dosiero aŭ aparta kliento por ĉifrita DNS povas sendi serĉojn tute aliloken. Notu, kion vi trovas, antaŭ ol ŝanĝi tion.

resolvectl status
resolvectl query app.internal.example

Apartigu ĉi tie solvadon de atingeblo. Adreso, kiu alvenas dum la servo restas neatingebla, estas demando pri enkursigo aŭ politiko, ne pri DNS.

Provu la gastigantan solvilan reĝimon sur tiu adaptilo

La NAT-DNS-opcioj de VirtualBox priskribas malsamajn meĥanismojn, kaj la diferenco gravas, kiam la propra solvilo de la gastiganto ŝanĝiĝas kun la tunelo. La DNS-prokurilo plusendas petojn de la gasto al serviloj, kiujn ĝi ricevis. La gastiganta solvila reĝimo kaptas la petojn kaj vokas la DNS-API de la gastiganto, kaj tio estas la reĝimo, kiu sekvas Windows-solvilon reagorditan de VPN-kliento.

Ŝaltu la malĝustan meĥanismon kaj la komando tamen sukcesos, dum la konduto ne ŝanĝiĝos, kio estas konfuza maniero perdi posttagmezon.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Notu la nunajn agordojn de la virtuala maŝino, malŝaltu ĝin, kaj celi la adaptilon, kiun vi konfirmis pli frue. La fina cifero en la opcio estas adaptila numero, ne konstanto, do apliki ĝin al maŝino, kies trafita adaptilo estas la dua, estas silenta senefika ago. Startigu la gaston kaj kontrolu la solvilan agordon, kiun ĝi fakte ricevis, ĉar mana agordo en la gasto superas ĉion, kion proponas la NAT-tavolo. Memoru, ke la gastiganta solvila reĝimo ankaŭ supozas, ke la propra DNS-vojo de la gastiganto estas tiu, kiun vi intencis kunhavigi.

Ripetu la samajn testojn dum VPN-rekonekto

Ripetu ambaŭ serĉojn en la gasto, poste malfermu la veran aplikaĵon kaj lasu ĝin mem validigi la atestilon. Testo nur laŭ adreso utilas por izoli nomosolvadon kaj ne egalas al funkcianta TLS-sesio, do ne haltu ĉe ping. Poste, en aprobita fenestro, malkonektu kaj rekonektu la tunelon de la gastiganto kaj ripetu ankoraŭfoje. Konduto, kiu teniĝas nur ĉe la unua konekto post la starto, estas vivcikla problemo raportenda, ne DNS-mistero postkurinda per alia solvilo.

Tio, ke publika solvado funkcias, ne pruvas, ke privataj demandoj restis sur la vojo, kiun postulas via politiko.

Kiam la gastiganta solvila reĝimo ŝanĝas nenion, remetu la notitan agordon kaj konservu la kvar observojn: kion redonis la gastiganto, kion redonis la gasto, la adaptilan reĝimon kaj la solvilan staton. Neatingebla interna servilo, filtrilo, kiu ekskludas trafikon de la hipervidilo kaj superregado ĉe la flanko de la gasto bezonas ĉiu alian korekton. Konverti la adaptilon al ponto ŝanĝas la retan dezajnon kaj ne estas DNS-restarigo.