Zwei OpenVPN-Clients auf einem Linux-Gateway: die Politik aufteilen

Zwei OpenVPN-Daemons können beide einen erfolgreichen Tunnel melden, während das Gateway jeden Client durch denselben schickt. Nichts im Handshake entscheidet, welchen Tunnel ein Client nutzt; das entscheidet der Kernel, Paket für Paket, indem er die Politikregeln und danach die Tabelle durchläuft, die jede Regel benennt. So betrachtet, geht es in der Konfiguration nicht mehr um OpenVPN-Optionen, sondern um eine Routing-Matrix mit zwei Eigentümern.

Der Kernel entscheidet, nicht der Daemon

Ein weitergeleitetes Paket kommt am LAN-Interface an, und der Routing-Code wertet die Regelliste in Prioritätsreihenfolge aus. Die erste Regel, deren Selektor passt, benennt eine Tabelle, und die Routen dieser Tabelle wählen das Ausgabegerät. Hat die Tabelle keine passende Route, läuft die Suche zur nächsten Regel weiter, und genau dieses Detail lässt eine halbfertige Einrichtung leise statt laut scheitern.

Der Tunnelprozess hat bei diesem Durchlauf nichts zu sagen. Er legt ein Interface an und kann Routen installieren, aber ob das Paket eines bestimmten Clients in dieses Interface gelangt, hängt ganz von der Tabelle ab, in die es geschickt wurde. Zwei Tunnel mit identisch importierten Routen konkurrieren daher, und der letzte Schreiber gewinnt für alle. Deshalb kann eine Einrichtung in den Konfigurationsdateien ausgewogen aussehen und trotzdem alle Clients durch einen Daemon schicken.

Geben Sie jeder Instanz ihren eigenen Ressourcensatz

Beginnen Sie mit Namen, denn wiederverwendete Namen sind der Weg, auf dem die beiden Instanzen versehentlich Zustand teilen. Vergeben Sie getrennte Tunnelgeräte, getrennte Konfigurationsdateien, getrennte Zugangsdaten und getrennte Service-Units. Halten Sie äußeren Endpunkt und Tunneladresse jeder Instanz in derselben Tabelle wie die Politik-Matrix fest, damit eine spätere Änderung eine Stelle zum Nachsehen hat.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull hält die vom Server geschobenen Routen aus der lokalen Tabelle heraus, was genau das ist, was Sie wollen, wenn die Politiktabelle explizit sein soll. Ob ein gegebener Server zusätzlich eine redirect-gateway-Option schiebt und ob Ihre Client-Version die Filterform unterstützt, sollten Sie im Handbuch nachlesen statt anzunehmen.

Schreiben Sie die Matrix: Quelle, Tabelle, Gerät

Fügen Sie für jede Client-Gruppe eine Regel hinzu, die eine Tabelle nach Quelladresse auswählt, und legen Sie dann den beabsichtigten Weg in diese Tabelle:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Die Tabelle braucht die Zielrouten, die die Gruppe haben soll, plus alle lokalen oder Verwaltungs-Ausnahmen, die das Gateway nutzbar halten. Eine Tabelle, die nur eine Default-Route enthält, ist eine Full-Tunnel-Politik für diese Gruppe, was genau richtig sein kann, aber es sollte eine Entscheidung sein und keine Auslassung.

Der eigene Transport des Tunnels ist in keiner Client-Gruppe

Die verschlüsselten Pakete jedes Daemons entstehen auf dem Gateway selbst und sind an den äußeren Peer adressiert. Eine Regel, die nur ein Client-Quellpräfix trifft, lässt diese Pakete in Ruhe, weshalb quellbeschränkte Regeln sicherer sind als Regeln, die alles treffen. Eine Regel ohne Selektor kann den eigenen Transport des Tunnels einfangen und ihn durch einen Tunnel zurückschicken, und die Verbindung scheitert dann auf eine Weise, die wie ein Anbieterproblem aussieht.

Halten Sie die lokale Verwaltungssitzung und den Underlay-Pfad ausdrücklich aus den Politiktabelle heraus. Schreiben Sie diese Ausnahmen neben die Matrix; sie gehören zum Entwurf und sind kein Notbehelf, der während eines Vorfalls neu entdeckt werden muss.

Einen Weg zu wählen erlaubt ihn nicht

Weiterleitungserlaubnis ist eine zweite Entscheidung, die später auf dem Weg fällt. Eine Firewall-Regel, die Pakete akzeptiert, die durch den zweiten Tunnel verlassen, bringt den Routing-Code nicht dazu, ihn zu wählen, und eine korrekte Tabelle erteilt keine Erlaubnis zum Weiterleiten. Beides muss vorhanden sein, und ein Test, der nur eines von beidem beweist, wird Sie über das andere täuschen. Wenn eine Gruppe funktioniert und die andere nicht, prüfen Sie diese beiden Schritte getrennt, statt die Tabellen neu zu schreiben.

Quellübersetzung ist eine dritte Entscheidung, und sie sollte auf die Quellgruppe und das Tunnelgerät begrenzt werden, das sie tatsächlich trägt. Fügen Sie eine eigene Kette für die beiden Instanzen hinzu, statt die postrouting-Kette zu leeren, denn unabhängige Dienste können dort Einträge haben, und ein Flush entfernt sie stillschweigend.

Was passiert, wenn ein Tunnel ausfällt

Entscheiden Sie das Fehlerverhalten im Voraus. Verliert eine Tunnel-Tabelle ihre Route, fällt die Suche zur nächsten Regel durch, und der Verkehr der Gruppe läuft ohne jeden Fehler über den anderen Tunnel oder den gewöhnlichen Uplink weiter. Ist das nicht akzeptabel, fügen Sie eine abschließende Regel mit niedrigerer Prioritätsnummer hinzu, die für diese Quelle ein unerreichbares Ergebnis zurückgibt, damit der Verlust sichtbar wird, statt aufgesogen zu werden.

Senden Sie eine frische Anfrage aus jeder Quellgruppe und halten Sie vier Fakten fest: die gewählte Tabelle, das Ausgabegerät, die übersetzte Quelle und ob die Antwort über denselben Weg zurückkam. Nehmen Sie dann einen Tunnel herunter und wiederholen Sie es. Zwei TUN-Geräte in einer Interface-Liste beweisen, dass beide Daemons gestartet sind; sie sagen nichts darüber, welchen ein gegebener Client benutzt hat. Der zweite Lauf, mit einem fehlenden Tunnel, ist der, der zeigt, ob Ihre Fallback-Regel das tut, was Sie beabsichtigt haben.