Warum bricht ein zweiter VPN-Tunnel den ersten?

Einen zweiten VPN-Client zu installieren, um ein Kundennetz zu erreichen, ist der übliche Weg, wie das beginnt, und der erste Tunnel wird dunkel, während beide Clients Erfolg melden. Jeder Client hat eine Default-Route installiert, die zweite war spezifischer, und der Kernel folgt ihr jetzt für alles außer der eigenen äußeren Verbindung des ersten Tunnels. Nichts ist abgestürzt und kein Profil ist falsch. Eine Route hat eine andere ersetzt, und die Lösung besteht darin, zu entscheiden, welcher Tunnel den Default besitzen soll.

Das Symptom: Der zweite Client gewinnt leise

OpenVPN: Die Option redirect-gateway def1 überschreibt 0.0.0.0/0 nicht. Sie fügt 0.0.0.0/1 und 128.0.0.0/1 hinzu: Zusammen decken sie jede IPv4-Adresse ab, und jedes Präfix schlägt einen einfachen Default an Länge. Der ursprüngliche Default bleibt in der Tabelle und wird für normalen Verkehr nicht mehr genutzt, und eine Host-Route zum VPN-Server hält den Tunnel davon ab, seine eigenen äußeren Pakete abzufangen. Beide Clients tun das, und der zweite installiert sein Paar einfach später.

Deshalb wirkt der erste Tunnel tot statt getrennt. Seine Schnittstelle ist oben, sein Steuerkanal lebt, und kein Anwendungsverkehr erreicht ihn mehr. Die umgekehrte Beschwerde hat denselben fehlenden Push: Ein Telefon, das sich verbindet, aber nichts sendet, spricht meist mit einem Server, der nie redirect-gateway angekündigt hat, also behält das Gerät seinen eigenen Default und erreicht nur den Pool.

Machen Sie eine Routing-Aufnahme vor und nach dem Verbinden des zweiten Clients. Die beiden halben Routen, die in der Tabelle erscheinen, sind die ganze Änderung, und sie erklären beide Beschwerden. Nichts anderes in der Tabelle muss sich bewegen, damit das Symptom auftritt. Deshalb stellt das Entfernen des zweiten Clients den ersten sofort wieder her.

Lesen Sie nach, welcher Tunnel tatsächlich gewinnt

Leiten Sie den Gewinner nicht aus der Startreihenfolge der Clients oder aus dem Symbol im Infobereich ab. Fragen Sie den Kernel, welche Route er für ein Ziel außerhalb beider privater Netze verwenden würde, und lesen Sie die zurückgegebene Schnittstelle.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Die ersten beiden sind die Linux-Antwort und die letzten beiden das Windows-Äquivalent. Führen Sie sie aus, während beide Tunnel oben sind, trennen Sie dann einen und führen Sie sie erneut aus. Der Unterschied zwischen den beiden Ausgaben ist die Tatsache, die Sie vor der Wahl einer Lösung brauchen, und es dauert weniger Zeit, als das Protokoll eines der Clients zu lesen.

Halten Sie das Ergebnis fest, einschließlich Schnittstellenname und des passenden Präfixes. Ein Ticket, das sagt, der zweite VPN habe den ersten kaputtgemacht, ist eine Beschreibung des Symptoms, keine Routing-Aussage, auf der jemand handeln kann. Die Abfrage macht daraus eine Tatsache, die der nächste Ingenieur mit einem Befehl reproduzieren kann.

Windows: Verhindern, dass ein Profil den Default besitzt

Windows speichert Profile, und der eingebaute Client lässt eines von einem anderen abhängen, damit das erste automatisch hochkommt, wenn das zweite wählt. Das zuletzt verbundene Profil behält tendenziell den Default, also ist der praktische Besitzer der letzte Wählvorgang und nicht der erste. Geben Sie jedem Profil eigene gepushte Routen und aktivieren Sie Split Tunneling für dasjenige, das den Default nicht besitzen soll.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split Tunneling ändert das: Nur vom Server gepushte Präfixe landen in der Tabelle, was den Default beim ersten Tunnel lässt. Das Design scheitert weiterhin, wenn beide Server eine Default-Route pushen, denn dann gewinnt die letzte Verbindung, und keine Einstellung auf Client-Seite ändert das. Korrigieren Sie den Push auf Serverseite oder akzeptieren Sie einen Besitzer.

App-gesteuerte Profile sind eine andere Funktion und wissenswert: Ein Windows-Profil kann starten, wenn eine benannte ausführbare Datei läuft, wobei Verkehrsfilter entscheiden, was es trägt. Das ist eine Profileinstellung und keine Firewall-Regel, und es löst ein anderes Problem als den Default-Routen-Konflikt.

Linux: Den zweiten Tunnel aus der Haupttabelle heraushalten

Zwei openvpn --config-Instanzen auf einer Maschine laufen zu lassen, bringt beide Clients in dieselbe Tabelle, und drei Optionen trennen sie mit wachsender Isolation. Am leichtesten ist, den zweiten Client die Tabelle gar nicht bearbeiten zu lassen: route-nopull mit expliziten Routen oder ein route-up-Skript, das nur das installiert, was Sie beabsichtigen. Dann trägt der zweite Tunnel genau die von Ihnen genannten Präfixe und nichts sonst. Dann entscheiden Sie, welche Präfixe wohin gehen, statt es hinterher zu entdecken.

Policy-Routing ist die mittlere Option. Eine Regel wählt eine separate Tabelle für eine Quelladresse oder Firewall-Marke, und diese Tabelle trägt die Routen des zweiten Tunnels. Reverse-Path-Filtering ist hier die Falle, denn eine Antwort, die auf einer anderen Schnittstelle ankommt als der, die die Tabelle wählen würde, wird verworfen, also prüfen Sie die Einstellung rp_filter, bevor Sie schließen, dass der Tunnel kaputt ist.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Netzwerk-Namespaces sind die schwerste und sauberste Option. Starten Sie den zweiten Client in ip netns, geben Sie ihm ein veth-Paar und betreten Sie diesen Namespace, um ihn zu nutzen. Störungen verschwinden, weil jeder Namespace eigene Tabellen besitzt statt eine zu teilen, was den zusätzlichen Aufwand wert ist, wenn beide Tunnel wochenlang oben bleiben müssen.

Pro Anwendung und Verkettung als eigenes Problem

Manchmal soll nur ein Programm den zweiten Tunnel nutzen. Unter Linux erreicht Policy-Routing nach Benutzer, cgroup oder Port dieses Ergebnis, und ein einzelnes Ziel lässt sich an eine Schnittstelle binden, ohne den Default überhaupt anzutasten. Eine Anwendung, die ihren Socket an eine Schnittstelle bindet, konsultiert die Routingtabelle gar nicht, sodass ein Launcher den physischen Adapter weiter nutzen kann, bis eine Adresse in seinen eigenen Einstellungen gewählt wird.

Verkettung ist ein anderer Vorgang als zwei Tunnel nebeneinander zu betreiben. A über B zu verketten bedeutet, dass die Adresse des inneren Servers aus dem äußeren Tunnel heraus erreichbar sein muss. Der äußere Client darf außerdem die verschlüsselten Pakete des inneren Clients nicht für ein Leck halten. Ein Client in einer virtuellen Maschine ist die grobe, aber zuverlässige Variante; beide auf einem Host erfordern die Routing-Arbeit oben plus einen äußeren Pfad zum inneren Server, der nie in den inneren Tunnel gelangt.

Notieren Sie den Besitzer des Defaults, die Präfixliste jedes Tunnels und den DNS-Pfad. Diese drei Fakten machen den nächsten Vorfall zu einem Nachschlagen statt zu einer Untersuchung.