Zwei VPN-Clients auf einem Desktop: Was kollidiert und was funktioniert

Zwei Clients streiten um die Standardroute, den Resolver und Filtertreiber. Halten Sie fest, wer den Ausgang besitzt, und trennen Sie dann den zweiten Tunnel mit einer VM oder einem netns.

Ihr zweiter Client verbindet sich, die Ressourcen des ersten werden nicht mehr aufgelöst, und das Ticket besagt, dass das Arbeits-VPN das private kaputtgemacht hat. Nichts ist im Sinne eines Defekts kaputt: Beide Clients taten, wofür sie entworfen wurden, und die Maschine hat nur eine Routingtabelle. Die Kollision betrifft vier Ressourcen, von denen jeder Client annimmt, er besitze sie. Gehen Sie sie der Reihe nach durch, und die Behebung wird meist zu einer Designentscheidung statt zu einer Reparatur.

Schritt 1: Finden Sie heraus, welcher Client den Ausgang besitzt

Lesen Sie die aktuelle Ausgangsentscheidung, bevor Sie etwas ändern. Die Routensuche für eine öffentliche Adresse sagt Ihnen, welche Schnittstelle und welchen nächsten Hop ein Paket gerade jetzt verwenden würde, und das ist die Antwort darauf, wer gewonnen hat. Vergleichen Sie das mit den Schnittstellennamen, die die Clients angelegt haben und die meist den Produkt- oder Protokollnamen tragen. Wenn die Suche auf den Tunnel zeigt, den Sie nicht erwartet haben, haben Sie die Kollision bereits gefunden.

ip route get 1.1.1.1
ip route show default
route print

Manche Clients ersetzen die Standardroute überhaupt nicht; sie fügen zwei Hälften hinzu, eine für die untere Hälfte des Adressraums und eine für die obere, die zusammen alles abdecken. Das lässt die ursprüngliche Standardroute sichtbar und lässt eine manuelle Reparatur korrekt aussehen, während der Verkehr weiterhin durch den Tunnel verlässt. Lesen Sie die Metrik und die Präfixlänge, nicht nur das Vorhandensein eines Standardeintrags.

Halten Sie an, wenn beide Clients dasselbe Präfix mit derselben Metrik beanspruchen. Der Kernel wählt eines, und das andere erscheint verbunden, während es nichts überträgt.

Schritt 2: Prüfen Sie den Resolver und die überlappenden Präfixe

DNS ist die zweite Kollision, und sie erzeugt ein unverwechselbares Symptom: Namen scheitern, während Adressen funktionieren. Jeder Client drängt seinen eigenen Resolver durch, und der letzte Schreiber gewinnt für die folgenden Abfragen. Fragen Sie den Resolver-Dienst, was er pro Verbindung verwendet, statt die Einstellungsseite des Clients zu lesen.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Vergleichen Sie dann die privaten Präfixe, die die beiden Netzwerke verwenden. Wenn beide Seiten aus demselben Bereich zuteilen, wird keine clientseitige Anordnung das beheben, weil die Maschine nicht sagen kann, welches 10.0.0.0/8-Ziel zu welchem Tunnel gehört. Eine Seite muss umnummeriert oder übersetzt werden, und das ist ein Gespräch mit den Netzwerkeigentümern statt einer Konfigurationsänderung. Überlappung ist die eine Kollision, bei der die ehrliche Antwort lautet, dass das Design geändert werden muss.

Halten Sie hier an, wenn die Präfixe überlappen. Alles Spätere in dieser Checkliste setzt voraus, dass sie es nicht tun.

Schritt 3: Wählen Sie ein Trennmuster, das hält

Die verlässlichen Muster vermeiden es, zwei Clients gegen dieselbe Routingtabelle laufen zu lassen. Ein Client mit einer Split-Tunnel-Richtlinie, die beide privaten Netzwerke erreicht ist das Einfachste, sofern sich die Ziele nicht überlappen und der Eigentümer der Richtlinie zustimmt. Eine virtuelle Maschine oder ein Netzwerk-Namespace ist die nächste Stufe, weil jede ihre eigene Tabelle und ihren eigenen Resolver bekommt.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Ein Namespace bietet dieselbe Trennung wie eine virtuelle Maschine ohne das zweite Betriebssystem, hat aber raue Kanten: Das Tunnelgerät muss hineinverschoben werden, und die Anwendung muss darin gestartet werden. Ein separates physisches Gerät ist oft die am wenigsten überraschende Option für ein privates VPN neben einem verwalteten Arbeits-Client. Einen Tunnel in einen anderen zu stapeln ist kein Trennmuster; der innere Endpunkt muss durch den äußeren Tunnel erreichbar bleiben, und die Anordnung bringt obendrein MTU- und Latenzprobleme mit.

Wählen Sie ein Muster und schreiben Sie auf, warum. Ein Namespace für eine Anwendung mit einem Split-Tunnel für den Rest zu mischen, erzeugt die ursprüngliche Kollision in schwerer zu debuggender Form neu.

Schritt 4: Prüfen Sie beide Netzwerke aus derselben Sitzung

Testen Sie eine Ressource in jedem privaten Netzwerk aus der Umgebung, in der die Anwendung tatsächlich läuft, nicht aus Ihrer Shell, wenn die Anwendung in einem Namespace läuft. Prüfen Sie die Ausgangsschnittstelle, die aufgelöste Adresse und den Antwortcode zusammen, denn ein Erfolg bei einem der drei kann einen Fehler bei den anderen verbergen. Wiederholen Sie es nach einem Neustart, da die Reihenfolge, in der die Clients starten, entscheidet, wer gewinnt. Genau diese Reihenfolge vergessen die Leute zu notieren.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Notieren Sie die Clientversionen, die Schnittstellen, den Resolver-Zustand und die Präfixe für jedes Netzwerk. Wenn ein Client aktualisiert wird und sein Routenverhalten ändert, ist diese Aufzeichnung der Unterschied zwischen einer Fünf-Minuten-Reparatur und einem Neuaufbau. Die nächste Person teilt nicht Ihre Erinnerung daran, welcher Tunnel zuerst hochkam.

Die Checkliste ist vollständig, wenn Sie die Schnittstelle nennen können, die die Standardroute besitzt, den Resolver, den jeder Name verwendet, das Muster, das den zweiten Tunnel trennt, und das Ergebnis einer Anfrage pro Netzwerk nach einem Neustart. Alles darunter ist eine Konfiguration, die heute zufällig funktioniert.

Ähnliche Artikel