DNS hosta ve VirtualBox NAT se po připojení hostitele k VPN rozbije
Host má vlastní resolver a adaptér NAT má dva režimy DNS. Vysledujte jedno hledání a pak rozhodněte, zda režim resolveru hostitele odpovídá zásadám VPN.
Na hostiteli s Windows se interní název aplikace přeloží, jakmile se připojí VPN, ale uvnitř hosta Ubuntu ne. Host si ponechává vlastní nastavení resolveru, a adaptér NAT před ním může odpovídat na dotazy DNS dvěma různými způsoby. Nasměrování hosta na veřejný resolver znovu načte weby, ale soukromé názvy zůstanou rozbité. Proto se cesta resolveru vysleduje dřív, než se cokoli upraví.
Vysledujte jedno hledání přes adaptér NAT
Vyberte jeden interní plně kvalifikovaný název a jeden veřejný název jako kontrolu. Se zvednutým tunelem potvrďte na hostiteli, že se interní název přeloží a aplikace za ním se otevře. Pak spusťte stejná dvě hledání uvnitř hosta a porovnejte odpovědi, ne nástroje.
Než půjdete dál, potvrďte, že adaptér je opravdu obyčejný NAT. Přemostěný adaptér, pojmenovaná síť NAT a druhý klient VPN uvnitř hosta mají každý svou konfiguraci a své vysvětlení. Hádání v tomto bodě plýtvá zbytkem vyšetřování.
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet resolvectl status | head -40 cat /etc/resolv.conf
První příkaz ukazuje režim adaptéru a případnou síť NAT, která k němu patří. Uvnitř hosta Ubuntu druhý vypíše nastavení DNS pro jednotlivá spojení a třetí často odhalí jen místní zástupnou adresu, což znamená, že skutečný upstream je jinde.
Držte překlad a dostupnost oddělené. Host, který dostane správnou adresu, ale nedokáže otevřít spojení, má problém se směrováním, filtrováním nebo oprávněním služby a další změny DNS se ho nikdy nedotknou. Otestujte adresu zvlášť a zapište, která z těch dvou věcí selhala.
Režim proxy a režim resolveru hostitele jsou různé mechanismy
V režimu proxy předává stroj NAT dotazy hosta serverům DNS, které už zná. V režimu resolveru hostitele dotaz zachytí a požádá operační systém hostitele, aby název přeložil tím, co hostitel právě používá. Jen druhý následuje klienta VPN, který při zvednutí tunelu přepisuje překlad na hostiteli. Proto obě nastavení dávají na stejném stroji různé odpovědi.
Tento rozdíl je celý problém v jedné větě. Dát hostu seznam adres serverů není totéž jako požádat Windows, aby název přeložil přes svůj nakonfigurovaný resolver, a u VPN s rozděleným DNS se obě odpovědi liší. Volba adaptéru se týká mechanismu, ne oprávnění.
Ani jeden režim nic nezpřístupňuje. Autorizace žije v zásadách VPN a ve službě a fungující hledání znamená jen to, že se název proměnil v adresu.
Přepněte adaptér a pak ověřte, co host dostane
Nejprve si poznamenejte síťové nastavení a DNS virtuálního stroje, pak stroj vypněte, aby se upravovala trvalá konfigurace. U virtuálního stroje jménem work-ubuntu, jehož první adaptér nese NAT, se volba pro konkrétní adaptér nastavuje z hostitele, když je stroj vypnutý. Poté ho znovu spusťte a výsledek prohlédněte, místo abyste věřili návratovému kódu.
VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns
Poslední číslice vybírá číslo adaptéru, takže to není univerzální hodnota; nastavení pro adaptér 2 by na tom místě neslo 2. Použijte binárku VBoxManage, která patří k nainstalované verzi VirtualBoxu, protože starší v cestě může zapsat nastavení, jež běžící verze ignoruje.
Zapnutí volby proxy místo toho zvolí jiný mechanismus a chování resolveru hostitele vám nedá. Po spuštění hosta zkontrolujte konfiguraci DNS, kterou skutečně drží, protože připnutý resolver nebo nastavení šifrovaného DNS uvnitř hosta drží aplikace na jiné cestě bez ohledu na to, co adaptér nabízí.
Testujte napříč celým životním cyklem VPN, ne jen jednou
Zopakujte obě hledání v hostu, pak otevřete skutečnou aplikaci a nechte ji ověřit název hostitele TLS. Test spojení pouze přes IP dobře izoluje DNS, ale není to kontrola certifikátu a nemělo by se to tak hlásit. Zaznamenejte název, adresu a výsledek aplikace společně.
V schváleném okně odpojte a znovu připojte VPN hostitele a test zopakujte. Výsledek by měl odpovídat zásadám přístupu a to, že veřejný překlad znovu funguje, nic neříká o tom, zda soukromé dotazy zůstaly na zamýšlené cestě.
Když režim resolveru hostitele nic nezmění, vraťte zaznamenanou hodnotu a pozorování si ponechte. Klient VPN, který vylučuje provoz hypervizoru, nedostupný interní resolver a připnuté nastavení hosta potřebují každý jinou opravu a přemostění adaptéru mění návrh sítě, místo aby resetovalo DNS.