Routingtabelle gegen tatsächlichen Lookup: wohin VPN-Verkehr geht

Ein Routingtabellen-Auszug ist die am wenigsten nützliche Diagnose bei der VPN-Fehlersuche und die am häufigsten eingefügte. Vierzig Zeilen mit Präfixen sagen Ihnen, was die Maschine tun könnte, nicht was sie für die fehlgeschlagene Anfrage getan hat. Der Mechanismus, den Sie eigentlich wollen, ist der Lookup: bei dieser Quelle und diesem Ziel, welche Regel passte, welche Tabelle wurde befragt, und welche Schnittstelle und welcher nächste Hop kamen heraus. Beginnen Sie bei einem Ziel und einer Quelle, lesen Sie die Tabelle dann mit dieser Frage im Kopf, und dieselbe Ausgabe wird zur Beweislage statt zum Rauschen.

Eine Tabelle ist eine Menge von Kandidaten, keine Entscheidung

Jeder Eintrag beschreibt ein Präfix und was mit passendem Verkehr zu tun ist: ihn an eine Schnittstelle senden, an einen nächsten Hop übergeben oder verwerfen. Nichts in dieser Liste ist nach Absicht geordnet, und der Eintrag, der einem Menschen am spezifischsten erscheint, ist nicht immer der, den der Kernel auswählt, weil die Auswahl dem längsten Präfix-Match folgt und bei gleichen Präfixen der Metrik.

Der erste Schritt ist also, den Kernel zu fragen, statt die Liste zu lesen. Das Lookup-Kommando antwortet für ein Ziel, und mit einem Quellargument antwortet es für das genaue Paar, das eine weitergeleitete oder gebundene Verbindung verwenden würde:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Jede Adresse oben ist ein Dokumentationsbeispiel. Der Punkt ist die Form der Antwort: Schnittstelle, gewählte Quelladresse, Gateway und die Tabelle, aus der der Eintrag stammt. Wenn diese Ausgabe nicht zur erwarteten Schnittstelle passt, haben Sie das Problem mit einem einzigen Kommando lokalisiert, und kein Lesen der vollen Tabelle hätte Ihnen gesagt, welcher Kandidat gewonnen hat.

Der Lookup durchläuft zuerst Regeln, dann Tabellen

Unter Linux ist die Entscheidung zweistufig. Policy-Regeln werden nach Priorität ausgewertet, und die erste passende Regel benennt eine Tabelle, die befragt wird; diese Tabelle führt dann den längsten Präfix-Match aus. Eine Regel kann auf Quelle, Ziel, Firewall-Mark, Schnittstelle oder eine Kombination passen, weshalb ein Auszug der Haupttabelle völlig korrekt und für das untersuchte Paket völlig irrelevant sein kann.

ip rule show
ip route show table all | head -40
ip route show table 100

Wenn eine Regel Verkehr aus Ihrem VPN-Pool an Tabelle 100 sendet, dann ist Tabelle 100 die relevante, und die Haupttabelle ist ein Lockvogel. Das ist auch der Mechanismus hinter quellenbasiertem Routing auf einem Router: dasselbe Ziel kann zwei verschiedene Antworten haben, je nachdem, woher das Paket kam, und nur der Lookup mit Quellargument zeigt, welche gilt.

IPv6 hat eigene Regeln und Tabellen. Ein Design, das beide Familien betreibt, braucht beide Lookups, und eine funktionierende IPv4-Antwort sagt nichts über den v6-Pfad, den ein Dual-Stack-Client bevorzugen mag.

Was der VPN-Client installiert

Clients ersetzen normalerweise nicht die Standardroute, weil das den eigenen äußeren Pfad des Tunnels brechen würde. Sie installieren etwas Spezifischeres, das über die Präfixlänge gewinnt: ein Paar Halb-Standardrouten für 0.0.0.0/1 und 128.0.0.0/1 ist der klassische Trick, denn beide sind längere Präfixe als 0.0.0.0/0 und decken zusammen den gesamten Raum ab. Andere installieren bestimmte private Präfixe plus eine Policy-Regel, und manche fügen eine Markierung hinzu, sodass nur ausgewählter Verkehr erfasst wird.

Deshalb ist "das VPN hat meine Standardroute nicht geändert" kein Beweis für einen Fehler. Prüfen Sie, was es tatsächlich hinzugefügt hat, und ob das fragliche Ziel in diesen Präfixen liegt:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Zwei Halbrouten werden in einem Auszug leicht übersehen, weil sie nicht wie eine Standardroute aussehen. Eine Split-Tunnel-Konfiguration, die vergessen hat, ein Präfix aufzunehmen, erzeugt genau das Symptom, dem Sie nachjagen: die Anwendung, die den Tunnel nutzen sollte, löst stattdessen lokal auf und verbindet sich. Vergleichen Sie die installierten Präfixe mit den Zielen, die der Benutzer tatsächlich braucht, nicht mit den Adressen, die Sie zufällig getestet haben. Eine Split-Tunnel-Liste, die den Dateiserver abdeckt, aber nicht dessen Resolver, erzeugt eine Verbindung, die zu einer öffentlichen Adresse auflöst und dann bei der Authentifizierung scheitert, was wie ein Passwortproblem aussieht und ein Routenproblem ist.

Auch die äußere Route muss überleben

Der Tunnel ist selbst Verkehr. Die Pakete, die die gekapselte Nutzlast tragen, gehen über die physische Schnittstelle an die Adresse des Peers, und dieser Pfad darf nicht zurück in den Tunnel geroutet werden. Wenn doch, erhalten Sie den charakteristischen Fehler, bei dem der Tunnel aufgebaut wird und dann aufhört, Verkehr durchzulassen, weil der Transport für den Tunnel nun im Tunnel liegt.

Prüfen Sie die Peer-Adresse so, wie Sie das innere Ziel geprüft haben, und bestätigen Sie, dass sie auf die physische Schnittstelle statt auf den Tunnel auflöst:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Eine rekursive Route, eine Policy-Regel, die den Peer einfängt, oder eine Standardroute, die durch einen Full-Tunnel-Client ersetzt wurde, sind die drei üblichen Ursachen. Alle drei sind im äußeren Lookup sichtbar, und keine davon ist in einem nachträglich erstellten Auszug der Haupttabelle sichtbar.

Was Routing-Ausgaben Ihnen nicht sagen können

Ein korrekter Lookup bedeutet, dass der Kernel das Paket an einen sinnvollen Ort senden würde. Es bedeutet nicht, dass die Firewall es erlaubt, die IPsec-Policy es abdeckt, die NAT-Regel es übersetzt oder die Gegenseite eine Rückroute hat. Jedes davon ist eine spätere Stufe, und die strongSwan-Hinweise zur Weiterleitung beschreiben die Kette, die ein Paket an beiden Enden passieren muss.

Es berücksichtigt auch keine Bindung auf Anwendungsebene. Ein Prozess kann sich an eine Schnittstelle binden, eine Markierung setzen oder einen eigenen Resolver verwenden und sich über einen Namen verbinden, der anders auflöst als der getestete. Wenn der Lookup stimmt und die Verbindung trotzdem scheitert, ist die nächste Frage, welcher Prozess sie aufbaut und ob dieser Prozess dieselbe Tabelle sieht wie Sie.

Halten Sie die Diagnose also geordnet: Benennen Sie Ziel und Quelle, führen Sie den Lookup aus, lesen Sie nur die Tabelle und Regel, die der Lookup benannt hat, und testen Sie dann die nächste Stufe. Diese Reihenfolge hält eine Routing-Untersuchung im Minutenbereich und hinterlässt eine Aufzeichnung, der andere folgen können, was eine eingefügte Tabelle nie tut.