DNS des VirtualBox-NAT-Gasts bricht zusammen, wenn der Host einem VPN beitritt

Auf einem Windows-Host wird der interne Anwendungsname aufgelöst, sobald das VPN verbindet, in einem Ubuntu-Gast nicht. Der Gast behält seine eigenen Resolver-Einstellungen, und der NAT-Adapter davor kann DNS-Anfragen auf zwei verschiedene Arten beantworten. Zeigt der Gast auf einen öffentlichen Resolver, laden Websites wieder, private Namen bleiben aber kaputt. Deshalb wird der Resolver-Pfad nachvollzogen, bevor etwas geändert wird.

Verfolgen Sie eine Auflösung durch den NAT-Adapter

Wählen Sie einen internen vollqualifizierten Namen und einen öffentlichen Namen als Kontrolle. Bestätigen Sie bei aktivem Tunnel auf dem Host, dass der interne Name auflöst und die dahinterliegende Anwendung sich öffnet. Führen Sie dann dieselben zwei Abfragen im Gast aus und vergleichen Sie die Antworten, nicht die Werkzeuge.

Bestätigen Sie, dass der Adapter wirklich einfaches NAT ist, bevor Sie weitermachen. Ein Bridge-Adapter, ein benanntes NAT-Netzwerk und ein zweiter VPN-Client im Gast haben jeweils ihre eigene Konfiguration und ihre eigene Erklärung. Raten an dieser Stelle verschwendet den Rest der Untersuchung.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

Der erste Befehl zeigt den Adaptermodus und jedes daran angeschlossene NAT-Netzwerk. In einem Ubuntu-Gast listet der zweite die DNS-Einstellungen pro Link auf, und der dritte offenbart oft nur eine lokale Stub-Adresse, was bedeutet, dass der echte Upstream woanders sitzt.

Halten Sie Auflösung und Erreichbarkeit getrennt. Ein Gast, der die richtige Adresse erhält, aber keine Verbindung öffnen kann, hat ein Routing-, Filter- oder Dienstberechtigungsproblem, und weitere DNS-Änderungen werden es nie berühren. Testen Sie die Adresse separat und notieren Sie, welche der beiden fehlgeschlagen ist.

Proxy-Modus und Host-Resolver-Modus sind verschiedene Mechanismen

Im Proxy-Modus leitet die NAT-Engine Gastabfragen an DNS-Server weiter, die sie bereits kennt. Im Host-Resolver-Modus fängt sie die Abfrage ab und bittet das Host-Betriebssystem, den Namen mit dem aufzulösen, was der Host gerade verwendet. Nur der zweite folgt einem VPN-Client, der die Host-Auflösung neu schreibt, wenn der Tunnel hochkommt. Deshalb liefern die beiden Einstellungen auf derselben Maschine unterschiedliche Antworten.

Dieser Unterschied ist das ganze Problem in einem Satz. Dem Gast eine Liste von Serveradressen zu geben ist nicht dasselbe, wie Windows zu bitten, einen Namen über seinen konfigurierten Resolver aufzulösen, und bei einem Split-DNS-VPN unterscheiden sich die beiden Antworten. Bei der Adapteroption geht es um den Mechanismus, nicht um die Berechtigung.

Keiner der Modi gewährt Zugang zu irgendetwas. Die Autorisierung liegt in der VPN-Richtlinie und im Dienst, und eine funktionierende Auflösung bedeutet nur, dass ein Name zu einer Adresse wurde.

Schalten Sie den Adapter um und prüfen Sie dann, was der Gast erhält

Notieren Sie zuerst die Netzwerk- und DNS-Einstellungen der VM und fahren Sie die Maschine dann herunter, damit die persistente Konfiguration das ist, was Sie bearbeiten. Bei einer VM namens work-ubuntu, deren erster Adapter NAT trägt, wird die Option pro Adapter vom Host aus gesetzt, während die VM ausgeschaltet ist. Starten Sie sie danach erneut und prüfen Sie das Ergebnis, statt dem Exit-Status zu vertrauen.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

Die letzte Ziffer wählt die Adapternummer, ist also kein universeller Wert; eine Einstellung für Adapter 2 würde an dieser Stelle eine 2 tragen. Verwenden Sie die VBoxManage-Binärdatei, die zur installierten VirtualBox-Version gehört, denn eine ältere im Pfad kann Einstellungen schreiben, die die laufende Version ignoriert.

Die Proxy-Option stattdessen zu aktivieren wählt einen anderen Mechanismus und liefert Ihnen kein Host-Resolver-Verhalten. Prüfen Sie nach dem Start des Gasts die DNS-Konfiguration, die er tatsächlich hält, denn ein festgelegter Resolver oder eine verschlüsselte DNS-Einstellung im Gast hält Anwendungen auf einem anderen Pfad, unabhängig davon, was der Adapter anbietet.

Testen Sie über den gesamten VPN-Lebenszyklus, nicht nur einmal

Wiederholen Sie beide Auflösungen im Gast, öffnen Sie dann die echte Anwendung und lassen Sie sie den TLS-Hostnamen validieren. Ein Verbindungstest nur über IP isoliert DNS gut, ist aber keine Zertifikatsprüfung und sollte nicht als eine gemeldet werden. Notieren Sie Namen, Adresse und Anwendungsergebnis zusammen.

Trennen und verbinden Sie das Host-VPN während eines genehmigten Fensters und wiederholen Sie den Test. Das Ergebnis sollte zur Zugriffsrichtlinie passen, und dass die öffentliche Auflösung wieder funktioniert, sagt nichts darüber aus, ob private Abfragen auf dem vorgesehenen Pfad blieben.

Wenn der Host-Resolver-Modus nichts ändert, setzen Sie den notierten Wert zurück und behalten Sie die Beobachtungen. Ein VPN-Client, der Hypervisor-Verkehr ausschließt, ein nicht erreichbarer interner Resolver und eine festgelegte Gasteinstellung brauchen jeweils eine andere Korrektur, und den Adapter zu bridgen ändert das Netzwerkdesign, statt DNS zurückzusetzen.