Nur ein privates Subnetz durch das VPN schicken

Ein privates Subnetz durch den Tunnel und alles andere über den normalen Weg ist ein kleiner Wunsch mit sehr vielen Möglichkeiten, ihn falsch umzusetzen. Entscheidend ist nicht das Kontrollkästchen namens Split Tunneling, sondern wo die Entscheidung durchgesetzt wird: in der Routentabelle des Clients, in einer vom Server gepushten Route oder in einer Richtlinie, die beide Enden aushandeln. Wählen Sie die falsche Ebene, bekommen Sie entweder einen vollständigen Tunnel, den Sie nie wollten, oder eine Route in einen Tunnel, den die Gegenseite nicht annimmt. Ich prüfe vor dem Öffnen jeder Konfiguration drei Bedingungen und wähle dann einen der Mechanismen unten.

Drei Bedingungen, die das Design entscheiden

Erstens brauchen Sie das genaue Präfix und die Maske vom Netzwerkverantwortlichen. Das Netz 10.x ist kein Präfix; 10.20.0.0/16 ist eines. Prüfen Sie, dass es sich nicht mit Ihrem Heim-LAN, einer Docker-Bridge oder einem anderen VPN überschneidet, denn eine Überschneidung macht die Route mehrdeutig, und der Kernel wählt den Eintrag, den Sie nicht gemeint haben.

Zweitens: Wer beantwortet den Rückverkehr. Ein Paket in den Tunnel zu routen bringt es nur zum VPN-Server. Liegt das Subnetz hinter einem anderen Router ohne Rückroute zu Ihrem Client-Pool, muss der Server den Verkehr maskieren, oder dieser Router muss Ihren Pool lernen. Keine clientseitige Route behebt einen fehlenden Rückweg.

Drittens: der Durchsetzungspunkt. Manche Clients installieren eine Route, und das Betriebssystem erledigt den Rest. Andere handeln eine Richtlinie aus, und eine Richtlinie, die das Gateway nicht akzeptiert, erzeugt überhaupt keinen Tunnel: Pakete werden ohne erkennbaren Fehler verworfen. Finden Sie vor dem Schreiben irgendetwas heraus, welcher der beiden Fälle Ihrer ist.

WireGuard: AllowedIPs ist die Routentabelle

Auf dem Client listet AllowedIPs die Ziele, die in den Tunnel dürfen, und wg-quick macht aus jedem Eintrag eine gewöhnliche Route. Die Client-Hälfte dieser Aufgabe ist also eine Zeile.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Vergleichen Sie nun den Eintrag des Servers für denselben Client. Er beschreibt, was der Server an den Client sendet, und das ist normalerweise die Tunneladresse des Clients, nicht das private Subnetz.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Diese beiden zu vertauschen ist der Fehler, den ich am häufigsten sehe. 10.20.0.0/16 im peer-Abschnitt des Servers zu setzen behauptet, das ganze Subnetz liege hinter diesem Client, und das ist ein Site-to-Site-Anspruch, keine Erlaubnis. Pakete, die zu keinem AllowedIPs eines Peers passen, werden still verworfen, ein falscher Eintrag sieht also genau wie ein Firewall-Problem aus.

Wenn Sie die Routen selbst verwalten, setzen Sie Table = off unter [Interface] und fügen die gewünschte Route hinzu. Dann wird nichts automatisch eingetragen, die Route gehört also dorthin, was das Interface hochbringt.

OpenVPN: die Route pushen und prüfen, dass sie ankommt

Auf einem normalen Server ist die Änderung eine Anweisung in der Serverkonfiguration, neben dem Client-Pool.

push "route 10.20.0.0 255.255.0.0"

Der Client fügt sie beim Verbinden hinzu. Der Fehlerfall zeigt sich, wenn dasselbe Profil auch redirect-gateway pusht oder wenn jemand bereits route-nopull gesetzt hat: Ersteres macht die Sitzung zu einem vollständigen Tunnel, Letzteres verwirft jede gepushte Route, auch Ihre.

Ein Client, der gegenüber einem Volltunnel-Server enges Verhalten braucht, sollte nur die Teile ignorieren, die er nicht will. In OpenVPN 2.4 und später gibt es pull-filter genau dafür.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Halten Sie Adressfamilien getrennt: Eine gepushte IPv4-Route bewirkt nichts für einen internen Dienst, der zu IPv6 auflöst, und dieser Dienst scheitert über den Tunnel, während alles andere in Ordnung aussieht.

Liegt das private Subnetz nicht auf dem VPN-Server, sondern hinter einem anderen Client, muss der Server es wissen. Fügen Sie über client-config-dir eine Datei pro Client mit iroute 10.20.0.0 255.255.0.0 hinzu, dazu die passende route, damit andere Clients den Weg lernen. Ohne iroute hat der Server keinen Grund, dieses Präfix gerade durch diesen Tunnel zu senden.

IPsec: die Traffic-Selektoren müssen übereinstimmen

Bei IPsec gibt es keine Route zum Pushen. Die beiden Enden handeln aus, welche Adressen im Tunnel liegen, und Verkehr außerhalb der vereinbarten Selektoren wird weder verschlüsselt noch hindurchgesendet. Bei einem strongSwan-Client sind die Selektoren ausdrücklich gesetzt.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ist das Gateway auf beiden Seiten mit 0.0.0.0/0 konfiguriert, verkleinert die IKEv2-Verengung die Child-SA meist auf die Schnittmenge der beiden Vorschläge, was dem gewünschten Ergebnis entspricht. Manche Gateways lehnen dagegen einen Vorschlag ab, der nicht zu ihren konfigurierten Selektoren passt, und das Protokoll zeigt dann eine fehlgeschlagene Child-SA statt einer Routing-Beschwerde. In diesem Fall gehört die Änderung auf das Gateway, denn eine Client-Route kann keinen Tunnel für einen Selektor erzeugen, den die Gegenseite nicht akzeptiert.

Unter Windows verbirgt der eingebaute Client dieselbe Entscheidung hinter zwei Einstellungen. Split Tunneling muss an sein, und das Präfix muss am Profil registriert werden.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Die Registrierung des Präfixes ist es, was es ein Wiederverbinden überstehen lässt, was eine von Hand gesetzte Route nicht tut.

Endpunkt und DNS aus der Entscheidung heraushalten

Der VPN-Endpunkt muss ohne den Tunnel erreichbar bleiben, sonst fällt der Tunnel in sich zusammen. Wird nur 10.20.0.0/16 geroutet, ist das automatisch so, da der Endpunkt eine öffentliche Adresse ist. Bei einem Volltunnel-Profil ist es das nicht, und der Client braucht eine ausdrückliche Host-Route zum Endpunkt, bevor der Tunnel hochkommt.

DNS ist eine zweite Entscheidung, die ein Routen-Push nicht für Sie trifft. Interne Namen lösen meist über einen Resolver auf, den nur das private Netz erreicht. Pusht der Server einen DNS-Server, läuft jeder Name darüber; tut er es nicht, schlagen interne Namen entweder fehl oder lösen öffentlich zu etwas auf, das Sie nicht gemeint haben. Geteiltes DNS hält eine Suchdomäne auf dem internen Resolver, doch das hängt von der Client-Unterstützung ab, behandeln Sie es also als eigene Aufgabe und nicht als Nebenwirkung des Routings.

Prüfen, dann neu starten und erneut prüfen

Drei Sonden decken die Routing-Frage ab. Fragen Sie den Kernel, wohin eine entfernte Adresse ginge, holen Sie etwas aus dem Inneren des Subnetzes und bestätigen Sie dann, dass eine gewöhnliche öffentliche Anfrage weiterhin über Ihre normale Verbindung hinausgeht.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Die erste Zeile nennt ein Interface. Nennt sie Ihr physisches Interface, ist die Route nie angekommen. Unter Windows beantwortet Find-NetRoute -RemoteIPAddress 10.20.5.7 dieselbe Frage, und die letzte Sonde sollte weiterhin Ihre gewöhnliche Adresse zeigen und nicht die des VPN-Servers.

Starten Sie dann neu. Von Hand gesetzte Routen verschwinden, Routen aus dem Profil, aus einer gepushten Konfiguration oder aus AllowedIPs kommen zurück. Funktioniert der enge Zugang vor dem Neustart und scheitert danach, liegt der Fehler darin, wie der Tunnel startet, nicht in der Route selbst.

Bevor Sie es als fertig bezeichnen, bestätigen Sie vier Dinge: Das Präfix kam vom Netzwerkverantwortlichen und überschneidet sich mit nichts Lokalem, der Rückweg existiert oder eine Maskerade-Regel ersetzt ihn, der konfigurierte Mechanismus ist derjenige, der Routing auf Ihrer Plattform durchsetzt, und dieselben Sonden bestehen nach einem sauberen Neustart. Die Weiterleitungsnotizen von strongSwan sind eine Lektüre wert, wenn der Rückweg der Teil ist, der immer wieder scheitert.