Ein LAN-Subnetz durch OpenVPN leiten und die Standardroute behalten

Geräte, die für ein LAN routen und zugleich eine VPN-Verbindung aufbauen, geraten mit sich selbst in denselben Streit: Der Tunnel will die Standardroute besitzen, und das LAN braucht sie zurück. Wenn OpenVPN sich verbindet, kann es eine Standardroute durch den Tunnel oder ein Paar halber Standardrouten installieren, was für ein Notebook richtig und für ein Gateway falsch ist, dessen Nachbarn Antworten von seiner LAN-Adresse erwarten. Die Antwort ist nicht, das VPN auszulassen. Die Antwort ist, den beiden Entscheidungen verschiedene Tabellen zu geben.

Eine Standardroute, zwei Eigentümer

Weitergeleiteter Verkehr und lokal erzeugter Verkehr müssen nicht denselben Weg nehmen. LAN-Clients brauchen den Tunnel nur für die Ziele, die du auswählst, während die eigenen Verwaltungssitzungen des Hosts und seine Antworten an diese Clients die LAN-Standardroute brauchen. Beides in der Haupttabelle zu vermischen, erzwingt eine einzige Antwort auf zwei verschiedene Fragen.

OpenVPN hat genau dafür einen Schalter. route-noexec hindert den Client daran, die Haupttabelle überhaupt anzufassen, und die Werte, die er sonst verwendet hätte, werden an ein route-up-Skript als route_vpn_gateway, dev und die Interface-Adressen exportiert. Danach entscheidest du, welche Tabelle welche Route erhält, in Code, den du später lesen kannst.

Policy-Tabelle versus Umschreiben der Haupttabelle

Die separate Tabelle ist die einzige Option, die über ein Subnetz hinaus skaliert. Benenne sie einmal und verweise dann über den Namen darauf, damit sich niemand eine Zahl merken muss:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Die Adressen hier sind Platzhalter. Ersetze das LAN-Präfix, das Tunnel-Gateway und den Gerätenamen aus deiner eigenen Umgebung, bevor du irgendetwas ausführst.

Die Regel muss auch zum Host passen

Eine Regel, die nur auf das LAN-Präfix passt, deckt weitergeleitete Pakete ab. Sie deckt keinen Verkehr ab, den das Gateway selbst erzeugt, und auch nicht die Antworten, die es an LAN-Clients zurückschickt, die die LAN-Adresse des Gateways als Quelle tragen. Diese Lookups fallen auf main durch und können den Tunnel immer noch verlassen.

Füge eine zweite Regel für die eigene LAN-Adresse des Gateways hinzu oder erweitere die erste Regel zu einer Menge, die beide enthält. Die Reihenfolge zählt: Setze die spezifischere Regel zuerst und prüfe das Ergebnis mit einem Lookup, das die Quelle ausdrücklich nennt.

ip route get 203.0.113.9 from 192.168.50.1

Wenn das für ein Ziel, das lokal bleiben soll, das Tunnelgerät meldet, ist das Regelwerk falsch, egal was die Tabelle enthält.

NAT oder eine Route auf der Gegenseite

Der VPN-Server kennt das Tunnel-Subnetz und sonst nichts. Pakete, die mit einer LAN-Quelladresse ankommen, haben keinen Rückweg, sofern ihn niemand bereitstellt, und es gibt genau zwei Möglichkeiten, ihn bereitzustellen. Eine Route für das LAN-Präfix auf dem Server hält die ursprüngliche Quelle durchgehend sichtbar, was ein geprüftes Design normalerweise will. Maskierung auf dem Gateway schreibt die Quelle auf die Tunneladresse um und braucht keine Mithilfe des Servers.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Wähle NAT, wenn du den Server nicht kontrollierst und dort keine Routen hinzufügen kannst. Wähle die Route auf der Serverseite, wenn Protokolle, Zugriffskontrolle oder Rückwegsymmetrie zählen, denn Maskierung löscht die ursprüngliche Adresse aus allem, was die Gegenseite aufzeichnet.

So oder so muss die Weiterleitung aktiviert sein, und strikte Reverse-Path-Filterung kann die Antwort verwerfen, wenn main den Tunnel für diese Quelle nicht gewählt hätte. Prüfe den tatsächlichen Wert, bevor du dem Tunnel die Schuld gibst.

Den Split eine Neuverbindung überstehen lassen

Von Hand hinzugefügte Regeln und Routen verschwinden, wenn das Interface neu erstellt wird, und ein veralteter Tabelleneintrag kann die Sitzung überleben, die ihn gerechtfertigt hat. Lege die Tabellenregel, die Tunnelroute und den Maskierungseintrag in das route-up-Skript des Clients und leere die Tabelle am Anfang des Skripts, damit ein altes Gateway nicht in die neue Sitzung hinüberlebt.

Prüfe von beiden Enden: ein Lookup auf dem Gateway mit der LAN-Quelle und eine echte Anfrage von einem LAN-Client an ein Ziel, das den Tunnel passieren soll. Eine Route, die existiert, aber nie ausgewählt wird, verhält sich genau wie keine Route, bis du die Zähler liest.