A VirtualBox-vendég DNS-e elromlik, miután a gazdagép VPN-hez csatlakozik

Egy belső alkalmazás a Windows gazdagépen abban a pillanatban oldódik fel, amikor a VPN csatlakozik, a VirtualBox NAT mögötti Ubuntu vendég viszont még mindig nem találja. A vendégnek saját resolverje van, és a NAT adapter többféleképpen is kezelheti a DNS-t. A vendég resolverének nyilvános kiszolgálóra cserélése a hétköznapi webhelyeket működőképessé, a privát neveket pedig sikertelenné teszi, ami inkább másfelé tereli a problémát, mint megoldja. Végezze el a négy ellenőrzést sorrendben, és álljon meg az elsőnél, amelyik nem teljesül.

Erősítse meg, melyik adapter módot hibakeresi

Csak a sima NAT módban lévő adapter viselkedik úgy, ahogy ez a cikk leírja. A híd adapter a fizikai hálózaton ül saját identitással, a NAT hálózat egy elnevezett virtuális kapcsoló saját DHCP- és DNS-beállításokkal, a vendégen belüli VPN-kliens pedig teljesen második resolvert ad hozzá. Erősítse meg a módot, mielőtt tovább olvasna, mert a javítás mindegyik esetben eltér.

Egy virtuális gép két adaptert is hordozhat különböző módokban, és az érintett nem mindig az első.

Azt is erősítse meg, hogy a gazdagép egyáltalán feloldja-e a nevet. Nyissa meg ugyanazt az alkalmazást a gazdagépen felállított alagúttal, ugyanazt a teljesen minősített nevet használva, amelyet a vendég használni fog. Ha a gazdagép is elbukik, nem a vendég a hibás, és semmilyen virtuális hálózati változtatás nem javítja meg.

Kövessen végig egy nevet a vendég resolverén

Válasszon egy belső nevet és egy nyilvános kontrollnevet, majd tesztelje mindkettőt mindkét helyen. Az a nyilvános név, amely feloldódik, miközben a privát nem, a hibát a privát útvonalra lokalizálja, nem a névfeloldásra általában. Ha csak a privát nevet teszteli, nem tudja megkülönböztetni a törött resolvert a törött útvonaltól.

A vendégen belül nézze meg, mire van a resolver valójában beállítva. Egy systemd-resolvedet futtató Ubuntu vendégen a kapcsolatonkénti állapot mutatja a megérkezett kiszolgálókat, és a resolv.conf fájl csak egy stub-címet tartalmazhat, ami helyes, nem gyanús. Egy kézzel szerkesztett fájl vagy egy külön titkosított DNS-kliens teljesen máshová küldheti a lekérdezéseket. Jegyezze fel, amit talált, mielőtt bármit módosítana.

resolvectl status
resolvectl query app.internal.example

Itt válassza szét a feloldást az elérhetőségtől. Az a cím, amely megérkezik, miközben a szolgáltatás elérhetetlen marad, útvonal- vagy házirendkérdés, nem DNS-kérdés.

Próbálja ki a gazdagép resolver módot azon az adapteren

A VirtualBox NAT DNS-beállításai különböző mechanizmusokat írnak le, és a különbség számít, amikor a gazdagép saját resolverje az alagúttal együtt megváltozik. A DNS-proxy továbbítja a vendég kéréseit a kapott kiszolgálók felé. A gazdagép resolver mód elfogja a kéréseket, és a gazdagép DNS API-ját hívja, és ez az a mód, amely a VPN-kliens által újrakonfigurált Windows resolvert követi.

Kapcsolja be a rossz mechanizmust, és a parancs továbbra is sikeres lesz, miközben a viselkedés nem változik, ami zavarba ejtő módja egy délután elvesztésének.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Jegyezze fel a virtuális gép jelenlegi beállításait, kapcsolja ki, és célozza meg a korábban megerősített adaptert. Az opció utolsó számjegye adapter szám, nem állandó, ezért olyan gépre alkalmazva, amelynek érintett adaptere a második, csendes, hatástalan művelet. Indítsa el a vendéget, és ellenőrizze a ténylegesen kapott resolver-konfigurációt, mert a vendégen kézzel beállított érték felülír mindent, amit a NAT réteg kínál. Ne feledje, hogy a gazdagép resolver mód azt is feltételezi, hogy a gazdagép saját DNS-útvonala az, amelyet meg akart osztani.

Ismételje meg ugyanazokat a teszteket egy VPN-újracsatlakozás során

Ismételje meg mindkét lekérdezést a vendégen, majd nyissa meg a valódi alkalmazást, és hagyja, hogy maga ellenőrizze a tanúsítványt. A csak címre épülő teszt hasznos a névfeloldás elkülönítésére, és nem egyenértékű egy működő TLS-munkamenettel, ezért ne álljon meg egy pingnél. Ezután egy jóváhagyott időablakban bontsa és állítsa helyre a gazdagép alagútját, és ismételje meg még egyszer. Az a viselkedés, amely csak az indítás utáni első kapcsolatnál áll fenn, jelentendő életciklus-probléma, nem DNS-rejtély, amelyet másik resolverrel kellene üldözni.

Az, hogy a nyilvános feloldás működik, nem bizonyítja, hogy a privát lekérdezések azon az útvonalon maradtak, amelyet a házirendje megkövetel.

Amikor a gazdagép resolver mód semmit sem változtat, tegye vissza a feljegyzett konfigurációt, és tartsa meg a négy megfigyelést: mit adott vissza a gazdagép, mit adott vissza a vendég, az adapter módját és a resolver állapotát. Egy elérhetetlen belső kiszolgáló, a hipervizor forgalmát kizáró szűrő és egy vendégoldali felülbírálás mindegyike más javítást igényel. Az adapter hídra alakítása megváltoztatja a hálózati tervet, és nem DNS-visszaállítás.