So leiten Sie ein einzelnes IPv4-Ziel außerhalb eines OpenVPN-Tunnels

Die meisten Full-Tunnel-Setups schicken jedes Paket durch das VPN, und die Direktive redirect-gateway sorgt dafür. Ein einzelnes Ziel lässt sich trotzdem ausnehmen. Eine Host-Route für diese Adresse mit dem Platzhalter net_gateway weist den Client an, sie über das ursprüngliche Gateway des Rechners zu erreichen, während alles andere weiter den Tunnel nutzt.

Die Zeile wirkt harmlos und ist es oft auch, aber sie entscheidet nur eine Frage: wohin Pakete für genau diese IPv4-Adresse gehen. Sie ändert weder DNS noch IPv6 noch die Firewall-Richtlinie oder den Prozess, der die Verbindung geöffnet hat, und jedes davon kann die Ausnahme still zunichtemachen.

Was net_gateway tatsächlich benennt

Der Profileintrag für diese Ausnahme ist eine Zeile: route 198.51.100.77 255.255.255.255 net_gateway. Die erste Adresse ist ein Dokumentationsplatzhalter für das Ziel, die Maske macht daraus eine Einzelhost-Route, und das letzte Token benennt den Gateway-Platzhalter. OpenVPN löst Gateway-Platzhalter auf, wenn es Routen installiert. vpn_gateway bedeutet das eigene Gateway des Tunnels, also die Gegenseite der VPN-Verbindung. net_gateway bedeutet das Standardgateway, das der Host hatte, bevor das VPN etwas änderte, meist der lokale Router im physischen Netz.

Ein dritter Platzhalter, remote_host, verweist auf die Adresse des VPN-Servers, und er existiert, damit der Tunnel den Server über den physischen Pfad erreichen kann. Diese drei zu verwechseln ist der häufigste Grund, warum eine Ausnahme am falschen Ort landet oder gar nicht installiert wird.

Der Wert wird beim Verbinden gelesen, nicht in die Datei geschrieben. Wechselt der Rechner in ein anderes Netz, ändert sich das Gateway vor dem VPN, und die Route folgt dem neuen. Das ist meist gewollt, bedeutet aber auch, dass das Verhalten der Ausnahme vom Netz abhängt, aus dem der Client gestartet ist.

Warum eine Host-Route die Tunnel-Standardroute schlägt

Routing entscheidet das spezifischste passende Präfix. redirect-gateway def1 ersetzt normalerweise nicht die Standardroute; es fügt zwei Hälften hinzu, eine Route für die untere Hälfte des Adressraums und eine für die obere, sodass die ursprüngliche Standardroute für andere Zwecke erhalten bleibt. Diese Hälften sind breiter als eine einzelne Adresse.

Eine Route für eine Adresse mit der Maske 255.255.255.255 ist eine /32, und spezifischer geht es bei IPv4 nicht. Wird ein Paket für diese Adresse ausgewertet, passt die /32 und gewinnt, unabhängig davon, welche Route zuerst installiert wurde. Das ist der Mechanismus hinter der Ausnahme, und er funktioniert unter Linux, macOS und Windows gleich, solange die Route tatsächlich vorhanden ist.

Windows fügt eine zweite Dimension hinzu. Sind zwei Routen gleich spezifisch, gewinnt die mit der niedrigeren Metrik, und ein VPN-Adapter kann eine Schnittstellenmetrik tragen, die das Ergebnis ändert. Eine /32 bleibt spezifischer als die Hälften, die Ausnahme hält also normalerweise, aber eine veraltete Route aus einer früheren Sitzung kann ein verwirrendes Ergebnis erzeugen, wenn sie ebenso spezifisch ist.

Was die Ausnahme nicht abdeckt

DNS ist die erste Lücke. Der Client kann interne Resolver-Einstellungen durchreichen, und das Betriebssystem wird sie weiter für Auflösungen verwenden. Eine Anwendung, die einen Namen vor dem Verbinden auflöst, kann eine interne Adresse für einen Dienst erhalten, der direkt gehen soll, oder eine externe Adresse, die korrekt auflöst, dann aber über die nächste Lücke stolpert.

IPv6 ist die zweite. Die Routendirektive behandelt nur IPv4. Ein Dual-Stack-Ziel kann IPv6 bevorzugen, das je nach Richtlinie dem Tunnel oder der IPv6-Standardroute des Hosts folgt, sodass die IPv4-Ausnahme nie zum Tragen kommt. Sie brauchen eine passende IPv6-Route oder eine bewusste Entscheidung, IPv6 für diesen Client abzuschalten.

Der Anwendungsbereich ist der dritte. Die Regel ist zielbasiert, also nutzt jeder Prozess, der sich mit dieser Adresse verbindet, den direkten Pfad, ob es der gewünschte ist oder nicht. Umgekehrt kann eine Website von mehreren Adressen antworten, eine Ausnahme für eine /32 nimmt die Seite also nicht aus. Wenn die eigentliche Anforderung Routing pro Anwendung ist, ist die Routentabelle des Community-Clients das falsche Werkzeug.

Die Ausnahme prüfen, ohne sich selbst zu täuschen

Beginnen Sie mit der installierten Route, nicht mit einem Browser. Fragen Sie unter Linux den Kernel, welche Route und welchen nächsten Hop er für die konkrete Adresse verwendet; lesen Sie unter Windows die Routentabelle für diese /32. Bestätigen Sie, dass das Gateway das physische und nicht der Tunnel ist. Fehlt der Eintrag, wurde das Profil nicht angewandt oder dem Client fehlte die Berechtigung, Routen zu ändern.

Testen Sie dann zwei Ziele. Eine Anfrage an die ausgenommene Adresse sollte über die physische Schnittstelle hinausgehen, und eine Anfrage an eine interne Kontrolladresse sollte weiter den Tunnel nutzen. Nur die ausgenommene Adresse zu testen beweist nichts über den Rest des Tunnels, und eine öffentliche Website zu testen prüft die Adresse, auf die diese Site aufgelöst wurde, die nicht die aus der Regel sein muss.

Prüfen Sie schließlich die Kontrollen, die die Route überstimmen können. Ein clientseitiger Kill-Switch oder eine Windows-Einstellung block-outside-dns kann direkten Verkehr verbieten, was sich als Verbindung zeigt, die fehlschlägt, obwohl die Route korrekt ist. Deaktivieren Sie diese Kontrollen nicht, damit die Ausnahme zu funktionieren scheint; wenn die Richtlinie den direkten Pfad verbietet, ist die Ausnahme ein Entwurfsproblem für den Betreiber des VPN-Dienstes.

Prüfen Sie nach erneutem Verbinden oder Netzwechsel erneut, denn das Gateway vor dem VPN und der verfügbare Pfad sind Eigenschaften des Moments, nicht des Profils.