DNS hosta ve VirtualBoxu se rozbije, když se hostitel připojí k VPN

Interní aplikace se na Windows hostiteli přeloží ve chvíli, kdy se VPN připojí, a host Ubuntu za NAT VirtualBoxu ji stále nenajde. Host má vlastní resolver a adaptér NAT umí s DNS pracovat více než jedním způsobem. Nahrazení resolveru hosta veřejným serverem rozchodí běžné weby a nechá soukromá jména selhat, což problém přesouvá, místo aby ho řešilo. Projděte čtyři kontroly v pořadí a zastavte se u první, která neplatí.

Ověřte, který režim adaptéru ladíte

Tak, jak tento článek popisuje, se chová pouze adaptér v prostém režimu NAT. Přemostěný adaptér sedí na fyzické síti s vlastní identitou, síť NAT je pojmenovaný virtuální přepínač s vlastním nastavením DHCP a DNS a klient VPN uvnitř hosta přidává zcela druhý resolver. Ověřte režim, než budete číst dál, protože oprava se v každém z těchto případů liší.

Jeden virtuální stroj může mít dva adaptéry v různých režimech a postižený nemusí být vždy první.

Také ověřte, že hostitel jméno vůbec překládá. Otevřete stejnou aplikaci na hostiteli se zvednutým tunelem a použijte stejné plně kvalifikované jméno, jaké bude používat host. Pokud selže i hostitel, host není viníkem a žádná změna virtuální sítě to nespraví.

Sledujte jedno jméno přes resolver hosta

Vyberte jedno interní jméno a jedno veřejné kontrolní jméno a pak obě otestujte na obou místech. Veřejné jméno, které se přeloží, zatímco soukromé ne, lokalizuje závadu do soukromé cesty, nikoli do překladu jmen obecně. Testování pouze soukromého jména vám nedovolí rozeznat rozbitý resolver od rozbité trasy.

Uvnitř hosta se podívejte, na co je resolver skutečně nastavený. U hosta Ubuntu se systemd-resolved ukazuje stav po spojení servery, které dorazily, a soubor resolv.conf může obsahovat jen zástupnou adresu, což je správné, nikoli podezřelé. Ručně upravený soubor nebo samostatný klient šifrovaného DNS může posílat dotazy úplně jinam. Než to změníte, zapište si, co jste zjistili.

resolvectl status
resolvectl query app.internal.example

Oddělte zde překlad od dostupnosti. Adresa, která dorazí, zatímco služba zůstává nedostupná, je otázka směrování nebo zásad, nikoli DNS.

Vyzkoušejte režim resolveru hostitele na tomto adaptéru

Možnosti NAT DNS ve VirtualBoxu popisují různé mechanismy a rozdíl začne být důležitý, jakmile se vlastní resolver hostitele změní s tunelem. Proxy DNS předává požadavky hosta serverům, které dostala. Režim resolveru hostitele požadavky zachytí a volá DNS API hostitele, což je režim, který následuje resolver Windows překonfigurovaný klientem VPN.

Zapněte špatný mechanismus a příkaz stále uspěje, zatímco chování se nezmění, což je matoucí způsob, jak ztratit odpoledne.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Zapište aktuální nastavení virtuálního stroje, vypněte ho a zamiřte na adaptér, který jste dříve ověřili. Poslední číslice v přepínači je číslo adaptéru, nikoli konstanta, takže její použití na stroj, jehož postižený adaptér je druhý, je tichá operace bez účinku. Spusťte hosta a zkontrolujte konfiguraci resolveru, kterou skutečně dostal, protože ruční nastavení v hostu přebíjí vše, co vrstva NAT nabízí. Pamatujte, že režim resolveru hostitele také předpokládá, že vlastní cesta DNS hostitele je ta, kterou jste chtěli sdílet.

Zopakujte stejné testy při opětovném připojení VPN

Zopakujte oba dotazy v hostu, potom otevřete skutečnou aplikaci a nechte ji ověřit certifikát sama. Test pouze podle adresy je užitečný pro izolaci překladu jmen a není rovnocenný funkční relaci TLS, takže se nezastavujte u ping. Potom v povoleném okně odpojte a znovu připojte tunel hostitele a zopakujte to ještě jednou. Chování, které vydrží jen při prvním připojení po startu, je problém životního cyklu k nahlášení, ne DNS záhada, kterou má honit jiný resolver.

Funkční veřejný překlad nedokazuje, že soukromé dotazy zůstaly na cestě, kterou vyžadují vaše zásady.

Když režim resolveru hostitele nic nezmění, vraťte zaznamenanou konfiguraci a podržte si čtyři pozorování: co vrátil hostitel, co vrátil host, režim adaptéru a stav resolveru. Nedostupný interní server, filtr, který vylučuje provoz hypervizoru a přepis na straně hosta potřebují každý jinou opravu. Převod adaptéru na most mění návrh sítě a není resetem DNS.