Zwei Gateways, ein VPN: Warum OpenVPN den falschen Uplink wählt

Zwei Uplinks, ein Tunnel, und der Verkehr verlässt das Netz über den, den Sie nicht gewählt haben. Die privaten Subnetze sind erreichbar, das Protokoll meldet eine erfolgreiche Verbindung, und die gemessene Leitung ist die, die ihn trägt. Nichts in der OpenVPN-Ausgabe nennt ein Gateway, weil der Client nie eines gewählt hat. Er öffnete einen Socket zu einer entfernten Adresse und ließ den Kernel entscheiden, wie diese Adresse erreicht wird.

Die Tunneladresse ist nicht der Endpunkt

In jeder Sitzung gibt es zwei verschiedene Wege. Der äußere Weg trägt den verschlüsselten Transport zur öffentlichen Adresse des Servers. Der innere Weg trägt alles, was der Server in den Tunnel schiebt, und Routingregeln für den einen wirken nicht auf den anderen.

Der remote-Eintrag im Profil benennt das äußere Ziel, also ist das die Adresse, die festgehalten werden muss. Es ist auch der Wert, der sich ändert, wenn ein Hostname anders aufgelöst wird oder das Profil mehrere remotes auflistet.

Finden Sie die Adresse, die der Client tatsächlich angewählt hat

Lesen Sie den laufenden Socket statt der Konfigurationsdatei. Die Sockettabelle zeigt den Peer, mit dem der Prozess tatsächlich verbunden ist, und das ist der Wert, den eine Ausnahme treffen muss. Ein Profil kann nach dem Sitzungsstart bearbeitet werden, und der Socket ist der einzige Beweis dafür, was angewählt wurde:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Die Protokollzeile nennt Peer-Adresse und Port zum Zeitpunkt der Verbindung. Wenn sie vom Profil abweicht, schreibt etwas vor dem Client das Ziel um, bevor die Verbindung beginnt.

Prüfen Sie auch die Adressfamilie. Ein Dual-Stack-Profil kann über IPv6 verbinden, während Ihre Ausnahme nur IPv4 abdeckt, und dann folgt der Verkehr einer anderen Regel als der, die Sie geschrieben haben. Dasselbe gilt für einen Proxy, der im Namen des Endpunkts antwortet. Beide Fälle ergeben einen Tunnel, der funktioniert, während Ihre Route nichts bewirkt.

Den Endpunkt festhalten und die Reihenfolge der Richtlinien lesen

Eine Hostroute ist spezifischer als jede Standardroute. Eine /32 für die Peer-Adresse gewinnt daher innerhalb der Tabelle, die sie enthält. Die übliche Form nennt Gateway und Gerät ausdrücklich:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Diese Route hilft nur, wenn die Suche diese Tabelle erreicht. Richtlinienregeln werden der Reihe nach ausgewertet, und der erste Treffer entscheidet, also umgeht eine Regel, die alles in eine zweite Tabelle schickt, Ihre Hostroute in main. Lesen Sie die Regeln, bevor Sie annehmen, die Route sei maßgeblich:

ip rule show
ip route get 203.0.113.40

Fragen Sie den zweiten Befehl mit derselben Quelladresse oder Markierung ab, die der Client verwendet, wenn die Richtlinie davon abhängt. Er meldet die Route, die der Kernel wählen würde, was ein Beweis über die Suche ist und kein Beweis dafür, dass der laufende Socket diesen Weg nutzt.

Wenn sich der Endpunkt verschiebt

Ein Hostname, der auf mehrere Adressen auflöst, entwertet eine dauerhafte /32, sobald sich die Antwort ändert. Ein Profil mit mehreren remote-Zeilen hat dasselbe Problem, weil der Client auf jeder von ihnen landen kann. Aktualisieren Sie die Route aus den Lifecycle-Hooks des Clients selbst, statt sie von Hand hinzuzufügen. Ein up-Skript, das den ausgehandelten Peer liest und die Hostroute installiert, hält die Ausnahme mit der Realität im Einklang, und ein passendes down-Skript entfernt sie.

Halten Sie die Aktualisierung am selben Ort fest wie den Rest der Routingkonfiguration des Hosts. Eine Route, die nur bis zum nächsten Neustart existiert, ist ein Test, keine Korrektur.

Die innere Richtlinie getrennt halten

Den äußeren Weg zu verschieben gewährt keinen Zugang zu einem neuen privaten Subnetz und ändert nicht, welche Ziele der Server in den Tunnel schiebt. Die Route der unteren Schicht wählt die Leitung; die geschobenen Routen wählen, was in den Tunnel gelangt. Diese beiden Entscheidungen getrennt zu halten macht die Aufteilung vorhersagbar.

Wenn das Ziel nur ist, den verschlüsselten Transport von einer gemessenen Leitung fernzuhalten, lassen Sie die Standardroute in Ruhe und fügen Sie die einzelne Hostausnahme hinzu. Die maschinenweite Standardroute zu ersetzen, um eine VPN-Verbindung zu verschieben, bricht jede andere Anwendung auf dem Host.

Bestätigen Sie das Ergebnis mit zwei unabhängigen Beobachtungen: der lokalen Adresse und dem Gerät des Sockets sowie der Route, auf die das private Ziel aufgelöst wird. Wenn beides Ihrer Absicht entspricht, ist die Aufteilung real. Das OpenVPN-2.6-Handbuch behandelt die Optionen für remote- und lokale Bindung, die entscheiden, welche Adresse der Client anwählt.