Firmen-VPN innerhalb von WireGuard: Welche Schicht kommt zuerst?

Zwei Clients auf einem Rechner funktionieren nur, wenn der äußere Tunnel den eigenen Endpunkt des inneren Clients trägt und Metriken für jedes Präfix die richtige Schnittstelle wählen.

Für verschachtelte Tunnel auf einem Entwickler-Laptop gibt es zwei legitime Gründe. Entweder muss der Firmen-Client so erscheinen, als käme er aus einem bestimmten Land, oder zwei private Netze müssen gleichzeitig erreichbar sein. In beiden Fällen muss der äußere Tunnel die eigene Verbindung des inneren Clients tragen.

Zwei Clients in irgendeiner Reihenfolge zu starten, leistet das nicht. Das Routing leistet es.

Vergleichen Sie die beiden möglichen Reihenfolgen

Wählen Sie die äußere Schicht als den Tunnel, dessen Endpunkt das öffentliche Internet erreichen kann. Die innere Schicht ist der Tunnel, dessen Server nur über diesen Ausgang antwortet. Unter Windows ist die praktische Aufteilung WireGuard außen und der Firmen-Client innen. Der entscheidende Faktor ist Kontrolle.

Der offizielle WireGuard-Client wendet eine vollständige Konfigurationsdatei an, einschließlich Routen und DNS. Kommerzielle Firmen-Clients verbergen beides meist. Setzt man einen verborgenen Client nach außen, bleibt man beim Raten über den darunterliegenden Pfad.

Die umgekehrte Reihenfolge ist nicht unmöglich. Sie ist nur schwerer zu durchdenken, weil der äußere Client Routen nach einem Zeitplan umschreibt, den man nie sieht.

Lassen Sie AllowedIPs nur den Firmenbereich benennen

AllowedIPs listet die Ziele auf, die WireGuard in den Tunnel leitet. Für die Verschachtelung braucht es nur die Adresse des inneren Servers und die Firmen-Präfixe. Alles andere bleibt im lokalen Netz, Drucker und Hypervisor eingeschlossen. Das ist ein Split-Tunnel per Design, und er vermeidet das Ausschlussproblem vollständig.

Eine äußere Schicht als Full-Tunnel braucht 0.0.0.0/0 abzüglich der lokalen Bereiche. Das Format kann keinen Ausschluss ausdrücken, also muss das Komplement berechnet und eingefügt werden.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

Wenn der innere Client keine eigenen Routen installiert, listen Sie die Firmen-Präfixe selbst auf. Ein Präfix, das in dieser Zeile fehlt, ist ein Ziel, das der äußere Tunnel nie trägt. Eine veraltete Kopie der Liste ist schlimmer als keine, weil sie noch korrekt aussieht.

Reihenfolge, Metriken und der zweite Adapter

Verbinden Sie zuerst den äußeren Tunnel und starten Sie dann den Firmen-Client. Dessen Endpunktverbindung geht dann über WireGuard statt über das lokale Gateway. Geben Sie der Firmenschnittstelle eine niedrigere Metrik, damit ihre Präfixe für die Adressen gewinnen, die sie besitzt.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Metriken sind der Schritt, den Leute überspringen. Ohne eine Reihenfolge gewinnt für das überlappende Präfix die zuletzt installierte Route. Das ändert sich zwischen Neustarts, deshalb wirkt das Problem sporadisch.

Auf OpenVPN 2.6 aufbauende Clients fügen eine eigene Falle hinzu. Wenn der Adapter für das Offloading des Datenkanals bereits belegt ist, weigert sich eine zweite Instanz einfach zu starten. Das Hinzufügen von disable-dco zum Profil fällt auf den älteren TAP-Pfad zurück, und dann laufen beide nebeneinander.

Wo der verschachtelte Pfad bricht

Das Trennen des äußeren Tunnels tötet den inneren. Verbindet man nur den inneren Client neu, schickt er ihn oft direkt ins Internet und entfernt die Verschachtelung still. Testen Sie die Reihenfolge jedes Mal von Grund auf, mit beiden gestoppten Tunneln.

Erwarten Sie eine kleinere nutzbare MTU. Jede Schicht fügt Overhead hinzu, ein Startpaar um 1420 und 1400 ist also ein Anfang. Eine Übertragung, die bei großen Paketen hängt, während kleine Anfragen durchgehen, ist das übliche Kennzeichen. Die Firmenrichtlinie ist die andere Grenze, denn ein Client, der ein verwaltetes Gerät verlangt, kann einen verschachtelten Pfad als Verstoß werten.

Wenn beide Enden feste Netze sind, beseitigt ein Site-to-Site-Tunnel zwischen den Gateways das Reihenfolgeproblem, statt es zu verwalten. Auf einem Laptop koexistieren zwei Tunnel nur, wenn jeder seine eigene Schnittstelle hat und eine Regel Ziele pro Präfix auswählt.

Ähnliche Artikel