Ihre alte Standardroute überlebt OpenVPN absichtlich

Sie verbinden den Tunnel, führen ip route aus, und das ursprüngliche Standard-Gateway steht immer noch da. Der nächste Gedanke ist, dass der Client die Route nicht übernommen hat, also löschen Sie die Standardroute von Hand und verlieren die Verbindung vollständig. Dieser Eintrag soll bleiben. Mit redirect-gateway def1 installiert OpenVPN zwei spezifischere Routen, die die gewöhnliche Standardroute überstimmen, statt sie zu ersetzen. Das alte Gateway bleibt und trägt den Verkehr, den Sie getestet haben, nicht mehr.

Was def1 tatsächlich tut

Das Flag fügt 0.0.0.0/1 und 128.0.0.0/1 hinzu, beide zum Tunnel zeigend. 0.0.0.0/1 erfasst jede Adresse, deren erstes Oktett 0 bis 127 ist, und 128.0.0.0/1 erfasst 128 bis 255, sodass jedes IPv4-Ziel eine spezifischere Übereinstimmung als die alte Standardroute hat. Die Präfixlänge, nicht die Metrik, entscheidet, welche Route gewinnt.

Die ursprüngliche Standardroute stehen zu lassen, ist Absicht. Der Client muss sich nicht merken, was er ersetzt hat, und er schreibt die Route nicht um, die seine eigene Verbindung zum VPN-Server trägt. Beim Trennen entfernt er die beiden Halbrouten, und die Tabelle kehrt zu dem zurück, was sie war.

Warum /1 und nicht /0

Routing wählt das längste passende Präfix, nicht die niedrigste Metrik, also schlägt eine /1 eine /0, egal was die Metrik der Standardroute sagt. Beide Hälften existieren, weil eine /1 nur die Hälfte des Raums abdeckt; ist nur 0.0.0.0/1 vorhanden, folgt alles ab 128.0.0.0 der alten Standardroute, was das verwirrende Symptom erzeugt, dass manche Seiten funktionieren und andere nicht.

Die Metrik der alten Standardroute zu erhöhen oder zu senken, ändert nichts, und eine Standardroute mit niedrigerer Metrik auf einer anderen Schnittstelle stiehlt den Verkehr auch nicht. Zuerst entscheidet die Präfixlänge, und nur gleiche Präfixe greifen auf die Metrik zurück.

Eine echte Routingtabelle lesen

Ein verbundener Host kann alle drei Einträge gleichzeitig zeigen, wobei der Tunnel die Hälften trägt und das ursprüngliche Gateway noch aufgeführt ist. Die Adressen sind Beispiele und keine Konfiguration zum Kopieren, weil Schnittstellennamen, Tunneltopologie und zusätzliche Routen je nach Plattform und Client variieren.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Wichtig ist die Beziehung: zwei bestimmte Hälften über einer allgemeinen Standardroute. Die Zeile des alten Gateways bleibt, weil nichts sie ersetzt hat.

Prüfen, welche Route das Paket tatsächlich nimmt

Spezifischere Routen können trotzdem gewinnen: eine Route für einen privaten Bereich, ein lokales Subnetz oder die eigene Adresse des VPN-Servers ist länger als eine /1. Der Tunnel braucht einen äußeren Pfad zu seinem Server, und diese Verbindung zurück in den Tunnel zu schicken, würde ihn sofort brechen. Fragen Sie unter Linux den Kernel, statt die Tabelle mit dem Auge zu lesen: ip route get mit dem Ziel, das Sie interessiert, gibt die gewählte Route, Schnittstelle und Quelle aus. Ist Policy-Routing konfiguriert, prüfen Sie auch die Regeln, denn eine Regel kann eine andere Tabelle auswählen, bevor die Haupttabelle herangezogen wird.

Wenn sich nur ein Teil von IPv4 falsch verhält, bestätigen Sie, dass beide Hälften installiert sind, und suchen Sie dann nach einer Ausnahme, die zum fehlschlagenden Ziel passt. Die alte Standardroute zu löschen, ist keine Lösung, und sie entfernt die Route, die der Client braucht, um den Tunnel sauber abzubauen.

Was def1 nicht abdeckt

Zwei IPv4-Einträge sagen nichts über IPv6: Ein Host mit IPv6-Konnektivität nutzt weiter seine eigene Standardroute, bis etwas diese Familie getrennt umleitet, weshalb in einem Dual-Stack-Netz ein Teil des Verkehrs den Tunnel scheinbar umgeht. Andere Clients und Netzwerkmanager implementieren Full-Tunnel-Routing anders, und ihre Tabellen werden nicht übereinstimmen. Das hier beschriebene def1-Verhalten gehört zum dokumentierten Flag von OpenVPN, nicht zu jedem VPN auf der Maschine.

Ein Kill-Switch beantwortet eine andere Frage: was die Maschine tut, wenn der Tunnel ausfällt. Die Routenpriorität entscheidet, wohin der Verkehr geht, solange der Tunnel steht; sie entscheidet nicht, was eine Firewall danach tut. Reihenfolge der Arbeit: Tabelle lesen, bestätigen, dass beide Hälften existieren, ip route get für das fehlschlagende Ziel ausführen, Policy-Regeln prüfen und dann IPv6 getrennt ansehen. Lassen Sie die alte Standardroute, wo sie ist.