OpenVPN redirect-gateway: Was jedes Flag mit den Routen macht

Verbinden Sie sich mit redirect-gateway im Profil, und die Standardroute Ihres Rechners kann verschwinden, sich teilen oder genau dort bleiben, wo sie war, je nach Flags, die niemand zweimal liest. Die Option ändert nur den Routing-Zustand und sonst nichts, also ist der einzige verlässliche Beweis dafür, was sie getan hat, die Tabelle, die der Client danach installiert hat. Was folgt, ist die Tabelle nach einer Verbindung, die Route, die den Tunnel selbst am Leben hält, und der IPv6-Verkehr, den die Anweisung nie zu decken behauptet. Jeder Schritt ist ein Befehl, den Sie auf dem Client ausführen können, während der Tunnel steht.

Was jedes Flag mit der Standardroute macht

Ohne jedes Flag entfernt die Option die gewöhnliche Standardroute und setzt den Tunnel an ihre Stelle, sodass das alte Gateway aus der Tabelle verschwindet, solange die Verbindung steht. Fügen Sie def1 hinzu, bleibt diese Standardroute gelistet, und zwei engere Routen erledigen die Arbeit. Fügen Sie bypass-dhcp hinzu, überlebt auch die DHCP-Route, was in einem Netz zählt, in dem der Client noch den lokalen DHCP-Server erreichen muss. Die Flag-Liste auf der Handbuchseite zu OpenVPN 2.6 ist kurz genug für einen Blick, und jeder Eintrag ändert, welche Routen in der Tabelle landen.

Eine geschobene Option verhält sich genauso, sobald sie ankommt, daher kann das Clientprofil gar nichts enthalten, während die Tabelle vollständig umgeleitet aussieht. Das ist normal: Der Server schickte die Flags, der Client wandte sie an, und die lokale Datei erwähnte die Anweisung nie. Wenn ein Push nichts zu tun scheint, prüfen Sie den clientseitigen Filter, der heruntergeladene Optionen annimmt oder verwirft, denn eine verworfene Option löst auf keiner Seite einen Fehler aus.

def1 gewinnt durch Spezifität, ohne Ihre Standardroute anzutasten

Zwei halbe Standardrouten decken zusammen den IPv4-Raum ab, 0.0.0.0/1 und 128.0.0.0/1. Jede ist spezifischer als 0.0.0.0/0, also bevorzugt eine Suche sie, während die echte Standardroute für alles in der Tabelle bleibt, was die am wenigsten spezifische Übereinstimmung verlangt.

Lesen Sie die Tabelle statt das Profil, denn nur die Tabelle zeigt, in welchem dieser Fälle Sie sind. Zwei Zeilen genügen, um sie zu unterscheiden:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Achten Sie auf Schnittstelle und Metrik jeder Zeile, nicht nur auf das Ziel. Eine Standardroute zum Tunnel und ein Paar halber Standardrouten zum Tunnel beschreiben dieselbe Absicht und scheitern unterschiedlich, wenn der Tunnel ausfällt, weil im einen Fall der Rückfallweg noch existiert. Notieren Sie beide Felder im Änderungsvermerk. Ein überlebender Rückfallweg hält manchmal eine Fernsitzung lange genug am Leben, um den Tunnel zu reparieren, und er ist auch das, was Verkehr leckt, wenn die Absicht ein voller Tunnel war.

Halten Sie den Tunnelendpunkt erreichbar

Der Client braucht eine Route zum fernen Ende des Tunnels, die nicht selbst durch den Tunnel läuft. OpenVPN installiert diese Host-Route, bevor es etwas anderes ändert, und eine manuelle Routenänderung oder ein zweiter VPN-Client kann sie entfernen. Das Symptom danach ist eine Verbindung, die verbunden meldet und dann nichts durchlässt.

Fragen Sie den Kernel, welche Schnittstelle er für die Endpunktadresse verwenden würde, während der Tunnel steht. Die Antwort muss die physische Schnittstelle und ihr Gateway nennen, niemals tun0:

ip route get 198.51.100.20

Wenn diese Suche das Tunnelgerät zurückgibt, trägt der Tunnel seinen eigenen Transport und bricht zusammen, sobald ein Paket hinaus muss. Lokale Präfixe, ein zweiter Adapter und Policy-Routing zählen hier weiterhin, weshalb eine Umleitung, die auf einem sauberen Laptop funktioniert, auf einem Host mit Verwaltungsschnittstelle und zwei Standardrouten scheitern kann. Meist wird dem Profil angelastet, was der Adressplan getan hat.

IPv6-Verkehr nutzt weiterhin seine eigene Tabelle

IPv4 umzuleiten lässt IPv6 unberührt, und die beiden Familien werden von verschiedenen Flags geändert. Auf einem Dual-Stack-Host mit funktionierender v6-Standardroute kann v4-Verkehr vollständig im Tunnel sitzen, während jedes v6-fähige Ziel über die physische Verbindung hinausgeht. Ein Host, der in einer Tabelle richtig aussieht, leckt in der anderen.

Prüfen Sie nach dem Verbinden die v6-Tabelle, statt anzunehmen, der Tunnel habe sie abgedeckt. Die Anweisung trägt genau deshalb Adressfamilien-Flags, und ein Profil, das sie weglässt, erbt, was die Plattform standardmäßig tut:

ip -6 route show default
ip -6 route get 2001:db8::10

Beweisen Sie, welche Schnittstelle eine Anwendung nutzt

Ein verbundener Zustand ist keine Sperre, und eine Routenänderung ist kein Notausschalter. Wenn direkter Verkehr stoppen soll, sobald der Tunnel ausfällt, lebt diese Regel in der Firewall und braucht ihren eigenen Test.

Testen Sie den Weg, den eine Anwendung wirklich nimmt, statt den Weg, den das Profil beschreibt. Fragen Sie zuerst die Route ab, binden Sie dann eine Anfrage der Reihe nach an jede Schnittstelle und vergleichen Sie, was die Gegenseite meldet:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Wenn beide Anfragen dieselbe Adresse zurückgeben, nutzt die Anwendung den Tunnel nicht, obwohl die Routing-Tabelle das sagt. Wenn nur die an den Tunnel gebundene Anfrage gelingt, ist der physische Weg für dieses Ziel gefiltert, und der Tunnel tut, worum Sie gebeten haben. Schreiben Sie die Flags, die installierten Routen, die Endpunktabfrage und beide Ausgangsergebnisse in den Änderungseintrag, damit die nächste Person Fakten erbt statt eines Screenshots.