Ein Linux-Konto per UID-Regel durch OpenVPN routen

Kontobasiertes Routing passt, wenn jeder IPv4-Socket eines Linux-Benutzers durch einen bestehenden Tunnel verlassen soll, und es passt nicht, wenn Sie Isolation auf Programmebene brauchen. Es wählt nach UID, also liegt alles im Bereich, was unter diesem Konto läuft, auch der vergessene Batch-Job. Klären Sie diese Frage, bevor Sie eine einzige ip rule anfassen.

Das Beispiel unten setzt ein eigenes Browserkonto mit UID 1500, ein Tunnelgerät tun-office mit lokaler Adresse 10.80.0.11 und ein VPN voraus, das die betreffenden Ziele erlaubt. Der Daemon selbst läuft außerhalb dieser UID.

Drei Bedingungen, die den Mechanismus wählen

Wählen Sie eine UID-Regel, wenn die Identität, die die Arbeit leistet, das Konto ist, wenn es akzeptabel ist, seinen gesamten Verkehr zu verschieben, und wenn ein Namespace schwerer wäre, als die Aufgabe verdient. Wählen Sie einen Netzwerk-Namespace, wenn die Arbeitslast eigene Schnittstellen, Resolver und Routingtabelle braucht. Wählen Sie einen Proxy oder eine Bindung pro Prozess wenn genau eine Anwendung wandern soll, während der Rest der Sitzung auf dem lokalen Pfad bleibt. Diese drei aufzuschreiben verhindert eine Regel, die still mehr abdeckt als beabsichtigt.

Der Fehler, den es zu vermeiden gilt, ist die Annahme, ein Starter lege den Eigentümer fest. Ein Browser, dem die Sitzung eines anderen Benutzers eine URL übergibt, hat keine Sockets unter UID 1500 erzeugt, und keine Regel verschiebt den Verkehr, den er erzeugt.

Die Tabelle, die Regel und der Wächter

Nach Prüfung bestehender Regeln und Wahl ungenutzter Tabellen- und Prioritätsnummern ist die Anordnung kurz: eine Standardroute in einer eigenen Tabelle, die die Quelladresse des Tunnels trägt, eine Regel, die die Abfragen des Kontos in diese Tabelle schickt, und eine abschließende Regel, die den Rückfall blockiert. Ausgeschrieben ist das ein idempotenter Routenersatz, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, gefolgt von ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Der Wächter ist ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, und er zählt mehr, als seine Länge vermuten lässt. Ohne ihn fällt eine fehlende Route in Tabelle 51820 auf den gewöhnlichen Uplink durch, und das Konto verliert still Verkehr, den die Richtlinie einfangen sollte. Mit ihm wird derselbe Fehler zu einem Timeout, also zu Blockieren statt Rückfall.

Halten Sie die normale Regel für lokale Adressen vor diesen, und entscheiden Sie bewusst, ob LAN- oder Verwaltungsausnahmen vor die gewählte Tabelle gehören. Eine dort gefundene Standardroute fragt danach nicht main nach einer spezifischeren LAN-Route, was Leute überrascht, die erwarten, dass die längste Präfixübereinstimmung über Tabellen hinweg gilt. Schreiben Sie die beabsichtigte Ausnahmeliste in die Änderungsnotiz, solange die Begründung noch frisch ist.

Was UID-Routing auslässt: DNS

Ein Resolver-Daemon öffnet seine Upstream-Sockets unter seiner eigenen UID, also verschiebt die Wahl von 1500 diese Abfragen nicht in Tabelle 51820. DNS-Integration ist eine eigene Entscheidung: Richten Sie das Konto auf einen durch den Tunnel erreichbaren Resolver, oder akzeptieren Sie, dass Namensauflösung dem Pfad des Hosts folgt, der Verkehr aber nicht.

Eine Loopback-Abfrage an einen lokalen Stub ist kein Beweis dafür, dass die Upstream-Abfrage die Route des Browsers genutzt hat, und ein erfolgreicher Seitenaufruf aus dem Cache auch nicht.

IPv6 braucht einen eigenen Satz im Entwurf

Die Regeln oben decken nur IPv4 ab. Wenn die Anforderung ein IPv4-Tunnel ohne direktes IPv6 von diesem Konto ist, ergänzen Sie eine geprüfte abschließende Regel wie ip -6 rule add priority 12101 uidrange 1500-1500 unreachable und prüfen Sie dann frühere IPv6-Regeln sowie die Loopback-Ausnahmen, die Sie behalten wollen.

Direktes IPv6 zu blockieren ist kein Dual-Stack-Tunneling; es ist eine Grenze. Es Tunneling zu nennen wird die nächste Person verwirren, die die Richtlinie liest, und die Verwirrung taucht als Support-Ticket über eine kaputte IPv6-Seite auf.

Prüfen Sie mit dem echten Konto und übernehmen Sie dann den Lebenszyklus

Vergleichen Sie Abfragen: ip -4 route get 198.51.100.25 uid 1500 gegen dasselbe Ziel mit einer gewöhnlichen UID. Stellen Sie dann eine erlaubte Anfrage unter dem eigenen Konto und prüfen Sie die Quelladresse, die die Gegenseite sieht. Eine bevorzugte Quelladresse ist kein Source-NAT und überschreibt keine Anwendung, die etwas anderes bindet. Wenn beide Abfragen denselben Pfad liefern, tut die Regel nicht, was Sie glauben.

Halten Sie Tabelle, Regeln und Lebensdauer der Tunnelroute unter einem Eigentümer, testen Sie eine Wiederverbindung und einen Tunnelverlust, und entfernen Sie beim Ausmustern der Richtlinie nur deren genaue Einträge. Ein Namespace steht weiterhin bereit, wenn getrennte Schnittstellen und getrennter Zustand das sind, was Sie wirklich brauchen.