VPN-Routenmetrik nach dem Verbinden geändert: Was das bedeutet
Eine niedrigere Metrik entscheidet nur zwischen gleich spezifischen Routen. Lesen Sie Politikregel, Präfix und Host-Route des Endpunkts, bevor Sie eine VPN-Routennummer bearbeiten.
Sie verbinden das VPN, führen route print aus, und die Standardroute trägt jetzt eine viel niedrigere Metrik als zuvor. Die naheliegende Schlussfolgerung ist, dass das VPN die Standardroute übernommen hat, weil seine Zahl kleiner ist. Manchmal ist genau das passiert. Oft ist die Metrik gar nicht der entscheidende Faktor, und sie zu ändern bringt nichts, weil die Wahl früher getroffen wurde, durch die Präfixlänge oder durch eine Politikregel.
Das Symptom ist real: Verkehr, der früher über den Wi-Fi-Adapter ging, geht jetzt durch den Tunnel, oder umgekehrt. Die Metrik ist eine Eingabe für eine Suche, die in einer festen Reihenfolge läuft, und genau diese Reihenfolge müssen Sie lesen, bevor Sie eine Zahl anfassen.
Womit die Zahl tatsächlich konkurriert
Der erste Vergleich ist Spezifität, nicht Präferenz. Eine Route für 10.20.0.0/16 schlägt 10.0.0.0/8, und beide schlagen 0.0.0.0/0, was ihre Metriken auch sagen. Ein VPN, das eine Standardroute mit der niedrigsten Metrik auf dem Rechner installiert, verliert trotzdem gegen jede spezifischere Route, die zum Ziel passt, einschließlich der Host-Route, die der Client für seinen eigenen Server installiert.
Deshalb kann ein niedrigerer Metrikwert einer Standardroute ein direkt verbundenes Subnetz nicht in den Tunnel zwingen. Wenn Sie dieses Subnetz im VPN haben wollen, fügen Sie eine Route für das Präfix hinzu oder wählen Sie die Tunnel-Tabelle mit einer Politikregel. Die Metrik ist der falsche Hebel für diese Aufgabe.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux entscheidet über die Tabelle vor der Metrik
Unter Linux konsultiert der Kernel zuerst die Politikdatenbank. ip rule listet die Regeln und die Tabellen auf, die sie auswählen, und ip route get 203.0.113.10 meldet die Tabelle, Route und Quelladresse, die der Kernel für dieses Ziel tatsächlich verwenden würde. Eine Metrik innerhalb von Tabelle 100 konkurriert nie mit einer Route in der Haupttabelle, weil die Regel die Tabelle ausgewählt hat, bevor eine Metrik verglichen wurde.
Deshalb kann eine Route in ip route show table all richtig aussehen und trotzdem keinen Verkehr tragen. Lesen Sie die Regel, die gepasst hat, dann die Tabelle, die sie ausgewählt hat, und vergleichen Sie dann die Routen darin. Ist die falsche Tabelle ausgewählt, hilft keine Metrikänderung in der anderen Tabelle.
Windows kombiniert zwei Metriken
Windows hat standardmäßig keine Politikdatenbank, kombiniert aber eine Routenmetrik mit einer Schnittstellenmetrik, und die automatische Schnittstellenmetrik kann sich mit Linkgeschwindigkeit und Adapterzustand ändern. Deshalb kann sich dieselbe Route anders verhalten, nachdem eine Dockingstation oder ein virtueller Adapter erscheint. Find-NetRoute -RemoteIPAddress 203.0.113.10 meldet die gewählte Quelladresse, den nächsten Hop und die Schnittstelle, was näher an der tatsächlichen Entscheidung ist als die rohe Tabelle.
Lesen Sie Routen- und Schnittstellenwerte zusammen. Eine höhere Schnittstellenmetrik kann Verkehr verschieben, ohne dass sich ein Routeneintrag ändert, und ein VPN-Client, dem seine Routen gehören, installiert sie beim Neuverbinden neu und verwirft Ihre Änderung.
Halten Sie den Tunnelendpunkt außerhalb des Tunnels
Jeder Tunnel braucht einen Weg zu seinem eigenen Server, der nicht durch den Tunnel läuft. Clients installieren eine Host-Route für den Endpunkt über das physische Gateway, und diese Route muss spezifischer bleiben als die Standardroute, die der Client hinzufügt. Löschen Sie sie, oder lassen Sie den Tunnel die Suche für diese Adresse gewinnen, und die gekapselten Pakete versuchen, in den Tunnel einzutreten, den sie aufbauen sollen. Die Verbindung scheitert oder läuft in einer Schleife.
Prüfen Sie diese Host-Route vor und nach jeder Metrikänderung: Sie sollte auf den physischen nächsten Hop zeigen und ein Neuverbinden überstehen. Wenn der Client sie besitzt, ändern Sie das Profil oder die verwaltete Konfiguration statt eines Laufzeitwerts, der überschrieben wird.
Prüfen Sie beide Adressfamilien und den App-Kontext
IPv4 und IPv6 sind getrennte Entscheidungen mit getrennten Tabellen. Ein VPN kann IPv4 tragen, während IPv6 weiter den lokalen Router nutzt, und eine Metrikänderung in der einen Familie sagt nichts über die andere. Prüfen Sie beides, dann den Anwendungskontext. Ein Prozess, der an eine Schnittstelle gebunden ist, ein Container-Namespace oder ein VPN pro App kann eine andere Tabelle sehen als Ihre Shell.
Prüfen Sie mit dem Werkzeug, das die Entscheidung für das echte Ziel meldet, nicht mit der vollständigen Tabellenauflistung. Ist die gewählte Route die vom Design beabsichtigte, hören Sie auf. Eine Metrik, die nicht die kleinste Zahl auf dem Bildschirm ist, ist kein Fehler, und sie dazu zu zwingen, kann den Endpunktpfad brechen, von dem der Tunnel abhängt.