DNS gosta v VirtualBoxu se pokvari, ko se gostitelj poveže z VPN

Notranja aplikacija se na gostitelju Windows razreši v trenutku, ko se VPN poveže, gost Ubuntu za NAT VirtualBoxa pa je še vedno ne najde. Gost ima svoj resolver in adapter NAT lahko obravnava DNS na več kot en način. Zamenjava gostovega resolverja z javnim strežnikom naredi običajne spletne strani delujoče, zasebna imena pa neuspešna, kar problem prestavi, namesto da bi ga rešilo. Izvedite štiri preverjanja po vrsti in ustavite se pri prvem, ki ne drži.

Potrdite, kateri način adapterja odpravljate

Samo adapter v običajnem načinu NAT se obnaša tako, kot opisuje ta članek. Mostni adapter sedi v fizičnem omrežju z lastno identiteto, omrežje NAT je imenovano virtualno stikalo z lastnimi nastavitvami DHCP in DNS, odjemalec VPN znotraj gosta pa doda povsem drugi resolver. Potrdite način, preden berete naprej, ker se popravilo v vsakem od teh primerov razlikuje.

En virtualni stroj ima lahko dva adapterja v različnih načinih, prizadeti pa ni vedno prvi.

Potrdite tudi, da gostitelj ime sploh razreši. Odprite isto aplikacijo na gostitelju z dvignjenim tunelom in uporabite isto popolnoma kvalificirano ime, ki ga bo uporabil gost. Če tudi gostitelj ne uspe, gost ni kriv in nobena sprememba virtualnega omrežja tega ne bo popravila.

Sledite enemu imenu skozi resolver gosta

Izberite eno notranje ime in eno javno kontrolno ime, nato oba preizkusite na obeh mestih. Javno ime, ki se razreši, medtem ko se zasebno ne, napako locira na zasebno pot in ne na razreševanje imen na splošno. Preizkušanje samo zasebnega imena vam ne omogoča razlikovanja med pokvarjenim resolverjem in pokvarjeno potjo.

V gostu poglejte, za kaj je resolver dejansko nastavljen. Na gostu Ubuntu s systemd-resolved stanje po povezavi pokaže strežnike, ki so prispeli, datoteka resolv.conf pa lahko vsebuje le naslov stub, kar je pravilno in ne sumljivo. Ročno urejena datoteka ali ločen odjemalec šifriranega DNS lahko pošilja poizvedbe povsem drugam. Preden kaj spremenite, zapišite, kar ste našli.

resolvectl status
resolvectl query app.internal.example

Tukaj ločite razreševanje od dosegljivosti. Naslov, ki prispe, medtem ko storitev ostaja nedosegljiva, je vprašanje usmerjanja ali politike, ne DNS.

Preizkusite način resolverja gostitelja na tem adapterju

Možnosti NAT DNS v VirtualBoxu opisujejo različne mehanizme, razlika pa postane pomembna, ko se gostiteljev lastni resolver spremeni s tunelom. Proxy DNS posreduje zahteve gosta strežnikom, ki jih je prejel. Način resolverja gostitelja zahteve prestreže in pokliče DNS API gostitelja, in to je način, ki sledi resolverju Windows, ki ga je znova konfiguriral odjemalec VPN.

Vklopite napačen mehanizem in ukaz bo vseeno uspel, medtem ko se vedenje ne bo spremenilo, kar je zmeden način, kako izgubiti popoldne.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Zapišite trenutne nastavitve virtualnega stroja, ga izklopite in ciljajte adapter, ki ste ga potrdili prej. Zadnja številka v možnosti je številka adapterja in ne konstanta, zato je njena uporaba na stroju, katerega prizadeti adapter je drugi, tiha operacija brez učinka. Zaženite gosta in preverite konfiguracijo resolverja, ki jo je dejansko prejel, ker ročna nastavitev v gostu preglasi vse, kar ponuja plast NAT. Ne pozabite, da način resolverja gostitelja tudi predpostavlja, da je lastna pot DNS gostitelja tista, ki ste jo želeli deliti.

Ponovite iste teste med ponovno povezavo VPN

Ponovite obe poizvedbi v gostu, nato odprite pravo aplikacijo in pustite, da sama preveri potrdilo. Preizkus samo po naslovu je koristen za izolacijo razreševanja imen in ni enakovreden delujoči seji TLS, zato se ne ustavite pri ping. Nato v odobrenem oknu prekinite in znova povežite tunel gostitelja ter ponovite še enkrat. Vedenje, ki se obdrži le pri prvi povezavi po zagonu, je težava življenjskega cikla, o kateri je treba poročati, ne skrivnost DNS, ki bi jo bilo treba loviti z drugim resolverjem.

Da javno razreševanje deluje, ne dokazuje, da so zasebne poizvedbe ostale na poti, ki jo zahteva vaša politika.

Ko način resolverja gostitelja ne spremeni ničesar, vrnite zapisano konfiguracijo in obdržite štiri opažanja: kaj je vrnil gostitelj, kaj je vrnil gost, način adapterja in stanje resolverja. Nedosegljiv notranji strežnik, filter, ki izključuje promet hipervizorja in prepis na strani gosta potrebujejo vsak svoj popravek. Pretvorba adapterja v most spremeni zasnovo omrežja in ni ponastavitev DNS.