Getrennter Ausgang: VPN-Pool auf usb0, Gateway-Verkehr auf eth0

Clients verbinden sich und authentifizieren sich, und dann verlässt ihr Verkehr den falschen Uplink, weil die einzige Standardroute auf dem Rechner dem Gateway selbst gehört. Diese Standardroute zu ersetzen würde die eigenen Updates und den Verwaltungszugang der Maschine brechen, also muss die Auswahl enger sein als „der gesamte Verkehr“. Die funktionierende Form ist eine Policy-Regel, die an der inneren Quelladresse des Client-Pools ansetzt und auf eine zweite Routing-Tabelle zeigt, der das alternative WAN gehört. Von da an geht es in der Checkliste um Vollständigkeit und Fehlerverhalten, nicht um die Regel selbst.

Bestätigen Sie, dass die Quelladresse bis zur Routing-Entscheidung erhalten bleibt

Eine Policy-Regel, die auf einen Quellbereich passt, greift nur, wenn das Paket diese Quelle zum Zeitpunkt der Suche noch trägt. Weitergeleiteter Client-Verkehr tut das, solange nichts weiter oben ihn vor dem Routing umgeschrieben hat. Verkehr, den das Gateway selbst erzeugt, tut das nicht, und genau deshalb kann die eigene Standardroute des Gateways bleiben, wo sie ist.

Hier führen lokale Tests in die Irre. Ein curl-Lauf auf dem Gateway ist ein lokal erzeugter Fluss mit der Adresse des Gateways, also nimmt er die Haupttabelle und beweist nichts über den Client-Pfad. Testen Sie von einem verbundenen Client aus, oder erzeugen Sie Verkehr mit einer Quelle, die tatsächlich zum Pool gehört.

Schreiben Sie zuerst die echten Werte auf: das Pool-Präfix, das Tunnel-Interface, das es trägt, Adresse und nächsten Hop des zweiten WAN sowie die Tabellennummer, die Sie verwenden wollen. Räumen Sie die alten Regeln aus jedem früheren Versuch auf, bevor Sie neue hinzufügen, denn doppelte Regeln mit unterschiedlichen Prioritäten erzeugen Fehler, die zufällig wirken.

Bauen Sie eine ausgewählte Tabelle, die vollständig ist

Eine Tabelle ist keine Standardroute mit einem Freund. Sie braucht genug Routen, dass jede Suche in ihr aufgelöst wird, einschließlich der verbundenen Route für das WAN-Subnetz, damit der nächste Hop erreichbar ist. Für einen Pool 10.77.0.0/24 auf tun1, eine WAN-Adresse 203.0.113.20/24 mit nächstem Hop 203.0.113.1 und Tabelle 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Die Regel liegt auf einer Priorität unterhalb jeder vorhandenen Catch-All-Regel, sodass passende Clients zuerst Tabelle 600 treffen und alles andere auf die Haupttabelle durchfällt. Die ip-rule-Referenz beschreibt das geordnete Suchmodell und die Selektor-Syntax vollständig.

Denken Sie dann daran, was die Tabelle nicht enthält. Ein Ziel, das nur in der Haupttabelle eine Route hat, etwa ein über eth0 erreichbares Verwaltungssubnetz, wird in Tabelle 600 nicht gefunden und fällt nicht auf die Haupttabelle zurück, sobald dort eine Standardroute existiert. Wenn diese Pfade wichtig sind, fügen Sie sie ausdrücklich der ausgewählten Tabelle hinzu, was für eine VPN-Ausgangstabelle meist die richtige Antwort ist.

Halten Sie den eigenen Verkehr des Listeners aus der Policy heraus

Der OpenVPN-Listener hat seine eigene äußere Verbindung, die über den Uplink läuft, über den der Client ihn erreicht hat. Dieser Verkehr muss den Rückweg behalten, mit dem er ankam, und eine breite Regel, die die öffentliche Adresse des Servers oder das gesamte Tunnel-Interface abdeckt, kann ihn in die alternative Tabelle ziehen. Beschränken Sie die Regel auf den inneren Pool und nichts sonst.

Die Reverse-Path-Filterung verdient aus demselben Grund einen Blick. Wenn Antworten an Clients über usb0 hinausgehen, während die Anfrage über eine andere Verbindung ankam, kann eine strenge rp_filter-Einstellung Pakete verwerfen, die die Routing-Policy als gültig ansieht. Prüfen Sie die effektiven sysctl-Werte auf beiden Interfaces, bevor Sie schließen, dass die Regel versagt hat.

Auch die Reihenfolge zählt gegenüber allem anderen auf dem Rechner. Docker-Bridges, ein zweites VPN und alle bestehenden Regeln aus einem Provider-Image bringen Prioritäten mit, also lesen Sie die vollständige Regelliste, statt anzunehmen, Priorität 100 stehe allein.

Bringen Sie Weiterleitung und Übersetzung mit der Route in Einklang

Routing wählt einen Uplink; es erteilt keine Erlaubnis zum Weiterleiten. Der Kernel muss IPv4-Weiterleitung aktiviert haben, und die Firewall muss die Richtung vom Client zum WAN und den Rückverkehr annehmen. Eine korrekte Tabelle mit einer FORWARD-Kette, die den Fluss verwirft, erzeugt dasselbe Symptom wie eine fehlende Route, deshalb werden beide im selben Durchgang geprüft.

Wenn das zweite WAN einen privaten Pool nicht zu Ihnen zurückroutet, übersetzen Sie die Quelle an diesem Ausgang. Für ein Interface mit dynamischer Adresse ist eine enge Masquerade-Regel, begrenzt auf Pool und Interface, die übliche Wahl:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Der Umfang ist hier wichtiger als das Ziel. Eine Masquerade-Regel, die auf jedes ausgehende Interface passt, schreibt auch Verkehr um, der korrekt über eth0 hinausgeht, und das verdeckt Routingfehler, statt sie zu beheben. Die Übersetzung läuft nach der Routing-Entscheidung, kann also nie ein Paket reparieren, das an den falschen Uplink geschickt wurde.

Der Tunnel-Overhead braucht ebenfalls Aufmerksamkeit, sobald die Pfade unterschiedlich sind. Wenn Clients eine große TCP-MSS aushandeln und das alternative WAN eine niedrigere MTU oder einen Tunnel darin hat, stocken große Segmente, während kleine funktionieren. MSS-Clamping auf dem Weiterleitungspfad macht daraus ein vorhersagbares Verhalten statt eines zeitweisen Hängers.

Entscheiden Sie, was passiert, wenn usb0 verschwindet

Eine leere Tabelle ist kein fail-closed-Zustand. Wenn die passende Route verschwindet, läuft die Suche zur nächsten Regel weiter, erreicht die Haupttabelle und nimmt die eth0-Standardroute. Verkehr, der über das zweite WAN hätte hinausgehen sollen, geht still über das erste hinaus, was bei einem policy-routed Deployment meist das Ergebnis ist, das Sie am wenigsten wollen.

Wo dieser Rückfall nicht akzeptabel ist, fügen Sie eine ausdrückliche Terminalroute in Tabelle 600 hinzu, etwa eine Blackhole-Standardroute, oder verwerfen Sie den Pool in der Firewall, solange das Interface unten ist. Beide Optionen sind eine Entscheidung, die Sie aufschreiben können; Schweigen ist es nicht.

Persistenz ist der letzte Punkt. Wer beide Verbindungen besitzt, ob Netzwerkmanager, Dispatcher-Skript oder Verbindungslebenszyklus, muss die Routen und die Regel bei jeder Wiederherstellung neu anlegen, ohne Duplikate anzuhängen. Prüfen Sie mit einer Anfrage von einem echten Client und einer separaten Anfrage vom Gateway, bestätigen Sie den beobachteten Ausgang bei beiden, ziehen Sie dann das zweite WAN ab und beobachten Sie, welches der beiden entworfenen Ergebnisse tatsächlich eintritt. IPv6 braucht seine eigene Tabelle, Regel und Übersetzung; die obige IPv4-Regel sagt nichts darüber.