Linux-Policy-Routing prüfen, bevor Sie die Standardroute ändern

Ein VPN-Host antwortet auf einer Schnittstelle und weigert sich, Antworten durch den Tunnel zurückzusenden, und die Standardroute sieht korrekt aus. Hier hört die Haupttabelle auf, die ganze Geschichte zu sein. Linux kann per Policy-Regeln pro Paket eine Routing-Tabelle auswählen, und das VPN hat möglicherweise eine installiert. Lesen Sie die Regeln, bevor Sie die Standardroute anfassen.

Die Reihenfolge zählt: zuerst die Regeln, dann die Tabelle, die jede Regel auswählt.

Lesen Sie die Regeln in Prioritätsreihenfolge

Führen Sie ip rule show aus und lesen Sie von oben nach unten. Die Prioritätsnummer steuert die Auswertungsreihenfolge, und eine kleinere Nummer wird früher geprüft. Die Standardregel bei 32766 ist normalerweise die letzte, die zählt. Ist die Liste lang, speichern Sie sie in einer Datei, bevor Sie etwas ändern.

Notieren Sie für jede Regel die Priorität, die Übereinstimmung (Quelle, Markierung, Schnittstelle oder Ziel) und die Tabelle, auf die sie verweist. Eine Regel ohne nutzbare Tabelle ist eine Sackgasse, keine Route.

Machen Sie dasselbe für IPv6 mit ip -6 rule show. Eine Policy, die nur in der IPv4-Familie existiert, lässt die andere Familie auf der Haupttabelle.

Lesen Sie die Tabelle, die jede Regel auswählt

Verwenden Sie ip route show table <name or number> für jede referenzierte Tabelle. Vergleichen Sie ihre Routen mit der Schnittstelle und dem nächsten Hop, den Sie erwarten. Eine leere oder unvollständige Tabelle erklärt einen Fehler, den die Haupttabelle nicht erklären kann.

Die Haupttabelle kann weiterhin die Standardroute enthalten, und das ist in Ordnung. Wenn eine Regel Ihren Fluss zuerst in Tabelle 51820 schickt, ist die Hauptstandardroute für dieses Paket irrelevant.

Suchen Sie den Tabellennamen in /etc/iproute2/rt_tables, wenn die Nummer unbekannt ist. Diese Suche dauert eine Sekunde und verhindert einen langen Umweg.

Finden Sie heraus, wer die Regel installiert hat

NetworkManager, wg-quick und andere Skripte können Regeln dynamisch installieren. Das Löschen einer Regel zur Laufzeit kann beim nächsten Verbindungsaufbau rückgängig gemacht werden. Prüfen Sie die Konfiguration des Verwalters, bevor Sie eine konkurrierende Regel hinzufügen.

wg-quick fügt zum Beispiel eine markierte Regel und eine Tabelle für die erlaubten Adressen des Tunnels hinzu. Diese Regel ist der Grund, warum Datenverkehr zu diesen Adressen die Hauptstandardroute umgeht. Wenn Sie sie entfernen, ohne die Konfiguration zu ändern, stellt der nächste Start sie wieder her.

Bewahren Sie die äußere Route des Endpunkts und den Verwaltungszugang, während Sie prüfen. Leeren Sie nicht alle Regeln auf einem aktiven entfernten Gateway, um die Ausgabe zu vereinfachen. Eine Verwaltungssitzung, die die Änderung übersteht, gehört zum Test.

Testen Sie den Quellkontext, der zählt

Ein generisches ip route get beantwortet eine andere Frage als der Anwendungsfluss. Fügen Sie die Quelladresse hinzu, und die Markierung, falls das VPN eine verwendet, um den Pfad zu sehen, den das echte Paket nimmt. Testen Sie ein eingeschlossenes und ein ausgeschlossenes Ziel mit demselben Quellkontext. Wiederholen Sie das dann für IPv6, wenn der Host Dual-Stack fährt.

Führen Sie nach einer genehmigten Korrektur dieselben beiden Abfragen erneut aus und vergleichen Sie. Führen Sie ein Protokoll über die beabsichtigte Regel, die Tabelle und darüber, wie lange die Regel einen Neustart übersteht. Dieses Protokoll macht den nächsten Dienstneustart erklärbar statt rätselhaft. Die Handbuchseite zu ip-rule dokumentiert die Übereinstimmungsselektoren und die Tabellensyntax.