Gleiche Server-IP, zwei Wege: der äußere Flow von OpenVPN wird markiert

Der übliche Schleifenschutz ist eine Host-Route: Verkehr an die öffentliche Adresse des VPN-Servers geht über den Uplink hinaus, damit die verschlüsselte Sitzung nie in ihren eigenen Tunnel gelangt. Das funktioniert genau bis zu dem Moment, in dem du auch einen Webdienst auf demselben Server über den Tunnel erreichen willst, denn die Ausnahme hängt am Ziel, und das Ziel ist identisch. Der Ausweg besteht darin, nicht mehr nach dem Ziel zu klassifizieren, sondern danach, welcher Socket das Paket gesendet hat.

Beginne mit den zwei Flows, die du trennen willst

Der eine Flow ist der verschlüsselte OpenVPN-Transport selbst, der über den Uplink hinausgehen muss, sonst würde der Tunnel seine eigene äußere Verbindung tragen. Der andere ist eine gewöhnliche HTTPS-Anfrage an dieselbe öffentliche Adresse, die du im Tunnel haben willst, damit sie mit einer Tunnelquelle beim Dienst ankommt. Gleiches Ziel, in vielen Fällen gleiche Portnummer, anderer erforderlicher Weg.

Für diesen Durchgang nehmen wir einen Client auf 10.90.0.10 über tun1 an, eine öffentliche Serveradresse von 198.51.100.25 und eine unberührte Haupttabelle, deren Standard auf den gewöhnlichen Uplink zeigt. Die Serverseite muss den Webdienst außerdem auf dem inneren Weg annehmen und Verkehr an die Tunnelquelle zurückschicken; ein Paket an eine öffentliche Adresse zu senden hebt weder den Listener noch die Firewall-Regeln des Servers auf.

Bevor du etwas änderst, sichere die aktuellen Regeln des Hosts und wähle Werte, die niemand sonst verwendet: eine Marke, eine Tabellennummer und drei Regelprioritäten. Halte einen Zugang zurück in die Maschine offen, der nicht über diese Verbindung läuft, denn ein Fehler hier nimmt dir deinen eigenen Fernzugriff, statt nur einen Browser-Tab zu zerlegen.

Markiere den Socket, der den Umschlag trägt

Die Client-Konfiguration bekommt eine Marke für ihre verschlüsselten ausgehenden Pakete und installiert keine Routen mehr selbst, damit die Ersatzrichtlinie das Einzige ist, was Wege bestimmt:

mark 42
route-noexec
disable-dco

Dezimal 42 ist hexadezimal 0x2a, und die Hexform ist es, auf die die Routing-Regeln passen. Die Referenz zu den Link-Optionen beschreibt mark als etwas, das auf Linux für verschlüsselte ausgehende Pakete gilt, also genau für den Socket, dessen Weg du steuern musst. Das Abschalten des Datenkanal-Offloads hält dieses Beispiel auf dem Userspace-Weg, auf dem das Markenverhalten das beschriebene ist.

route-noexec unterdrückt das automatische Hinzufügen und Entfernen von Routen durch OpenVPN. Es setzt nichts an ihre Stelle, also muss der Routenbesitzer von diesem Moment an jede Route pflegen, die der Tunnel braucht. Wenn ein privates Ziel nach der Änderung verschwindet, ist das die fehlende Ersatzrichtlinie und kein Fehler der Marke.

Behalte währenddessen keine Host-Route in der Haupttabelle für 198.51.100.25. Eine solche Route führt genau die Ausnahme wieder ein, die das Design einschränken will, und sie gewinnt für den HTTPS-Flow, bevor irgendeine der Richtlinien unten befragt wird.

Schicke alles andere in die Tunnel-Tabelle

Sobald die Tunnelschnittstelle existiert und ihre Adresse hält, sieht die Richtlinie so aus:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Die erste Regel hält die spezifischen Routen des Hosts sichtbar, einschließlich eines etwaigen freigegebenen lokalen Netzes, macht aber die Standardroute der Haupttabelle für diese Suche unsichtbar. Dieser Unterschied zählt: den Standard zu unterdrücken ist nicht dasselbe wie die Tabelle zu ignorieren, und die lokalen Ausnahmen, die du weiterhin brauchst, überleben gerade deshalb. Lies diese Ausnahmen einzeln, statt anzunehmen, das Ergebnis sei ein universeller Notausschalter.

Unmarkierter Verkehr fällt dann in die Tunnel-Tabelle, nimmt die Tunnelquelle auf und verlässt den Host über das VPN. Markierter Verkehr scheitert am fwmark-Test der nächsten beiden Regeln und läuft weiter zur gewöhnlichen Hauptsuche weiter unten in der Liste, wo der Uplink-Standard noch liegt. Die abschließende unreachable-Regel ist es, die einen unmarkierten Flow daran hindert, bei fehlender Tunnelroute still auf den Uplink zurückzufallen. Der Selektor ist von Anfang bis Ende die Marke, und die Zieladresse geht nie in die Entscheidung ein.

Halte diese Sperre über Trennungen hinweg aufrecht und installiere sie mit dem Rest der Richtlinie statt von Hand. Eine Regel, die mit der Schnittstelle verschwindet, ist keine Richtlinie, sondern ein Zufall. Die Richtlinie zu löschen, wenn der Tunnel abbricht, ändert den Fehlermodus von „blockiert“ auf „geleakt“, und eine veraltete Tunnelroute, die später ausläuft, ist ein viel leichter zu erklärendes Problem als Verkehr, der über die falsche Schnittstelle hinausging.

Lass den Rückweg dieselbe Marke sehen

Ausgehende Marken sind nur die Hälfte des Mechanismus, und diesen Teil lassen die meisten Nachbauten aus. Antworten auf die verschlüsselte Sitzung kommen über den Uplink an und unterliegen der Reverse-Path-Prüfung, die fragt, ob die Quelle auf demselben Weg zurückgeroutet würde. Ohne Hilfe wendet diese Suche deine unmarkierte Tunnelrichtlinie an und kommt zu dem Schluss, das Paket sei auf der falschen Schnittstelle.

Die Korrektur gehört dem Firewall-Besitzer: die Marke auf der ausgehenden Verbindung speichern, sie auf passende eingehende Pakete wiederherstellen und quellvalidierte Markenbehandlung für den betreffenden Weg aktivieren. Dass OpenVPN eine Socket-Marke setzt, erledigt keines dieser drei Dinge, und ein Rezept, das nur die Client-Optionen auflistet, ist unvollständig. Verlange diese Integration schriftlich, denn sie ist der am wenigsten sichtbare Teil des Designs und der am leichtesten zu verlierende beim Neuaufbau.

Auch die lose Reverse-Path-Prüfung ist kein Ersatz. Der lose Modus braucht weiterhin irgendeine Route für die Quelle, und die unreachable-Sperre, die du hinzugefügt hast, entfernt für unmarkierte Suchen bewusst eine. Lass die Integration der Verbindungsmarke fertigstellen und prüfen, bevor du dich auf dieses Design verlässt, und behandle Host-Filter als separate Frage: eine Marke ist ein Routing-Signal, keine Erlaubnis. Fehlt die Integration, dann ist das Symptom eine Sitzung, die aufgebaut wird und verstummt, sobald Antworten eintreffen.

Beweise es mit zwei Routensuchen

Vergleiche, was der Kernel für die beiden Kontexte entscheidet, und lies die Felder dev und src statt den Exit-Status:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Die erste Suche sollte auf tun1 mit der Tunnelquelle auflösen und die zweite auf den Uplink. Das sind synthetische Suchen, sie beweisen also die Richtlinie und nicht den laufenden Prozess: bestätige den tatsächlichen Transportweg des laufenden Clients getrennt und stelle dann eine echte HTTPS-Anfrage mit eingeschalteter Zertifikatsprüfung.

Schreibe auf, was das Design nicht abdeckt, bevor du es für fertig erklärst. DNS, IPv6 und der Lebenszyklus der Regeln brauchen jeweils eine eigene Entscheidung, und dies ist ein IPv4-Routing-Beispiel und keine vollständige Datenschutzkonfiguration. Sein Wert ist der Selektor: der Umschlag bekommt die Uplink-Ausnahme, und ein gewöhnlicher Dienst an derselben Adresse muss sie nicht erben.