Wenn sich Split-Tunneling-Routen überschneiden: welches Präfix gewinnt

Zwei Split-Tunneling-Profile, zwei private Präfixe und ein Host, den beide beanspruchen. Das Symptom ist selten ein sauberer Ausfall: Ein Dienst läuft am Montag, läuft nach dem erneuten Verbinden des zweiten Clients in eine Zeitüberschreitung und läuft nach einem Neustart wieder. Die Reihenfolge, in der Sie die Clients verbunden haben, entscheidet das Ergebnis nicht, und die Reihenfolge der Zeilen in der Oberfläche des Clients auch nicht. Führen Sie diese Prüfungen der Reihe nach aus, und halten Sie bei der ersten an, die nicht zutrifft, denn die späteren ergeben erst Sinn, wenn die früheren stimmen.

1. Notieren Sie das Ziel und die Quelle

Beginnen Sie mit der genauen Adresse, an die die fehlschlagende Anfrage geht, nicht mit dem Hostnamen und nicht mit dem Anwendungsnamen. Lösen Sie den Namen einmal auf, notieren Sie jede Antwort und wählen Sie die, die der fehlschlagende Fluss tatsächlich nutzt. Notieren Sie dann die lokale Adresse desselben Flusses, denn die Quelladresse kann ändern, welche Richtlinienregel passt und damit, welche Tabelle konsultiert wird.

Eine Anfrage an einen von mehreren A-Einträgen kann fehlschlagen, während eine Schwesteradresse erfolgreich ist, was wie ein unzuverlässiger Tunnel aussieht und in Wahrheit zwei verschiedene Pfade sind. Wenn das Ziel ein Name mit mehreren Antworten ist, testen Sie jede Antwort einzeln, bevor Sie etwas ändern.

2. Fragen Sie den Kernel, welche Route er gewählt hat

Lesen Sie die Routentabelle nicht und leiten Sie die Antwort nicht daraus ab. Stellen Sie dieselbe Frage, die der Stack stellt, mit derselben Quelladresse: ip route get 10.20.4.10 from 10.8.0.2 unter Linux oder Find-NetRoute -RemoteIPAddress 10.20.4.10 in PowerShell. Die Ausgabe nennt die Route, die tatsächlich verwendet würde, und das ist oft nicht die, die Sie beim Lesen der Tabelle erwartet haben.

Unter den passenden Routen gewinnt normalerweise das spezifischere Präfix: Ein /24 schlägt ein /16 für eine Adresse, die in beiden liegt. Bei Treffern gleicher Länge gewinnt die niedrigere Metrik, und eine Route, die auf einer ausgefallenen Verbindung installiert ist, wird übersprungen. Zwei Tunnel, die dasselbe /24 mit derselben Metrik bekannt machen, sind ein anderer Fall: Der Kernel behält beide Routen und wählt zwischen ihnen aus, sodass das Ergebnis wechseln kann, statt der Reihenfolge zu folgen, in der die Clients verbunden wurden. Genau diese Situation erzeugt das Muster Montag läuft es, Dienstag nicht, und ein erneutes Verbinden in anderer Reihenfolge ändert daran nichts.

3. Prüfen Sie, ob eine Richtlinienregel die Suche umgeleitet hat

Bevor die Routentabelle konsultiert wird, durchläuft der Kernel seine Richtlinienregeln. Eine Regel kann Datenverkehr von einer bestimmten Quelle, einem Benutzer oder einer Firewall-Markierung in eine völlig andere Tabelle schicken, sodass das gewinnende Präfix in der Haupttabelle für diesen Fluss möglicherweise nie konsultiert wird. ip rule show listet sie in Auswertungsreihenfolge auf, und ip route show table 100 zeigt, was die ausgewählte Tabelle tatsächlich enthält.

Hier lauern zwei Fallen. Eine Regel, die auf eine leere Tabelle zeigt, erzeugt eine Suche, die zur nächsten Regel durchfällt, sodass die Regel nichts zu tun scheint. Die andere ist die Prioritätsnummer selbst: Regeln werden aufsteigend gelesen, und die eingebauten Werte sind 0 local, 32766 main und 32767 default. Eine Regel mit einer Nummer unter 32767 wird vor der Standardregel konsultiert, die alles abfängt. Eine Regel mit einer Nummer über 32767 liegt dahinter und wird nur erreicht, wenn keine frühere Tabelle antwortet, was eine normale Standardroute in main verhindert, sodass sie in der Praxis nie erreicht wird und stillschweigend nichts tut, während sie installiert aussieht. Wenn der Client eine Regel und eine Route geschrieben hat, prüfen Sie beides, und prüfen Sie es nach einem erneuten Verbinden noch einmal, denn ein neu geschriebenes Profil kann eine zweite Regel mit anderer Priorität hinzufügen.

4. Trennen Sie ein Routing-Unentschieden von einem doppelten Adressplan

Manchmal ist das Präfix überhaupt nicht das Problem. Zwei Standorte, die beide 192.168.1.0/24 verwenden, bedeuten, dass dieselbe Adresse zwei verschiedene Hosts bezeichnet, und keine Route kann sie auseinanderhalten. Eine Host-Route auf eine der beiden Antworten funktioniert nur so lange, bis der andere Standort für denselben Namen antwortet, und dann wird die Ausnahme stillschweigend zum Fehler.

Der Hinweis ist, dass die Zieladresse auf beiden Pfaden identisch ist und sich nur der vorgesehene Eigentümer unterscheidet. Das ist eine Entscheidung zum Adressplan, keine Routing-Anpassung: Nummerieren Sie eine Seite neu, setzen Sie eine Seite hinter ein übersetzendes Gateway, oder erreichen Sie den zweiten Standort über einen Proxy, der seine eigenen Namen auflöst. Eine Standardroute abzusenken oder Host-Ausnahmen zu stapeln verschiebt nur die Kollision.

5. Bestätigen Sie, dass der Resolver mit der Route übereinstimmt

Ein Name, der auf die falsche private Adresse auflöst, erzeugt jedes Symptom eines Routing-Konflikts und keine seiner Ursachen. Vergleichen Sie die Antwort, die der Host erhält, mit der Adresse, die das Ziel tatsächlich verwendet, und prüfen Sie, welcher Resolver geantwortet hat. Wenn der Tunnel einen Resolver vorgibt, sollte der Client ihn für die Flüsse installieren, die den Tunnel nutzen; wenn nicht, fragt der Host weiter den lokalen Resolver, der aus einer Suchdomäne oder einem zwischengespeicherten Eintrag antworten kann.

Fragen Sie den Resolver direkt und notieren Sie den Server, der geantwortet hat. Eine zwischengespeicherte Antwort mit kurzer TTL kann auch erklären, warum sich die erste Anfrage nach einem erneuten Verbinden anders verhält als die fünfte.

6. Verbinden Sie erneut, prüfen Sie den angewandten Zustand, und testen Sie dann beide Flüsse

Verbinden Sie nach einer Korrektur erneut und prüfen Sie, was der Client tatsächlich installiert hat, statt dem Profil-Editor zu vertrauen. Lesen Sie die Regeln, die Tabellen und die daraus folgende Antwort von ip route get erneut. Ein zweiter Client kann beim Verbinden seine eigene Route neu installieren und den Konflikt neu erzeugen, weshalb die Zustandsprüfung nach dem Verbinden des letzten Clients erfolgen muss und nicht davor.

Testen Sie zwei Flüsse, nicht einen: die Anfrage, die früher fehlschlug, und eine Ressource, die den anderen Tunnel nutzen soll. Wenn Sie den gesamten privaten Datenverkehr auf eine Verbindung legen, besteht der erste Test, während der zweite bricht, und nur ein gepaarter Test erkennt das. Notieren Sie jede Ausnahme, die Sie behalten, mit Ziel und Begründung, damit die nächste Person eine bewusste Host-Route von einer übrig gebliebenen unterscheiden kann.