VPN auf dem Host oder in der VM betreiben? Entscheidungsleitfaden

Den Tunnel im Gast aufzubauen und ihn auf dem Host aufzubauen verändert beides die Adresse, die ein Browser meldet, und dort endet die Ähnlichkeit. Ein gaseigener Tunnel behält seine Schlüssel, seine Standardroute und seinen Resolver im Gastkernel, während der Host verschlüsselte Pakete an eine einzige Gegenstelle weiterleitet. Ein hosteigener Tunnel ist das Spiegelbild: Der Host-Client hält die Sitzung und setzt Routen und Richtlinien durch, und der Gast leiht sich, was herauskommt. Wählen Sie den falschen Eigentümer, und jedes spätere Symptom schickt Sie zur falschen Maschine. Zwei Befehle klären die Frage in etwa einer Minute, und der Rest dieses Leitfadens ist, was Sie mit der Antwort tun.

Legen Sie den Eigentümer fest, bevor Sie den Client anfassen

Die Regel betrifft, wo der Geheimtext entsteht, nicht, welche Maschine ein VPN-Symbol zeigt. Erzeugt ihn der Gast, braucht der Gast eine funktionierende Route zum VPN-Server und nichts Weiteres vom Host. Erzeugt ihn der Host, muss der Weg des Gasts über den Host jede Richtlinie überstehen, die der Host-Client dem lokalen Verkehr auferlegt.

Drei Fragen wählen die Platzierung meist für Sie. Muss der Verkehr des Gasts einen Unternehmens-Client auf dem Host überstehen? Dann gehört der Tunnel in den Gast. Brauchen mehrere Gäste eine Anmeldeinformation und eine Ausgangsadresse? Dann gehört er auf den Host, mit bewusst eingerichteter Weiterleitung. Soll der Verkehr des Gasts ganz außerhalb des Host-VPN bleiben? Dann ist ein Gasttunnel die einzige Anordnung, die Ihnen das konstruktionsbedingt liefert.

Notieren Sie die Antwort in einer Zeile neben dem VM-Namen: guest-owned oder host-owned. In einem Labor mit sechs Maschinen spart diese Notiz mehr Zeit als jeder Schritt unten, weil sie verhindert, dass Sie einen Tunnel debuggen, der nie in der Maschine war, an der Sie angemeldet sind.

WSL1 und WSL2 sind entgegengesetzte Fälle

WSL1 ist keine virtuelle Maschine, daher verflüchtigt sich die Platzierungsfrage meist. Seine Linux-Binärdateien laufen über eine Übersetzungsschicht gegen den Netzwerkstack von Windows, und ein Linux-VPN-Client hat keine eigenständigen Schnittstellen zu konfigurieren. Was funktioniert, ist ein Tunnel auf der Windows-Seite, wobei die Distribution das Ergebnis nutzt, ohne etwas zu besitzen.

WSL2 ist das Gegenteil. Es betreibt einen echten Kernel in einer leichten Utility-VM hinter einem virtuellen Hyper-V-Switch, und sein Adressraum wird über einen Adapter auf der Hostseite per NAT übersetzt. Ein Linux-Client in der Distribution verhält sich daher wie auf einer physischen Linux-Kiste: Er legt tun0 oder wg0 an, installiert eigene Routen und funktioniert. Der Fehler sitzt auf der Hostseite. Wenn sich ein Windows-VPN-Client mit einer Richtlinie verbindet, die Verkehr in lokalen Netzwerken blockiert, behandelt er das WSL2-Subnetz als nicht vertrauenswürdiges lokales Netz und kappt den NAT-Pfad. Die Distribution verliert dann DNS und ausgehenden Zugang, während ihr eigener Tunnel noch gesund ist: wg show meldet einen Handshake, ip route sieht korrekt aus, und curl hängt.

Welche Abhilfe Sie nutzen können, hängt vom Windows-Build ab. Die ältere ist eine Ausnahme im Host-Client für das WSL-Subnetz, hinzugefügt unter den Einstellungen des Clients für lokales Netzwerk oder Split-Tunnel. Die neuere, auf Windows 11-Builds, die sie unterstützen, ist gespiegeltes Netzwerken: Setzen Sie networkingMode=mirrored in den Abschnitt [wsl2] von %UserProfile%\.wslconfig, führen Sie wsl --shutdown aus, und die Distribution teilt die Schnittstellen des Hosts statt eines privaten NAT-Subnetzes. Der gespiegelte Modus ändert auch das Verhalten von localhost und eingehenden Ports, behandeln Sie ihn also als Migration und nicht als Schalter.

NAT, Bridge und was der Host sehen kann

Unter NAT sind die Tunnelpakete des Gasts an die öffentliche Adresse des VPN-Servers adressiert und verlassen den Host-Adapter als verschlüsseltes UDP oder TCP. Der Host sieht einen Datenstrom und dessen Bytezahl, nichts über die Ziele darin. Unter einem gebrückten Adapter hat der Gast seine eigene Identität auf Schicht 2 im physischen LAN, bezieht eine eigene DHCP-Lease und wirkt für jede MAC-basierte Richtlinie wie ein zweites Gerät. Keiner der Modi lässt den Host die Tunnel-Nutzlast lesen; der gebrückte Gast ist für das Netz um ihn herum schlicht viel sichtbarer.

Auch die Isolation hat eine Untergrenze. Ein Gast kann sich nicht vor der Maschine verstecken, der sein Speicher gehört, und wer den Host kontrolliert, kann Schlüssel aus dem RAM des Gasts lesen. Was ein Gasttunnel Ihnen gibt, ist eine Routing- und eine Malware-Grenze, kein Schutz vor der Person, die das Laptop hält. Die dokumentierten Adaptermodi sollten Sie beim Auswählen offen haben, da der Modus sowohl ändert, was der Host sieht, als auch, was das LAN sieht.

Leitfaden: platzieren, konfigurieren, beweisen

Führen Sie diese vier Prüfungen der Reihe nach in einer frischen Gast-Shell aus und stoppen Sie bei der ersten, die dem notierten Eigentümer widerspricht.

1. ip route get 1.1.1.1 mit tun0 oder wg0 bedeutet gaseigen, eth0 mit einem privaten nächsten Hop bedeutet hosteigen.
2. resolvectl query example.com, oder lesen Sie /etc/resolv.conf dort, wo der Gast keinen Resolver-Dienst betreibt. Ein Tunnel, der Verkehr, aber kein DNS trägt, ist der häufigste halb konfigurierte Zustand.
3. Vergleichen Sie die Ausgänge: curl -4 -s https://ifconfig.me im Gast gegen curl.exe -4 -s https://ifconfig.me auf dem Host. Unterschiedliche Adressen bedeuten, dass der Gast den Tunnel besitzt, und ein Host im VPN mit einem Gast, der den Heim-ISP zeigt, ist der Fall, in dem nichts geerbt wurde.
4. Wiederholen Sie beides mit -6. Ein reiner v4-Tunnel leckt v6, es sei denn der Client blockiert oder routet es, und viele Clients lassen v6 standardmäßig auf der physischen Schnittstelle.

Bei einem Host-Gateway-Design, bei dem mehrere Gäste einen Tunnel teilen, muss der Host weiterleiten und übersetzen. Auf einem Linux-Host sind das drei Teile, und der Gast fällt still auf seine einfache Route zurück, wenn einer davon fehlt:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Auf der WireGuard-Seite muss AllowedIPs des Host-Peers das Gast-Subnetz enthalten, zum Beispiel 192.168.122.0/24, sonst kommen die Rückpakete nie an und das Setup sieht wie ein Firewall-Problem aus. Ein Windows-Host erreicht dasselbe mit Internet Connection Sharing oder einer NAT-Regel am Hyper-V-Switch und braucht dieselbe Prüfung des Rückwegs.

Wenn das Layout noch offen ist, deckt diese Tabelle die häufigsten Anordnungen ab:

Zwei Tunnel, zwei Gäste und die Konflikte dazwischen

Wenn Sie zwei Ausgänge gleichzeitig brauchen, ist das Muster, das hält, ein Tunnel pro Gast. Jede VM behält ihre Standardroute und ihren Resolver, der Host bleibt im gewöhnlichen Netz, und die beiden Tunnel streiten nie über dieselbe Routingtabelle. Zwei Gäste zu brücken bündelt ihre Routen ebenfalls nicht: Das virtuelle Netz liefert einen Pfad, und jedem Client muss weiterhin gesagt werden, dass dieser lokale Verkehr den Tunnel umgehen darf.

Einen Host-Tunnel und einen Gast-Tunnel zusammen zu betreiben ist legitim, und bewusstes Verschachteln ist manchmal genau das, was Sie wollen, wobei der Gast über seinen eigenen Tunnel hinausgeht und dieser Tunnel über den des Hosts. Was es zum Ausfall macht, ist, dass niemand notiert hat, welcher Endpunkt über welche Schicht erreicht werden soll. Führen Sie eine Zweispaltenliste aus Ziel und Eigentümer, und ein Routenkonflikt wird zu einem Nachschlagen statt zu einem Nachmittag voller Entdeckungen.

Prüfen, dann die Wiederherstellung beim Eigentümer lassen

Testen Sie aus dem Gast heraus mit einem frischen Anwendungsprozess: Verkehr, Namensauflösung, beide Adressfamilien und was passiert, wenn der Tunnel wegbricht. Das VPN-Symbol des Hosts sagt nichts über die Abdeckung des Gasts, und das ist die häufigste falsche Bestätigung in diesem ganzen Bereich.

Auch die Wiederherstellung gehört dem Eigentümer. Ein gaseigener Tunnel wird durch den eigenen Client des Gasts und die von ihm geschriebenen Routen wiederhergestellt. Ein hosteigenes Design wird durch die Boot-Sequenz des Hosts wiederhergestellt, und die Weiterleitungsregeln überleben einen Neustart nicht, es sei denn eine Unit oder eine Startaufgabe wendet sie erneut an. Ein wiederhergestellter Snapshot ist ein Deployment, keine Rückgängigmachung, denn er bringt alte Anmeldeinformationen und alte Routen zusammen mit der Festplatte zurück. Bevor Sie die Arbeit als erledigt bezeichnen, bestätigen Sie, dass der Eigentümer noch zu der notierten Zeile passt, dass DNS und beide Adressfamilien im Gast auflösen, dass ein toter Tunnel ein nutzbares Netz statt eines schwarzen Lochs hinterlässt und dass ein Neustart oder eine Snapshot-Wiederherstellung denselben Zustand reproduziert.