Nasira ang DNS ng guest ng VirtualBox kapag sumali ang host sa isang VPN

Nalulutas ang isang panloob na aplikasyon sa host na Windows sa sandaling kumonekta ang VPN, at hindi pa rin ito mahanap ng guest na Ubuntu sa likod ng NAT ng VirtualBox. May sariling resolver ang guest, at kayang hawakan ng adapter ng NAT ang DNS sa higit sa isang paraan. Ang palitan ang resolver ng guest ng pampublikong server ay nagpapagana sa mga ordinaryong website at nagpapabagsak sa mga pribadong pangalan, na naglilipat ng problema sa halip na lutasin ito. Gawin ang apat na pagsusuri nang sunod-sunod at huminto sa una na hindi tumutugma.

Tiyakin kung aling mode ng adapter ang ini-debug mo

Tanging adapter sa payak na mode na NAT ang kumikilos ayon sa inilalarawan ng artikulong ito. Ang bridge adapter ay nakaupo sa pisikal na network na may sariling pagkakakilanlan, ang NAT network ay isang pinangalanang virtual switch na may sariling mga setting ng DHCP at DNS, at ang VPN client sa loob ng guest ay nagdadagdag ng ganap na ikalawang resolver. Tiyakin ang mode bago magpatuloy sa pagbabasa, dahil iba ang pag-aayos sa bawat isa sa mga kasong iyon.

Maaaring magdala ang isang VM ng dalawang adapter sa magkaibang mode, at ang apektado ay hindi laging una.

Tiyakin din na nalulutas ng host ang pangalan. Buksan ang parehong aplikasyon sa host habang nakataas ang tunnel, gamit ang parehong buong kwalipikadong pangalan na gagamitin ng guest. Kung nabigo rin ang host, hindi ang guest ang may kasalanan at walang pagbabago sa virtual networking ang makakaayos nito.

Sundan ang isang pangalan sa resolver ng guest

Pumili ng isang panloob na pangalan at isang pampublikong pangalan ng kontrol, pagkatapos subukan ang dalawa sa dalawang lugar. Ang pampublikong pangalan na nalulutas habang ang pribado ay hindi ay naglalagay ng depekto sa pribadong landas at hindi sa paglutas ng pangalan sa pangkalahatan. Ang pagsubok lamang sa pribadong pangalan ay hindi ka makakapagpaiba ng sirang resolver sa sirang ruta.

Sa loob ng guest, tingnan kung para saan talaga naka-configure ang resolver. Sa guest na Ubuntu na nagpapatakbo ng systemd-resolved, ipinapakita ng status kada link ang mga server na dumating, at ang file na resolv.conf ay maaaring maglaman lamang ng stub address, na tama at hindi kahina-hinala. Ang file na mano-manong inedit o hiwalay na encrypted-DNS client ay makakapagpadala ng mga lookup sa ibang lugar nang lubusan. Isulat ang natuklasan bago ito baguhin.

resolvectl status
resolvectl query app.internal.example

Paghiwalayin dito ang paglutas sa maabot. Ang address na dumarating habang hindi maabot ang serbisyo ay usapin ng routing o patakaran, hindi DNS.

Subukan ang mode ng resolver ng host sa adapter na iyon

Inilalarawan ng mga opsyon ng NAT DNS ng VirtualBox ang magkaibang mekanismo, at mahalaga ang pagkakaiba kapag nagbabago ang sariling resolver ng host kasama ng tunnel. Ang proxy ng DNS ay nagpapasa ng mga kahilingan ng guest sa mga server na ibinigay dito. Ang mode ng resolver ng host ay humaharang sa mga kahilingan at tumatawag sa DNS API ng host, at iyon ang mode na sumusunod sa resolver ng Windows na muling na-configure ng VPN client.

Buksan ang maling mekanismo at magtatagumpay pa rin ang utos habang hindi nagbabago ang pag-uugali, na isang nakakalitong paraan ng pagkawala ng isang hapon.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Itala ang kasalukuyang mga setting ng VM, patayin ito, at i-target ang adapter na napatunayan mo kanina. Ang huling digit sa opsyon ay numero ng adapter at hindi isang constant, kaya ang paglalapat nito sa VM na ang apektadong adapter ay pangalawa ay isang tahimik na operasyong walang epekto. Simulan ang guest at suriin ang configuration ng resolver na aktuwal na natanggap nito, dahil ang mano-manong setting sa guest ay nananaig sa lahat ng iniaalok ng NAT layer. Tandaan na ipinapalagay din ng mode ng resolver ng host na ang sariling landas ng DNS ng host ang nais mong ibahagi.

Ulitin ang parehong mga pagsubok sa muling pagkonekta sa VPN

Ulitin ang dalawang lookup sa guest, pagkatapos buksan ang tunay na aplikasyon at hayaang ito mismo ang magpatunay ng sertipiko. Ang pagsubok na address lamang ay kapaki-pakinabang para ihiwalay ang paglutas ng pangalan at hindi katumbas ng gumaganang sesyon ng TLS, kaya huwag huminto sa isang ping. Pagkatapos, sa isang aprubadong window, idiskonekta at muling ikonekta ang tunnel ng host at ulitin muli. Ang pag-uugaling nananatili lamang sa unang koneksyon pagkatapos ng boot ay problemang siklo ng buhay na dapat iulat, hindi isang hiwagang DNS na hahabulin ng ibang resolver.

Ang paggana ng pampublikong paglutas ay hindi nagpapatunay na ang mga pribadong query ay nanatili sa landas na hinihiling ng iyong patakaran.

Kapag walang binabago ang mode ng resolver ng host, ibalik ang naitalang configuration at panatilihin ang apat na obserbasyon: ano ang ibinalik ng host, ano ang ibinalik ng guest, ang mode ng adapter at ang kalagayan ng resolver. Ang hindi maabot na panloob na server, isang filter na hindi kasama ang trapiko ng hypervisor at isang override sa panig ng guest ay nangangailangan ng kanya-kanyang pagwawasto. Ang pag-convert ng adapter sa bridge ay nagbabago ng disenyo ng network at hindi ito reset ng DNS.