DNS des VirtualBox-Gasts bricht weg, sobald der Host einem VPN beitritt

Eine interne Anwendung wird auf dem Windows-Host in dem Moment aufgelöst, in dem das VPN verbindet, und der Ubuntu-Gast hinter dem NAT von VirtualBox findet sie weiterhin nicht. Der Gast hat einen eigenen Resolver, und der NAT-Adapter kann DNS auf mehr als eine Weise behandeln. Ersetzt man den Resolver des Gasts durch einen öffentlichen Server, funktionieren gewöhnliche Websites und private Namen scheitern, was das Problem verlagert statt es zu lösen. Arbeiten Sie die vier Prüfungen der Reihe nach ab und halten Sie bei der ersten an, die nicht zutrifft.

Bestätigen Sie, welchen Adaptermodus Sie debuggen

Nur ein Adapter im einfachen Modus NAT verhält sich so, wie dieser Artikel beschreibt. Ein Bridge-Adapter sitzt mit eigener Identität im physischen Netz, ein NAT-Netzwerk ist ein benannter virtueller Switch mit eigenen DHCP- und DNS-Einstellungen, und ein VPN-Client im Gast bringt einen völlig zweiten Resolver hinzu. Bestätigen Sie den Modus, bevor Sie weiterlesen, denn die Reparatur unterscheidet sich in jedem dieser Fälle.

Eine VM kann zwei Adapter in unterschiedlichen Modi tragen, und der betroffene ist nicht immer der erste.

Bestätigen Sie außerdem, dass der Host den Namen überhaupt auflöst. Öffnen Sie dieselbe Anwendung auf dem Host bei aufgebautem Tunnel und verwenden Sie denselben vollqualifizierten Namen, den der Gast benutzen wird. Scheitert auch der Host, liegt der Fehler nicht beim Gast, und keine Änderung am virtuellen Netzwerk wird das beheben.

Verfolgen Sie einen Namen durch den Resolver des Gasts

Wählen Sie einen internen Namen und einen öffentlichen Kontrollnamen und testen Sie dann beide an beiden Stellen. Ein öffentlicher Name, der sich auflöst, während der private es nicht tut, lokalisiert den Fehler auf dem privaten Pfad und nicht in der Namensauflösung allgemein. Testen Sie nur den privaten Namen, können Sie einen defekten Resolver nicht von einer defekten Route unterscheiden.

Schauen Sie im Gast nach, wofür der Resolver tatsächlich konfiguriert ist. Bei einem Ubuntu-Gast mit systemd-resolved zeigt der Status je Verbindung die Server, die angekommen sind, und die Datei resolv.conf kann nichts als eine Stub-Adresse enthalten, was korrekt und nicht verdächtig ist. Eine handbearbeitete Datei oder ein separater Client für verschlüsseltes DNS kann Abfragen ganz woandershin schicken. Notieren Sie, was Sie finden, bevor Sie etwas ändern.

resolvectl status
resolvectl query app.internal.example

Trennen Sie hier Auflösung von Erreichbarkeit. Eine Adresse, die ankommt, während der Dienst unerreichbar bleibt, ist eine Routing- oder Richtlinienfrage und keine DNS-Frage.

Probieren Sie den Host-Resolver-Modus auf diesem Adapter

Die NAT-DNS-Optionen von VirtualBox beschreiben unterschiedliche Mechanismen, und der Unterschied zählt, sobald sich der eigene Resolver des Hosts mit dem Tunnel ändert. Der DNS-Proxy leitet Gastanfragen an Server weiter, die ihm übergeben wurden. Der Host-Resolver-Modus fängt die Anfragen ab und ruft die DNS-API des Hosts auf, und das ist der Modus, der einem von einem VPN-Client umkonfigurierten Windows-Resolver folgt.

Aktivieren Sie den falschen Mechanismus, und der Befehl gelingt weiterhin, während sich das Verhalten nicht ändert, was eine verwirrende Art ist, einen Nachmittag zu verlieren.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Notieren Sie die aktuellen Einstellungen der VM, fahren Sie sie herunter und zielen Sie auf den Adapter, den Sie zuvor bestätigt haben. Die letzte Ziffer in der Option ist eine Adapternummer und keine Konstante, daher ist ihre Anwendung auf eine VM, deren betroffener Adapter der zweite ist, ein stiller Leerlauf. Starten Sie den Gast und prüfen Sie die Resolver-Konfiguration, die er tatsächlich erhalten hat, denn eine manuelle Einstellung im Gast überschreibt alles, was die NAT-Schicht bietet. Denken Sie daran, dass der Host-Resolver-Modus auch davon ausgeht, dass der eigene DNS-Pfad des Hosts derjenige ist, den Sie teilen wollten.

Wiederholen Sie dieselben Tests über eine VPN-Neuverbindung hinweg

Wiederholen Sie beide Abfragen im Gast, öffnen Sie dann die echte Anwendung und lassen Sie sie das Zertifikat selbst prüfen. Ein Test nur über die Adresse ist nützlich, um die Namensauflösung zu isolieren, und entspricht keiner funktionierenden TLS-Sitzung, also bleiben Sie nicht bei einem Ping stehen. Trennen und verbinden Sie dann in einem freigegebenen Zeitfenster den Tunnel des Hosts und wiederholen Sie es noch einmal. Verhalten, das nur bei der ersten Verbindung nach dem Start hält, ist ein zu meldendes Lebenszyklusproblem und kein DNS-Rätsel, das mit einem anderen Resolver zu jagen wäre.

Dass öffentliche Auflösung funktioniert, beweist nicht, dass private Abfragen auf dem Pfad geblieben sind, den Ihre Richtlinie verlangt.

Wenn der Host-Resolver-Modus nichts ändert, stellen Sie die aufgezeichnete Konfiguration wieder her und behalten Sie die vier Beobachtungen: was der Host zurückgab, was der Gast zurückgab, den Adaptermodus und den Resolver-Zustand. Ein unerreichbarer interner Server, ein Filter, der Hypervisor-Verkehr ausschließt und eine Überschreibung auf der Gästeseite brauchen jeweils eine andere Korrektur. Den Adapter in eine Bridge umzuwandeln ändert das Netzwerkdesign und ist kein DNS-Reset.