Zwei VPN-Clients, eine Routing-Tabelle: Wer gewinnt die Standardroute

Es sieht aus, als kämpften zwei VPN-Clients um denselben Socket, und die naheliegende Lösung müsste sein, einen zu deinstallieren. In der Praxis berühren sie selten denselben Socket. Jede Verbindung schreibt die Routing-Tabelle des Betriebssystems neu, und ein Full-Tunnel-Profil beansprucht die Standardroute. Meist gewinnt der zuletzt verbundene Client, weshalb das Symptom zwischen den Clients zu wandern scheint.

Der Konflikt lebt in der Routing-Tabelle

Ein virtueller Adapter plus eine Standardroute – so fängt ein Full Tunnel den Verkehr ab. Wenn der zweite Client seine eigene Standardroute einrichtet, wird der ältere Eintrag ersetzt oder durch die Metrik herabgestuft, und jedes Ziel läuft nun über den neueren Tunnel. Der erste Client bleibt verbunden und zeigt weiterhin ein grünes Symbol, also ist die Schnittstelle aktiv, während der Pfad weg ist. Genau diese Trennung zwischen Verbindungszustand und Routing-Zustand macht das Verhalten verwirrend.

Die Clients sind Redakteure einer gemeinsamen Tabelle. Zu wissen, welche Änderung zuletzt geschah, erklärt fast jedes Symptom.

Lesen Sie, welcher Tunnel den aktuellen Pfad besitzt

Prüfen Sie die tatsächliche Entscheidung, statt dem Client zu vertrauen, der „verbunden“ meldet. Fragen Sie das System, welche Schnittstelle ein bestimmtes Ziel tragen würde.

ip route get 10.20.0.5
route print -4

Der erste Befehl nennt die Schnittstelle und die Quelladresse für ein Ziel, und das ist genau die Frage, die Sie interessiert. Die Routenausgabe zeigt unter Windows die konkurrierenden Standardeinträge und ihre Metriken, sodass Sie sehen, welcher gerade gewinnt. Führen Sie die Abfrage für einen Host in jedem entfernten Netz durch, denn ein Ziel kann richtig sein, während das andere Netz nicht erreichbar ist. Wenn die Antwort den falschen Tunnel nennt, hilft ein erneutes Verbinden nicht; die Routing-Richtlinie muss sich ändern.

Hindern Sie den zweiten Client daran, alles zu beanspruchen

Ein Client sollte die Standardroute besitzen, der andere nur seine eigenen Präfixe tragen. OpenVPN Clients können ablehnen, was der Server aufdrängt.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignoriert jede aufgedrängte Route, während pull-filter ignore "redirect-gateway" nur die Standardrouten-Direktive verwirft und aufgedrängtes DNS sowie andere Optionen behält. Wählen Sie zwischen beiden danach, wie viel von der Serverkonfiguration Sie noch wollen, und fügen Sie dann die konkreten Präfixe hinzu, die das zweite Netz braucht. Denken Sie an DNS, denn ein Resolver, der von einem Tunnel aufgedrängt wird, der die Abfragen nicht trägt, liefert nichts zurück. Testen Sie einen bekannten Host in jedem Netz und bestätigen Sie die Quelladresse, die die Gegenseite sieht.

Überlappende Subnetze lassen sich nicht umgehen

Wenn beide Netze dasselbe Präfix veröffentlichen, hält der Kernel einen Eintrag für zwei verschiedene Orte und muss wählen. Eine Host-Route kann die fehlende Unterscheidung nicht erfinden, und eine Metrik-Anpassung auch nicht. Nummerieren Sie eine Seite neu, oder lassen Sie deren Administrator den entfernten Bereich übersetzen, damit sich die Präfixe unterscheiden. Prüfen Sie die echten Subnetze, bevor Sie die Clients beschuldigen, denn eine Heimrouter-Standardroute 192.168.1.0/24 kollidiert häufiger mit einem Bürobereich, als man erwartet. Notieren Sie beide Bereiche im Ticket, damit die nächste Änderung die Überlappung nicht neu erzeugt.

Trennen Sie auch zwei Ziele: beide Netze zu erreichen ist ein Routing-Problem, während das Verketten von Tunneln für Privatsphäre ein anderes Design mit einem zusätzlichen Betreiber auf dem Pfad ist. Nutzen Sie nicht das eine, um das andere zu lösen.