VirtualBox NAT oder Bridge: Wo das VPN der VM endet

Zwei verschiedene Fragen kommen zusammen auf, sobald eine virtuelle Maschine einen VPN-Client ausführt, und sie haben verschiedene Antworten. Die erste ist, ob ein Tunnel im Gast den Host schützt, und die zweite, ob ein Tunnel auf dem Host den Gast abdeckt. Der Adaptermodus entscheidet beides, stärker als die VPN-Software. Ein NAT-Adapter macht den Host zum sichtbaren Endpunkt, während ein Bridge-Adapter den Gast mit eigener Adresse ins Netz legt.

Wer die verschlüsselte Sitzung tatsächlich beendet

Eine verschlüsselte Sitzung gehört der Maschine, die sie beendet, und das ist der Gast, wenn der Client in der VM läuft. Nur Verkehr, der in den virtuellen Adapter des Gastes eintritt, nimmt diesen Tunnel, und der Hypervisor leitet niemals von sich aus eine andere Maschine durch den Gast. Deshalb kann der Gast einen funktionierenden Tunnel halten, während der Host offen im Netz surft. Die Umkehrung ist nicht symmetrisch, und genau diese Asymmetrie ist der Teil, den die meisten Anleitungen falsch darstellen.

Wessen Adresse das äußere Netz sieht, ist die Frage, die der Adaptermodus beantwortet. Ist das geklärt, hört Abdeckung auf, eine politische Frage zu sein, und wird eine mechanische. Alles Folgende ergibt sich aus diesen zwei Tatsachen.

NAT schreibt den Gast um, bis er wie der Host aussieht

Bei NAT schreibt der Hypervisor jedes Paket des Gastes auf die Adresse des Hosts um, bevor es den ersten Switch erreicht. Dieser Verkehr wird dann dem eigenen Netzwerk-Stack des Hosts übergeben, wo er dessen Routing-Tabelle folgt, einschließlich einer Standardroute, die einem Tunnel auf dem Host gehört. Ein NAT-Gast wird also ohne jede Konfiguration von einem Tunnel auf dem Host abgedeckt, was dem Gegenteil dessen entspricht, was der Fall Gast zu Host vermuten lässt.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Ein Gast, der einen eigenen Client ausführt, beendet diesen Tunnel im Gast, und der verschlüsselte Verkehr verlässt ihn dann über dieselbe Umschreibung, sodass Host-Anwendungen ihren eigenen Pfad und ihre eigene Ausgangsadresse behalten. VirtualBox besitzt in diesem Modus auch die Namensauflösung und reicht Gastabfragen durch seine eigene Engine weiter, solange --natdnshostresolver1 nicht aktiviert ist. Das Aktivieren übergibt die Suchanfragen des Gastes an den Resolver des Hosts, was die Auflösung korrigiert, wann immer die Sicht des Hosts richtig ist, und ebenso einen Resolver übergibt, der nur innerhalb eines Tunnels existieren mag. Die VM muss ausgeschaltet sein, bevor die Einstellung wechselt, und die Einstellung gehört zum Adapter und nicht zur Software des Gastes.

Bridge gibt dem Gast seine eigene Lease und seine eigene Exposition

Bridge reicht die Frames des Gastes auf das physische Segment weiter, sodass DHCP ihm eine Lease gibt und das Netz ihn als eigenen Host behandelt. Jeder gebrückte Gast kann einen unabhängigen Tunnel mit eigener Standardroute halten, und die Tabelle des Hosts ändert sich nie. Der Preis ist Exposition: der Gast antwortet auf Broadcasts, erscheint in Nachbartabellen und unterliegt Port-Sicherheit am Switch und Isolierung drahtloser Clients. Auch ein Tunnel auf dem Host deckt diese Anordnung nicht ab, weil Gast-Frames nie durch den Host-Stack laufen.

Dieser Unterschied zum NAT-Fall verdient es, klar gesagt zu werden, statt als Andeutung stehen zu bleiben. Ein gebrückter Gast braucht seinen eigenen Client und seine eigenen Zugangsdaten, sobald sein Verkehr einen Tunnel nutzen muss. Wo der Gast für das lokale Netz unsichtbar bleiben muss, ist NAT oder ein rein internes Netz mit kontrolliertem Routing das bessere Design.

Warum der Gast nicht das Gateway des Hosts sein kann

Einen Tunnel des Gastes an den Host zu verleihen hat in keinem der beiden großen Hypervisoren einen unterstützten Schalter. Der Host hat keine Route in den Tunnel des Gastes und keine Übersetzungsregel, die darauf zeigt, also bleiben Gast- und Host-Verkehr getrennte Ströme mit getrennten Eigentümern. Diese Richtung scheitert unabhängig vom Adaptermodus.

Die brauchbaren Ersatzlösungen sind Weiterleitungen und Proxys. Eine lokale SSH-Weiterleitung lässt den Host seine eigene Loopback-Adresse ansprechen, während der Gast den Strom in den Tunnel trägt, was TCP-Dienste abdeckt, ohne einen zweiten Client zu installieren. Den eigenen IP-Verkehr des Hosts stattdessen den Tunnel des Gastes nutzen zu lassen, verlangt einen Router im Gast plus eine ausdrückliche Host-Route und Übersetzung auf dem Host. Das ist ein kleines Netzwerkdesign und kein Häkchen, und es braucht einen Plan für den Rückweg. Wenn der Gast nur existiert, um den Client auszuführen, setz den Client auf den Host und lösche den zusätzlichen Sprung.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Resolver und Routen überschreiten die Grenze nicht

DNS folgt dem Adapter, der die Option erhalten hat, also erbt ein Gast nicht den Tunnel-Resolver des Hosts und ein Host erfährt nie den Server, der dem Gast zugeschoben wurde. Zugeschobene dhcp-option DNS-Werte gelten für die Schnittstelle, die sie angenommen hat, und deshalb kann ein gebrückter Gast ohne Client keine internen Namen auflösen. Ein NAT-Gast nutzt stattdessen normalerweise die DNS-Behandlung des Hypervisors, und der Unterschied zeigt sich in einem Befehl pro Umgebung.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Lies Resolver und Route im Gast, bevor du annimmst, eines von beiden folge dem Host. Füge den Tunnel-Resolver dem eigenen Adapter des Gastes hinzu, wenn interne Namen dort aufgelöst werden müssen, und prüfe dann mit einem Namen, der nur hinter dem Tunnel existiert. Halte Adaptermodus, Tunnel-Eigentümer und Resolver-Quelle für jede VM fest, weil diese drei Tatsachen fast jede spätere Frage beantworten. Andere Hypervisoren benennen die Modi um und lassen das Prinzip unangetastet.