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

Sa isang Windows host, nareresolba ang panloob na pangalan ng application kapag kumonekta ang VPN, ngunit sa loob ng isang Ubuntu guest ay hindi. Pinapanatili ng guest ang sarili nitong mga setting ng resolver, at ang NAT adapter sa harap nito ay makakasagot sa mga query ng DNS sa dalawang magkaibang paraan. Ang pagturo sa guest sa isang pampublikong resolver ay nagpapaload muli ng mga website habang nananatiling sira ang mga pribadong pangalan. Kaya sinusubaybayan ang landas ng resolver bago baguhin ang anuman.

Subaybayan ang isang lookup sa pamamagitan ng NAT adapter

Pumili ng isang panloob na ganap na kwalipikadong pangalan at isang pampublikong pangalan bilang kontrol. Habang nakaangat ang tunnel, kumpirmahin sa host na nareresolba ang panloob na pangalan at bumubukas ang application sa likod nito. Pagkatapos ay patakbuhin ang parehong dalawang lookup sa loob ng guest at ihambing ang mga sagot, hindi ang mga tool.

Bago magpatuloy, kumpirmahin na ang adapter ay talagang ordinaryong NAT. Ang bridge adapter, pinangalanang NAT network at pangalawang VPN client sa loob ng guest ay may kani-kanilang configuration at kani-kanilang paliwanag. Ang paghula sa puntong ito ay nagsasayang ng natitirang pagsisiyasat.

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

Ipinapakita ng unang command ang mode ng adapter at anumang NAT network na nakakabit dito. Sa loob ng isang Ubuntu guest, inililista ng pangalawa ang mga setting ng DNS bawat link, at ang pangatlo ay madalas na naghahayag lamang ng lokal na stub address, ibig sabihin ang tunay na upstream ay nasa ibang lugar.

Paghiwalayin ang resolusyon at maabot. Ang guest na tumatanggap ng tamang address ngunit hindi makapagbukas ng koneksyon ay may problema sa routing, filtering o pahintulot ng serbisyo, at hindi ito maaapektuhan ng karagdagang pagbabago sa DNS. Subukan ang address nang hiwalay at itala kung alin sa dalawa ang nabigo.

Ang proxy mode at host resolver mode ay magkaibang mekanismo

Sa proxy mode, ipinapasa ng NAT engine ang mga query ng guest sa mga DNS server na kilala na nito. Sa host resolver mode, hinaharang nito ang query at hinihiling sa operating system ng host na resolbahin ang pangalan gamit ang ginagamit ng host sa sandaling ito. Tanging ang pangalawa ang sumusunod sa VPN client na nagsusulat muli ng resolusyon ng host kapag umangat ang tunnel. Kaya nagbibigay ang dalawang setting ng magkaibang sagot sa parehong makina.

Ang pagkakaibang iyon ang buong problema sa isang pangungusap. Ang pagbibigay sa guest ng listahan ng mga address ng server ay hindi katulad ng paghiling sa Windows na resolbahin ang pangalan sa pamamagitan ng naka-configure na resolver, at sa VPN na may split DNS ay magkaiba ang dalawang sagot. Ang opsyon ng adapter ay tungkol sa mekanismo, hindi sa pahintulot.

Wala sa dalawang mode ang nagbibigay ng access sa anuman. Ang awtorisasyon ay naninirahan sa patakaran ng VPN at sa serbisyo, at ang gumaganang lookup ay nangangahulugan lamang na ang isang pangalan ay naging address.

Palitan ang adapter, pagkatapos ay i-verify kung ano ang natatanggap ng guest

Itala muna ang mga setting ng network at DNS ng VM, pagkatapos ay isara ang makina upang ang ine-edit mo ay ang persistent na configuration. Para sa VM na pinangalanang work-ubuntu na ang unang adapter ay may NAT, ang opsyon bawat adapter ay itinatakda mula sa host habang patay ang VM. Simulan itong muli pagkatapos at siyasatin ang resulta sa halip na magtiwala sa exit status.

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

Pinipili ng huling digit ang numero ng adapter, kaya hindi ito pangkalahatang halaga; ang setting para sa adapter 2 ay magdadala ng 2 sa posisyong iyon. Gamitin ang VBoxManage binary na kabilang sa naka-install na bersyon ng VirtualBox, dahil ang mas luma sa path ay maaaring magsulat ng mga setting na hindi pinapansin ng tumatakbong bersyon.

Ang paganahin ang proxy option sa halip ay pumipili ng ibang mekanismo at hindi ka binibigyan ng pag-uugali ng host resolver. Pagkatapos magsimula ang guest, suriin ang configuration ng DNS na aktwal na hawak nito, dahil ang naka-pin na resolver o naka-encrypt na setting ng DNS sa loob ng guest ay nagpapanatili sa mga application sa ibang landas anuman ang inaalok ng adapter.

Subukan sa buong lifecycle ng VPN, hindi lamang isang beses

Ulitin ang parehong lookup sa guest, pagkatapos ay buksan ang tunay na application at hayaang i-validate nito ang TLS hostname. Ang test ng koneksyon na IP lamang ay naghihiwalay nang maayos sa DNS, ngunit hindi ito pagsusuri ng sertipiko at hindi dapat iulat nang ganoon. Itala ang pangalan, address at resulta ng application nang magkasama.

Sa loob ng isang aprubadong window, idiskonekta at ikonekta muli ang VPN ng host at ulitin ang test. Dapat tumugma ang resulta sa patakaran ng access, at ang paggana muli ng pampublikong resolusyon ay walang sinasabi kung nanatili ang mga pribadong query sa nilalayong landas.

Kapag walang binabago ang host resolver mode, ibalik ang naitalang halaga at panatilihin ang mga obserbasyon. Ang VPN client na nagbubukod sa trapiko ng hypervisor, hindi maabot na panloob na resolver at naka-pin na setting ng guest ay nangangailangan ng kani-kaniyang pagwawasto, at ang pag-bridge sa adapter ay nagbabago ng disenyo ng network sa halip na i-reset ang DNS.