Warum ein Subnetz die Standardroute der VPN immer noch umgeht

Sie schalten die VPN auf vollen Tunnel, der meiste Verkehr spurt, und dann antwortet eine Adresse direkt — ein Drucker, ein NAS, ein Jump-Host unter 10.x. Die naheliegende Deutung ist, dass der Tunnel leckt, also senken Sie die Metrik der Standardroute und nichts ändert sich. Dieser fehlgeschlagene Versuch ist der Hinweis: Eine Standardroute ist ein Rückfall, kein Urteil. Die Routensuche nimmt das längste passende Präfix, bevor sie überhaupt Metriken vergleicht, also gewinnt ein /24 weiterhin gegen ein /0, egal welche Zahl Sie an eines der beiden hängen. Ist diese Reihenfolge klar, ist das Leck meist eine Route, die jemand absichtlich installiert hat, oder ein Präfix, das der Client nie abdecken wollte.

Was eine Standardroute tatsächlich verspricht

0.0.0.0/0 passt auf jedes IPv4-Ziel mit null Bits Spezifität. Sie existiert, damit ein Host alles erreicht, was seine Tabelle nicht besser beschreibt. Eine Route nach 192.168.1.0/24 trägt 24 passende Bits, für 192.168.1.40 gewinnt sie also, bevor jemand Metriken, administrative Distanz oder wie auch immer der Client sein Prioritätsfeld nennt vergleicht. Dieselbe Regel gilt in der Linux-FIB, der Windows-Routingtabelle und dem BSD-Stack hinter macOS.

In einem normalen LAN ist dieses Verhalten eine Funktion. Das lokale Subnetz ist direkt angebunden, der Drucker läuft weiter, während der Tunnel Ihr Surfen trägt, und nichts ist falsch konfiguriert. Die Frage, die sich lohnt, ist nicht, warum diese eine Adresse direkt geht, sondern welches Präfix in welcher Tabelle darauf passt und wer es dort hingesetzt hat.

Halb-Standardrouten, oder warum der Standardeintrag unberührt aussehen kann

Das sauberste Beispiel ist redirect-gateway def1 bei OpenVPN. Statt Ihre Standardroute zu löschen und zu ersetzen, fügt es 0.0.0.0/1 und 128.0.0.0/1 hinzu. Zusammen deckt das Paar ganz IPv4 ab, jedes Präfix ist länger als /0, und beide schlagen die Standardroute des Routers, während sie an Ort und Stelle bleibt. Führen Sie danach eine Routenauflistung aus, und die ursprüngliche Standardroute ist noch da, zeigt noch auf Ihr Gateway; sie wird nur nie für Internetziele ausgewählt.

WireGuards wg-quick erreicht dasselbe über Policy-Routing. Wenn AllowedIPs 0.0.0.0/0 abdeckt, legt es eine eigene Tabelle an, schickt markierte Pakete dorthin und fügt eine Regel hinzu, die das Präfix der Länge null der Haupttabelle ignoriert. Die Haupttabelle behält ihren Standardeintrag, und die Regeln bestimmen, dass die Tunnel-Tabelle zuerst für den Verkehr befragt wird, den die Schnittstelle besitzt.

Beide Entwürfe brauchen genau eine Route außerhalb des Tunnels: eine Host-Route zur eigenen Adresse des VPN-Servers über das ursprüngliche Gateway. Ohne sie würde der Client versuchen, die Pakete, die den Tunnel aufbauen, innerhalb des Tunnels zu tragen, und die Verbindung käme nie zustande. Eine Nicht-Tunnel-Route in Ihrer Tabelle ist daher auch bei einem strikten Volltunnelprofil normal. Fragwürdig sind die Routen, die Ziele abdecken, die Ihnen wirklich wichtig sind.

Metriken entscheiden Gleichstand, Präfixe entscheiden Sieger

Metriken werden nur unter Kandidaten verglichen, die das Ziel gleich gut treffen. Unter Linux ip route get 10.20.5.9 gibt den Gewinner samt seiner Tabelle aus, und ip route show table all listet die Kandidaten auf, einschließlich etwaiger Halb-Standardrouten und jeder Tabelle, auf die eine Regel zeigt. Unter Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 liefert die gewählte Route und Quelladresse, während Get-NetRoute die rohe Tabelle zeigt — aber die effektiven Kosten sind Routenmetrik plus Schnittstellenmetrik, sodass ein langsamer Adapter einen Gleichstand verlieren kann, den er scheinbar gewinnt.

Drei Fälle decken das meiste ab, was Sie sehen werden:

• Gleiches Ziel, /24 gegen /0: Das /24 gewinnt über die Präfixlänge, was die Metriken auch sagen.
• Gleiches Ziel, zwei /24 mit unterschiedlichen Metriken: Die niedrigere effektive Metrik gewinnt.
• Gleiches Ziel, zwei Tabellen, eine durch eine Policy-Regel gewählt: Die Regel wählt zuerst die Tabelle, und der Präfixvergleich findet in ihr statt.

Der dritte Fall ist der, in dem die meisten dieser Berichte enden. Eine ip rule unter Linux oder ein Windows-VPN-Verkehrsfilter kann Verkehr in eine Tabelle schicken, die nie die Tunnel-Standardroute enthielt, und die Haupttabelle sieht die ganze Zeit perfekt aus.

Wem die Umgehung meist gehört

Fangen Sie beim Profil an, nicht bei der Tabelle. Split-Tunnel-Konfigurationen und VPN-Einstellungen pro App lassen benannte Präfixe bewusst außerhalb des Tunnels; ein Arbeitsprofil, das ein privates Subnetz schützt und allgemeines Surfen direkt gehen lässt, verhält sich wie entworfen, und es zu überschreiben bricht die Richtlinie, die es durchsetzen sollte. Microsofts Leitfaden zum VPN-Routing zieht dieselbe Grenze zwischen zwangsgetunneltem Verkehr und ausdrücklichen Ausnahmen, was ihn zu einer nützlichen Gegenprobe macht, bevor Sie irgendetwas ändern.

Suchen Sie dann nach Überbleibseln. Eine Route, die auf eine Schnittstelle zeigt, die es nicht mehr gibt, oder auf eine Adresse aus dem vorherigen Netz, taucht auf, nachdem Dockingstationen, USB-Adapter und Container-Bridges kommen und gehen. Sie einmal zu löschen ist nicht das Ende: NetworkManager-Verbindungsprofile, netplan-Dateien und persistente Windows-Routen installieren sie beim nächsten Verbinden oder Booten neu, also finden Sie die Datei oder das Profil, dem sie gehört, bevor Sie etwas ändern.

Prüfen Sie dann IPv6 für sich. ip -6 route und Get-NetRoute -AddressFamily IPv6 halten getrennten Zustand, getrennte Standardrouten und getrenntes Clientverhalten. Eine reine IPv4-Prüfung sagt nichts über einen Dual-Stack-Host, der stillschweigend einen nativen IPv6-Pfad bevorzugt, und allein das kann einen Client wie Split-Tunnel aussehen lassen.

Bestätigen Sie mit dem eigenen Ablauf der Anwendung

Notieren Sie das Ziel, das die Anwendung tatsächlich nutzt, und fragen Sie dann das System nach dem Pfad, den es von der Quelladresse aus nehmen würde, an die diese Anwendung bindet. ip route get 10.20.5.9 from 192.168.1.40 beantwortet das unter Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus die lokale Adresse tut es unter Windows. Vergleichen Sie das Ergebnis mit dem, was das Profil behauptet. Die öffentliche IP-Seite eines Browsers testet ein Ziel über ein Protokoll und sagt nichts über die private Adresse, die die Beschwerde ausgelöst hat.

Beheben Sie das engste Objekt, das den Unterschied erklärt. Ist die Ausnahme genehmigt, schreiben Sie das Präfix auf und lassen Sie es in Ruhe; wenn nicht, entfernen Sie die Route oder fügen Sie eine ausdrücklich engere Route durch den Tunnel hinzu, statt die Metrik der Standardroute zu senken. Eine gesenkte Metrik kann ein längeres Präfix nicht überbieten, und die Standardroute zu ändern, während zwei /1-Routen den Internetpfad besitzen, ändert ebenfalls nichts.

Verbinden Sie dann den Tunnel neu und wiederholen Sie dieselbe Abfrage. Clients installieren bei jeder Verbindung Routen neu, eine Änderung, die nur bis zum nächsten Handshake hält, ist also nicht getestet. Weicht der Pfad weiter ab, sind die verbleibenden Verdächtigen eine Policy-Regel, eine zweite Tabelle oder ein clientseitiger Filter — nicht die Standardroute.

• Benennen Sie das Ziel und die Quelladresse, die die App wirklich nutzt.
• Geben Sie die gewinnende Route mit ip route get oder Find-NetRoute aus.
• Prüfen Sie, ob ein /1-Paar oder eine Policy-Tabelle den Internetpfad besitzt.
• Listen Sie jedes Präfix auf, das länger als /0 ist und auf das Ziel passt.
• Wiederholen Sie die IPv6-Prüfung separat.
• Verfolgen Sie die überlebende Route zurück zu der Datei, dem Profil oder dem Filter, der sie installiert.
• Verbinden Sie neu und führen Sie die Abfrage erneut aus, bevor Sie es als behoben bezeichnen.

Stimmen alle sieben mit dem Profil überein, tut der Tunnel genau das, wofür er konfiguriert wurde, und die Korrektur gehört ins Profil statt in eine Metrik.