NAT oder gebrücktes VM-Netzwerk: Welches trägt den VPN-Verkehr?

Gebrückt und NAT sind keine zwei Arten, denselben Gast an dein VPN anzubinden; sie entscheiden, wem die Pakete des Gasts gehören, bevor überhaupt ein Tunnel im Spiel ist. Im NAT-Modus schreibt der Hypervisor den Verkehr des Gasts um und sendet ihn aus Code auf der Hostseite, sodass der Gast die Route nutzt, die der Host diesem Code gibt. Im gebrückten Modus bekommt der Gast eine eigene Identität auf der Link-Ebene im physischen Segment und wählt sein eigenes Standard-Gateway, was den Tunnel des Hosts für ihn irrelevant macht – es sei denn, der LAN-Router tunnelt selbst. Ich habe aufgehört, die VM als Teil des VPN zu betrachten, und angefangen, es als Frage danach zu behandeln, wohin die Standardroute des Gasts zeigt. Der Test unten dauert ein paar Minuten pro Modus und klärt es ohne Rätselraten.

NAT hält den Gast hinter Hypervisor-Code, wo die Routen des Hosts gelten

In VirtualBox sitzt ein NAT-Gast auf 10.0.2.0/24 mit einem virtuellen Gateway bei 10.0.2.2, einem DNS-Proxy bei 10.0.2.3 und keiner eigenen Route ins physische Netz. Ausgehende Pakete nimmt die NAT-Engine, schreibt sie so um, dass die Quelle der Host ist, und übergibt sie an den IP-Stack des Hosts. Von dort ist der Verkehr des Gasts ein Host-Flow, und die Routensuche erfolgt nach Ziel: Ein Full-Tunnel-Client, der 0.0.0.0/1 und 128.0.0.0/1 auf dem Host installiert, fängt ihn ab, ohne je zu wissen, dass es eine VM gibt. Oracles Kapitel zur VirtualBox-Netzwerkkonfiguration listet diese Standardwerte, wenn du die Adressen in deinem Build bestätigen willst.

Das Standardnetz von libvirt erreicht dasselbe von 192.168.122.0/24 aus, wo dnsmasq Leases verteilt und der Host das Subnetz maskiert, sodass die Pakete des Gasts wieder bei der Routing-Entscheidung des Hosts ankommen. Die Ausnahme ist ein Client, der Verkehr nach Prozess statt nach Route auswählt. Enthält die Split-Tunnel-Liste nur deinen Browser und sonst nichts, ist die NAT-Engine nicht auf dieser Liste, und der Gast verlässt die Maschine ungetunnelt, während der Browser des Hosts weiter abgedeckt aussieht. Gleiches Subnetz, entgegengesetztes Ergebnis.

Gebrückt gibt dem Gast seinen eigenen Platz im physischen LAN

Ein gebrückter Gast bekommt eine virtuelle Netzwerkkarte, die an einen echten Adapter gebunden ist, erhält eine eigene MAC-Adresse und holt sich ein DHCP-Lease aus dem physischen Netz. Sein Standard-Gateway ist der LAN-Router, nicht der Hypervisor, und seine Frames gehen über diesen Adapter auf die Leitung. Die Tunnelrouten des Hosts liegen in der Tabelle des Hosts und werden nie befragt, weil die Frames des Gasts nie in den IP-Stack des Hosts gelangen.

Das schneidet in beide Richtungen. mDNS und SMB-Browsing funktionieren plötzlich, weil der Gast LAN-Broadcast-Verkehr sieht, und der Gast wird von anderen Maschinen im selben Segment erreichbar, ohne dass eine Host-Firewall dazwischen liegt. Bridging ist auch kein Weg, einen Gast durch einen bestehenden Tunnel zu schieben: Eine VM an das WireGuard- oder OpenVPN-Interface des Hosts zu hängen, ist nichts, was VirtualBox oder libvirt für dich erledigen. Muss ein gebrückter Gast getunnelt werden, muss der Tunnel irgendwo in diesem LAN enden.

Der Test, der die Debatte beendet

Führe dieselben Prüfungen in beiden Modi durch und schreibe die Antworten auf:

• Auf dem Host liefert curl -s https://ifconfig.me die öffentliche v4-Adresse.
• Im Gast derselbe Befehl, dazu ip route unter Linux oder Get-NetRoute -DestinationPrefix 0.0.0.0/0 unter Windows für das Standard-Gateway.
• Resolver-Identität: resolvectl status oder cat /etc/resolv.conf im Gast, um zu sehen, ob er auf 10.0.2.3 oder auf einen LAN-Server zeigt.
• Adressfamilie: ip -6 addr show scope global und eine v6-Anfrage, weil ein v4-Tunnel nichts über eine globale v6-Adresse aussagt, die der Gast haben mag.

Übereinstimmende öffentliche Adressen bedeuten, dass der Gast auf dem Pfad des Hosts liegt. Eine Gastadresse, die dem gewöhnlichen Ausgang des LANs entspricht, bedeutet das Gegenteil. Der Schritt, den Leute auslassen, ist die Kontrolle: Fahr den Tunnel des Hosts herunter und wiederhole die Anfrage aus dem Gast. Surft der Gast weiter, hing er nie vom Tunnel des Hosts ab, was der Modusname auch nahelegen mag. Im NAT-Modus sollte der Gast ohne den Tunnel des Hosts kein Internet mehr haben – es sei denn, der Client ist so konfiguriert, dass er ungetunnelten Verkehr zulässt, was für sich genommen schon wissenswert ist.

Zwei Signale lügen. Ein erfolgreicher Ping beweist Erreichbarkeit, nicht den Ausgangspfad. Und DNS kann vom 10.0.2.3-Proxy über den Resolver des Hosts beantwortet werden, während TCP eine andere Route nimmt – so bekommt man eine Seite, die lädt, und ein Login, das nie fertig wird.

Welcher Modus zur Aufgabe passt

Der Modus ist eine Routing-Entscheidung, also wähle ihn nach der Anforderung statt nach Gewohnheit:

Zeile eins ist die Stelle, an der Leute erwischt werden: NAT plus ein Full-Tunnel-Hostclient deckt einen Gast tatsächlich ab, aber nur solange der Client per Route tunnelt und der Uplink des Hosts dieser Tunnel ist. Verschiebst du den Client auf eine Allowlist nur für den Browser, verschwindet die Abdeckung ohne Fehlermeldung irgendwo. Zeile vier ist der umgekehrte Fehler: ein Gast, der aus Bequemlichkeit gebrückt wird und still anfängt, SMB oder SSH im Büro-LAN zu beantworten.

Fehler, die dem VPN angelastet werden

Unter Windows läuft die NAT-Übersetzung im VirtualBox-VM-Prozess, ein Per-App-Client braucht also genau dieses Image auf seiner Liste statt einer pauschalen Regel für virtuelle Maschinen. Wenn ein Client-Update seine Prozess-Allowlist neu baut, verlieren NAT-Gäste zuerst die Abdeckung, und der Bericht liest sich wie eine VM, die das LAN, aber nicht das Internet erreicht, während der Host in Ordnung ist.

Bridging auf Wi-Fi ist der andere Klassiker. Access Points leiten selten Frames mit fremder Quell-MAC weiter, sodass eine Bridge auf wlan0 entweder ganz scheitert oder funktioniert, bis die Client-Isolation am AP sie fallen lässt. VirtualBox bietet den WLAN-Adapter trotzdem in seiner Liste an. Steht der Host im WLAN und muss der Gast gebrückt werden, plane einen Test ein, statt es anzunehmen.

MTU ist der dritte Punkt. Ein gebrückter Gast behält die 1500-Byte-MTU des LANs, und wenn er einen eigenen WireGuard-Client auf 1420 betreibt, stocken große TLS-Handshakes, während kleine Anfragen durchgehen. Unter NAT ist die MTU des Host-Tunnels das Problem des Hosts, aber der Gast glaubt weiter an 1500, und UDP mit gesetztem Don't-Fragment-Bit verschwindet genauso im Nichts.

Modus notieren und nach jedem Adapterwechsel erneut prüfen

Halte den Modus, das vom Bridge genutzte Host-Interface, das Standard-Gateway des Gasts, seinen Resolver und seine v4- und v6-Ausgangsadressen fest. Dieser Eintrag macht den nächsten Fehler billig: Wenn ein Laptop vom Dock ins WLAN wandert, folgt ein gebrückter Gast der Bridge zu einem anderen physischen Adapter und holt sich womöglich ein Lease in einem anderen Subnetz, während ein NAT-Gast seine 10.0.2.x-Adresse behält und still einen anderen Uplink erbt.

Bevor du das Ticket schließt, bestätige jeden dieser Punkte:

• Die Ausgangsadresse des Gasts unterscheidet sich von der des Hosts, er liegt also nicht auf dem Host-Tunnel.
• Der Resolver ist der 10.0.2.3-Proxy oder ein LAN-Server, und du weißt, welcher geantwortet hat.
• Es existiert keine globale v6-Adresse im Gast, wenn das Tunneling-Konzept nur v4 ist.
• Mit heruntergefahrenem Host-Tunnel hört der Gast auf zu surfen, oder du weißt jetzt, dass er nie davon abhing.
• Der Gast sieht keinen LAN-Broadcast-Verkehr, der ihn nichts angeht.