route-gateway ist nicht redirect-gateway: Was sich tatsächlich ändert

Ihr Tunnel kommt hoch, das private Subnetz antwortet, und gewöhnliches Surfen verschwindet weiterhin im VPN, obwohl jemand die Gateway-Zeile aus dem Profil gelöscht hat. Diese Kombination ist der Fingerabdruck der falschen Direktive, die bearbeitet wurde. Das Entfernte gab dem Client einen nächsten Hop für Routen, die er installiert; das, was weiterhin Verkehr abfing, kam von woanders und wurde vom Server geschoben. Abdeckung und nächster Hop sind getrennte Aufgaben, und nur eine davon entscheidet, ob öffentliche Ziele den Tunnel nutzen.

Die Zeile, die Sie entfernt haben, war ein nächster Hop, kein Richtlinien-Schalter

Jede Route, die der Client installiert, braucht eine Gateway-Adresse zum Anzeigen, und die Gateway-Direktive ist die Quelle dieser Adresse, wenn eine Route keine eigene nennt. Löschen Sie sie, und diese Routen haben nichts, woran sie hängen können, sodass sie entweder nicht installiert werden oder auf einem Weg landen, der nirgendwohin führt. Das private Subnetz ist genau das, was eine solche Route trug.

Inzwischen hat das überlebende Verhalten einen anderen Urheber: eine Umleitungsoption im geschobenen Block, die gewöhnlichen ausgehenden Verkehr gemäß ihren Flags in den Tunnel verschiebt. Das Entfernen des Gateways deaktiviert oder schwächt sie nicht. Das Ergebnis ist das Schlechteste beider Zustände: öffentlicher Verkehr wird weiterhin abgefangen, und das private Ziel, das den Tunnel rechtfertigte, ist nun unerreichbar. Deshalb ändert auch die zweite Bearbeitung, im selben Geist vorgenommen, nichts.

Vier Hebel, vier verschiedene Aufgaben

Vier Direktiven werden in dieser Diskussion austauschbar zitiert, und nur eine davon steuert die Abdeckung, also welche Ziele überhaupt durch den Tunnel geroutet werden. Eine zweite setzt den nächsten Hop, den Routen verwenden, eine dritte installiert ein einzelnes Präfix, und eine vierte verwirft alles, was der Server geschoben hat, einschließlich der privaten Routen, die das Deployment braucht. Die Tabelle sortiert sie danach, was ein Administrator ändern will, nicht nach dem Namen, denn die Namen verursachen die Verwechslung. Behandeln Sie sie als vier getrennte Entscheidungen und wählen Sie die, die Sie tatsächlich rückgängig machen wollen.

In der Praxis kommen alle vier oft in einem geschobenen Block an, Zeile für Zeile, was sie wie Teile einer einzigen Einstellung aussehen lässt. Das sind sie nicht, und die OpenVPN-Referenz dokumentiert sie genau deshalb als unterschiedliche Mechanismen. Herauszufinden, welche Entscheidung Sie rückgängig machen, ist die Aufgabe; die Bearbeitung ist eine Zeile.

Filtern Sie die geschobene Zeile, behalten Sie den nächsten Hop

Wenn die Abdeckung, gegen die Sie Einwände haben, als geschobene Option ankommt, ist die enge Antwort, diese Option namentlich zu ignorieren und den Rest des geschobenen Blocks unangetastet zu lassen. Als Filter geschrieben, sieht es aus wie die Zeile unten, und es gehört in das Profil des betroffenen Clients, nicht in die Serverkonfiguration.

pull-filter ignore "redirect-gateway"

Enge ist der Punkt. Weil der Filter ein Textpräfix vergleicht, passt ein kürzeres Muster auch auf die Nächster-Hop-Direktive, was genau die Information entfernt, auf die die privaten Routen angewiesen sind, und den ursprünglichen Fehler in neuem Gewand wiederholt. Ein Filter wirkt außerdem nur auf geschobene Optionen, berührt also nie eine gleichwertige Zeile, die lokal geschrieben oder von einem Netzwerkmanager vorgegeben wurde. Verbinden Sie danach neu, denn eine laufende Sitzung bewertet nicht neu, was der Server geschoben hat.

Lesen Sie die Suche, nicht die Tabelle

Fragen Sie nach dem Neuladen des Profils den Kernel, wohin zwei Ziele tatsächlich gehen würden: eines innerhalb des privaten Präfixes und eines im öffentlichen Internet. Ein vollständiger Dump der Haupttabelle ist schwerer zu lesen und leichter falsch zu lesen, weil eine Route existieren und trotzdem gegen eine spezifischere Übereinstimmung verlieren kann. Bei Policy-Routing gehören auch die Regel, die Tabelle und die Quelladresse in die Prüfung.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Die def1-Variante verdient Vertrautheit, weil sie den alten Standardeintrag sichtbar lässt, während ein Paar Halb-Standardeinträge die Suche gewinnt. Eine 0.0.0.0/0-Zeile in der Ausgabe beweist daher für sich genommen nichts. Die Suche beantwortet die Frage, die die Auflistung nur scheinbar beantwortet.

DNS, IPv6 und die private Route müssen weiterhin funktionieren

Eine IPv4-Umleitung abzulehnen sagt nichts über den Resolver, sodass eine geschobene DNS-Option weiterhin Anfragen in den Tunnel schicken kann, während die Routen korrekt aussehen. Ein IPv6-Standard kann dasselbe für eine Adressfamilie tun, die die IPv4-Prüfung nie berührt hat. Beide brauchen eine ausdrückliche Entscheidung statt einer Annahme. Bestätigen Sie dann, dass der private Dienst noch antwortet, denn ein Split-Tunnel, der seine private Route verloren hat, ist kein Split-Tunnel, sondern ein kaputter.

Ein breiteres Werkzeug verdient eine Warnung: route-nopull verwirft jede geschobene Route und jede geschobene DNS-Option, was den Volltunnel gewiss stoppt und ebenso gewiss die privaten Routen bricht, von denen das Deployment abhängt, also ein weit größerer Hammer ist als ein Namensfilter, der auf eine Option zielt. Prüfen Sie nach jeder Änderung das private Ziel, ein öffentliches Ziel und den Resolver, und betrachten Sie einen abgeschlossenen Handshake als Beweis für nichts außer den Handshake.