DNS fan 'e VirtualBox-gast brekt nei't de host by in VPN komt

In ynterne applikaasje wurdt op 'e Windows-host oplost op it stuit dat de VPN ferbynt, en de Ubuntu-gast efter VirtualBox NAT kin it noch hieltyd net fine. De gast hat syn eigen resolver, en de NAT-adapter kin DNS op mear as ien manier behannelje. It ferfangen fan 'e resolver fan 'e gast troch in iepenbiere tsjinner lit gewoane websites wurkje en priveenammen mislearje, wat it probleem ferpleatst ynstee fan it op te lossen. Wurkje de fjouwer kontrôles yn folchoarder ôf en stop by de earste dy't net hâldt.

Befêstigje hokker adaptermodus jo debugge

Allinnich in adapter yn gewoane modus NAT hâldt him sa, as dit artikel beskriuwt. In brêgeadapter sit op it fysike netwurk mei syn eigen identiteit, in NAT-netwurk is in neamd firtuele skeakel mei syn eigen DHCP- en DNS-ynstellings, en in VPN-klant yn 'e gast foeget hielendal in twadde resolver ta. Befêstigje de modus foardat jo fierder lêze, want de reparaasje ferskilt yn elk fan dy gefallen.

Ien VM kin twa adapters yn ferskillende modi drage, en de oantaaste is net altyd de earste.

Befêstigje ek dat de host de namme hielendal oplost. Iepenje deselde applikaasje op 'e host mei de tunnel omheech, en brûk deselde folslein kwalifisearre namme dy't de gast brûke sil. As de host ek mislearret, is de gast net de skuld en gjin feroaring oan firtueel netwurk sil dat reparearje.

Folgje ien namme troch de resolver fan 'e gast

Kies ien ynterne namme en ien iepenbiere kontrôlenamme, en test dan beide op beide plakken. In iepenbiere namme dy't oplost wylst de privee dat net docht, lokaliseart de flater op it priveepaad ynstee fan op namme-oplossing yn 't algemien. Allinnich de priveenamme testen lit jo net ta om in stikken resolver fan in stikken rûte te ûnderskieden.

Sjoch yn 'e gast wêr't de resolver eins foar konfigurearre is. Op in Ubuntu-gast mei systemd-resolved lit de status per keppeling de tsjinners sjen dy't oankamen, en it bestân resolv.conf kin neat oars as in stub-adres befetsje, wat korrekt is en net fertocht. In mei de hân bewurke bestân of in aparte fersifere-DNS-klant kin opfrezen hielendal earne oars hinne stjoere. Skriuw op wat jo fine foardat jo it feroarje.

resolvectl status
resolvectl query app.internal.example

Skied hjir oplossing fan berikberheid. In adres dat oankomt wylst de tsjinst ûnberikber bliuwt, is in rûte- of beliedskwestje, net in DNS-kwestje.

Probearje de hostresolvermodus op dy adapter

De NAT-DNS-opsjes fan VirtualBox beskriuwe ferskillende meganismen, en it ferskil is fan belang sadra't de eigen resolver fan 'e host mei de tunnel feroaret. De DNS-proxy stjoert opfrezen fan 'e gast troch nei tsjinners dy't it krigen hat. Hostresolvermodus ûnderskept de opfrezen en ropt de DNS-API fan 'e host oan, en dat is de modus dy't in Windows-resolver folget dy't troch in VPN-klant werkonfigurearre is.

Skeakelje it ferkearde meganisme yn en it kommando slagget noch hieltyd wylst it gedrach net feroaret, wat in betiizjende manier is om in middei te ferliezen.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Skriuw de hjoeddeiske ynstellings fan 'e VM op, set him út en rjochtsje op 'e adapter dy't jo earder befêstige hawwe. It lêste sifer yn 'e opsje is in adapternûmer ynstee fan in konstante, dus it tapassen op in VM wêrfan't de oantaaste adapter de twadde is, is in stil leechloperke. Start de gast en kontrolearje de resolverkonfiguraasje dy't er eins krigen hat, want in hânmjittige ynstelling yn 'e gast oerhearsket alles wat de NAT-laach biedt. Tink derom dat hostresolvermodus ek oannimt dat it eigen DNS-paad fan 'e host is wat jo diele woene.

Werhelje deselde tests oer in VPN-ferbining opnij

Werhelje beide opfrezen yn 'e gast, iepenje dan de echte applikaasje en lit dy it sertifikaat sels falidearje. In test allinnich op adres is nuttich om namme-oplossing te isolearjen en is net gelyk oan in wurkjende TLS-sesje, dus stop net by in ping. Ferbrek dan, yn in goedkarde finster, de tunnel fan 'e host en ferbyn opnij, en werhelje noch ien kear. Gedrach dat allinnich by de earste ferbining nei it opstarten hâldt, is in libbenssyklusprobleem om te rapportearjen, net in DNS-mystearje om mei in oare resolver efternei te gean.

Dat iepenbiere oplossing wurket, bewiist net dat privee opfrezen op it paad bleaun binne dat jo belied easket.

As hostresolvermodus neat feroaret, set de opnommen konfiguraasje werom en hâld de fjouwer waarnimmings: wat de host weromjoech, wat de gast weromjoech, de adaptermodus en de resolverstatus. In ûnberikbere ynterne tsjinner, in filter dat hypervisor-ferkear útslút en in oerskriuwing oan 'e gastkant hawwe elk in oare korreksje nedich. It omsetten fan 'e adapter nei in brêge feroaret it netwurkûntwerp en is gjin DNS-reset.