Versteckt ein VPN-Routen-Cache Ihre Änderung? Prüfen Sie drei Dinge

Den Routen-Cache zu leeren ist der erste Instinkt, wenn eine Änderung nicht wirkt, und auf modernem Linux ist es verschwendete Mühe: Der globale IPv4-Routen-Cache wurde vor Jahren entfernt, also gibt ip route show cache nichts aus, und es gibt nichts zu löschen. Der Zustand, der Sie täuscht, lebt eine Schicht höher: in einem Socket, einer NAT-Zuordnung, einem Resolver oder einem Netzwerkmanager, der das alte Profil erneut angewandt hat. Drei Fragen trennen diese Fälle: Kommt der falsche Weg aus einem neuen Flow oder einer alten Verbindung, speichert Ihre Plattform überhaupt Routen im Cache, und liegt der Zustand im Routing oder darüber. Beantworten Sie sie, bevor Sie eine Schnittstelle zurücksetzen.

Prüfung eins: Kommt der alte Weg aus einem neuen Flow?

Eine bestehende Verbindung behält die Route, mit der sie erstellt wurde. Deshalb überlebt eine SSH-Sitzung über den Tunnel eine Änderung der Routentabelle, während eine neue Sitzung sofort den neuen Weg nimmt, und deshalb heißt „die Änderung hat nichts bewirkt“ oft „der alte Socket hält sie noch“. Testen Sie mit einem neuen Prozess, nicht mit dem Fenster, das Sie bereits offen haben.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Der letzte Befehl gibt die Adresse aus, die die neue Verbindung tatsächlich erreicht hat, was der billigste Weg ist, den echten Pfad zu sehen, ohne einem Statusfenster zu vertrauen. Vergleichen Sie sie mit der Quelladresse, die der Namespace oder die Schnittstelle hätte verwenden sollen.

Wenn ein frischer Flow den richtigen Weg nimmt und der alte sich nicht erholt, hören Sie auf, auf das Routing zu schauen. Die Route war richtig; die Sitzung war alt.

Prüfung zwei: Speichert Ihre Plattform überhaupt einen Routen-Cache?

Unter Linux lautet die Antwort nein, in dem Sinne, den die meisten Anleitungen meinen. Es gibt keinen globalen Ziel-Cache, den man verwerfen könnte, und der Socket-Eintrag, der eine gewählte Route hält, wird mit dem Socket freigegeben. Der Cache-Abschnitt des ip-route-Handbuchs beschreibt historisches Verhalten, nicht etwas, das Sie auf einem aktuellen Kernel leeren können.

Andere Plattformen unterscheiden sich, und hier geht das Kopieren von Ratschlägen schief. Windows hält einen Ziel-Cache, den Sie mit netsh interface ip delete destinationcache leeren können. BSD und macOS zeigen Nachschlagevorgänge pro Ziel über route -n get, und ihre Caches laufen nach ihrem eigenen Zeitplan ab. Ein Befehl, der auf einer davon funktioniert, bewirkt unter Linux gar nichts, weshalb dieselbe Lösung bei der Hälfte der Leute zu scheitern scheint, die sie ausprobieren.

Eine NAT- oder conntrack-Tabelle ist kein Routen-Cache, obwohl sie dasselbe Symptom erzeugt. Ein Flow, der vor Ihrer Änderung übersetzt wurde, behält seine Übersetzung, und conntrack -L zeigt ihn noch lange, nachdem die Routing-Richtlinie weitergezogen ist. Das ist veralteter Zustand, aber das Löschen von Routen berührt ihn nicht.

Prüfung drei: Liegt der Zustand im Routing oder darüber?

Lesen Sie den aktuellen Lookup, bevor Sie irgendetwas anderes lesen: ip route get für das Ziel, dann derselbe Befehl mit from und der Quelladresse, dann ip rule show. Wenn diese drei mit Ihrer Absicht übereinstimmen, ist das Routing nicht die Schicht zum Reparieren, und die veraltete Beobachtung kam von woanders.

Drei übliche Verdächtige sitzen über dem Routing. Ein Netzwerkmanager kann eine Route aus einem gespeicherten Profil Sekunden nach dem Löschen neu installieren, sodass Ihre Änderung rückgängig erscheint; prüfen Sie nmcli connection show --active und den Unit-Zustand, bevor Sie die Tabelle erneut bearbeiten. Ein Resolver-Cache liefert eine alte Adresse, was wie ein Routing-Fehler aussieht, bis Sie denselben Namen mit einem cacheumgehenden Werkzeug abfragen. Ein Verbindungspool einer Anwendung hält einen funktionierenden Socket zum alten Ziel und fragt den Kernel nie nach einer neuen Entscheidung.

Was die drei Antworten Sie schließen lassen

Setzen Sie die Antworten zusammen, und die Reparatur sagt sich meist selbst. Ein neuer Flow, der auf einer Plattform ohne Routen-Cache den falschen Weg nimmt, bedeutet, dass die Richtlinie wirklich falsch ist, also lesen Sie die Regeln und die Tabelle, die der Tunnel installiert hat. Ein neuer Flow, der den richtigen Weg nimmt, während die alte Sitzung stockt, bedeutet, dass die Anwendung oder der Socket das Problem ist. Korrekte Routen mit einer kaputten Beobachtung in beiden Fällen bedeuten, dass der Zustand über dem Routing liegt.

Widerstehen Sie der pauschalen Auffrischung. Den Netzwerk-Stack neu zu starten oder jede Route auf einer Maschine zu löschen, deren Standardroute der Tunnel ist, kann genau die Verbindung kappen, mit der Sie das reparieren, und es zerstört den Beweis, der Ihnen gesagt hätte, welche Schicht versagt hat.

Wenn Sie doch etwas leeren müssen, leeren Sie das kleinste Etwas, das zur Diagnose passt: die Sockets eines Prozesses, einen conntrack-Eintrag, den Resolver-Cache. Wiederholen Sie dann denselben Frisch-Flow-Test und notieren Sie, was sich geändert hat.

Halten Sie die drei Zustände in Ihren Notizen getrennt

Gespeicherte Konfiguration, aktueller Lookup und beobachteter Flow sind drei verschiedene Fakten, und sie zu „dem Cache“ zu verschmelzen ist das, was den Fehler schwer reproduzierbar macht. Notieren Sie das Profil oder die Unit, der die Route gehört, die Ausgabe von ip route get und Quelle und Ziel der tatsächlichen Verbindung.

Notieren Sie daneben die Plattform und die Client-Version, denn eine Lösung, die einen Windows-Ziel-Cache leert, ist keine Lösung für einen Linux-Host, und ein zwischen beiden kopiertes Verfahren lehrt die falsche Lektion. Wenn Sie das Problem an jemand anderen weitergeben, können diese drei Zeilen den fehlerhaften Zustand reproduzieren, statt zu raten.