Was Policy-Routing am VPN-Verkehr ändert und was nicht

Policy-Routing beantwortet eine andere Frage als die, die die meisten Fehlerbehebungsnotizen stellen. Die Haupttabelle sagt, wohin ein Ziel geht; Policy-Regeln sagen, welche Tabelle überhaupt befragt wird, und sie können das anhand der Quelladresse, einer Paketmarkierung, oder der Schnittstelle entscheiden, auf der ein Paket ankam. Wenn sich ein Tunnel inkonsistent verhält, ist häufig die Regelmenge der Grund und die Routingtabelle häufig nicht.

Regeln wählen die Tabelle, dann wählt die Tabelle die Route

Jede Regel trägt eine Priorität, eine Übereinstimmungsbedingung und eine Zieltabelle. Der Kernel durchläuft die Regeln in Prioritätsreihenfolge und stoppt bei der ersten Übereinstimmung, führt dann eine gewöhnliche Suche nach dem längsten Präfix in dieser Tabelle aus. Eine Regel, die auf eine leere Tabelle zeigt, fällt auf das durch, was die nächste Regel auswählt, und so kann eine sorgfältig geschriebene Regel scheinbar nichts bewirken.

Deshalb erklärt ein Auszug der Haupttabelle selten einen funktionierenden VPN-Client. Clients fügen Regeln oft mit niedrigen Prioritätsnummern ein, lange vor der Standardregel der Haupttabelle, sodass das Paket nie die Route erreicht, die Sie anstarrten. Eine Metrik in der Haupttabelle zu senken, ändert nichts für Verkehr, der bereits umgeleitet wurde.

Eine Regel kann ein Präfix auch absichtlich ins Leere laufen lassen oder unerreichbar machen. Manche Clients fügen eine solche Regel als Kill-Switch hinzu, und dann sieht der Verwerf nicht wie ein konfigurierter, sondern wie ein kaputter Tunnel aus.

Lesen Sie die Regelmenge als Abfolge, nicht als Liste

Geben Sie die Regeln mit ihren Prioritäten und den Tabellen aus, auf die sie verweisen, und geben Sie dann jede Tabelle aus, die eine Standard- oder Tunnelroute trägt. Die Reihenfolge ist der Teil, auf den es ankommt, und sie ist der Teil, den ein Screenshot meist auslässt:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Die letzten beiden Befehle sind die, die aus einer Theorie eine Beobachtung machen, weil sie fragen, was der Kernel für diese Quelle und diese Markierung tun würde. Ändert sich die Antwort, wenn sich die Markierung ändert, ist eine markierungsbasierte Regel im Spiel, und jeder Test, der die Markierung auslässt, testet ein anderes Paket. Die äußere Verbindung verdient eine eigene Regel. Ein Tunnel, der den gesamten Verkehr durch sich selbst leitet, muss die Endpunktadresse ausschließen, mit der er sich verbindet, sonst werden die verschlüsselten Pakete in den Tunnel zurückgeschickt, den sie gerade verlassen haben. Die meisten Clients fügen diesen Ausschluss automatisch ein, und eine handbearbeitete Regelmenge ist der Ort, an dem er fehlt.

Markierungen und Sockets: zwei Wege, wie Clients Verkehr aufteilen

Manche Clients markieren Pakete in der Firewall und fügen eine Regel hinzu, die auf die Markierung passt. Andere verwenden Routing auf Socket-Ebene und setzen eine Route auf dem Socket, bevor er sich verbindet. Ersteres ist in ip rule sichtbar; letzteres nicht, und es erscheint nicht in einem generischen Lookup.

Verhält sich ein Testprogramm anders als die Anwendung, die es vertreten soll, prüfen Sie, ob die Anwendung eine Markierung setzt oder sich an ein Gerät bindet. Dieser Unterschied ist kein Rätsel, sobald der Mechanismus benannt ist, und er erklärt, warum ein curl aus einer Shell und ein Browser-Tab auf derselben Maschine verschiedene Wege nehmen können. Beide Verfahren sind Policy-Routing im weiteren Sinne: Sie wählen einen Pfad anhand von etwas anderem als dem Ziel. Keines von beiden autorisiert den Verkehr, und keines ersetzt die Firewall-Regeln oder die Anmeldedaten, die der Peer erwartet.

Verfolgen Sie die Eigentümerschaft, bevor Sie eine weitere Regel hinzufügen

Regeln werden von etwas installiert. Ein VPN-Client, ein Netzwerkmanager und ein handgeschriebenes Skript können jeweils beim Start Regeln hinzufügen, und Wiederverbindungslogik kann die vorherige Menge zurücklassen. Zwei veraltete Regeln aus einem früheren Profil lenken den Verkehr noch lange weiter, nachdem das Profil gelöscht wurde.

Finden Sie heraus, welcher Prozess die Regel besitzt, anhand ihrer Priorität und ihrer Form, und prüfen Sie, ob dieser Eigentümer die Menge bei jeder Verbindung neu schreibt. Tut er das, verschwindet eine heute hinzugefügte manuelle Regel morgen, und die Korrektur gehört in die Konfiguration des Clients statt in eine Shell-History-Datei. Die gesamte Regelmenge zum Testen zu leeren, ist eine verlockende Abkürzung mit vorhersehbaren Kosten: Sie entfernt auch die Regeln, die der Client braucht, damit sein eigener Tunnel funktioniert. Löschen Sie jeweils eine Regel, oder testen Sie auf einer Maschine, die Sie neu starten können.

Beweisen Sie den Umfang mit zwei Flüssen, nicht mit einem

Eine Korrektur wird nur durch einen Fluss verifiziert, der betroffen sein sollte, und einen, der es nicht sein sollte. Wählen Sie ein Ziel, das die Policy in den Tunnel leitet, und eines, das sie draußen lassen muss, und vergleichen Sie dann die Lookups und die Mitschnitte für beide:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Wenn die beiden Lookups verschiedene Schnittstellen liefern, tut die Regel etwas. Wenn sie dieselbe Schnittstelle liefern, passt die Regel breiter als beabsichtigt, und das ist der Fehler, der still ein ganzes Subnetz durch einen Tunnel schickt, der für eine einzige Anwendung gedacht war.

Notieren Sie die Regelprioritäten und den besitzenden Dienst im Ticket, zusammen mit den beiden Testadressen. Die nächste Person hat dann ein reproduzierbares Paar statt einer Beschreibung eines Symptoms und kann innerhalb einer Minute sagen, ob Policy-Routing noch im Spiel ist.