Wie Split-Tunneling entscheidet, welcher Datenverkehr das VPN nutzt

Split-Tunneling ist eine als Regelsatz ausgedrückte Routing-Richtlinie, und der Client ist nur das, was diese Regeln installiert. Die Trennung geschieht an zwei Stellen: passende Regeln, die für jedes Paket einen Pfad wählen, und Bindungen, die eine Anwendung an einer Schnittstelle festhalten, was auch immer die Tabelle sagt. Welcher Mechanismus Ihrem Client zugrunde liegt, erklärt die meisten Überraschungen, von denen Menschen berichten.

Eine Richtlinie, die Sie in einer Zeile formulieren können, ist prüfbar. Eine als schnelleres Surfen beschriebene Richtlinie ist es nicht, und sie sagt Ihnen nicht, welche Regel zu ändern ist, wenn eine Anfrage den falschen Weg nimmt.

Der Client installiert Regeln, der Kernel trifft die Wahl

Wenn der Tunnel hochkommt, fügt der Client Routen und oft auch Richtlinienregeln derselben Tabelle hinzu, die Ihre anderen Schnittstellen nutzen. Jedes Paket erreicht dann eine Suche, die sein Ziel mit jedem Kandidatenpräfix vergleicht und die spezifischste Übereinstimmung behält, während die Priorität Gleichstände zwischen Regeln entscheidet, die auf verschiedene Tabellen zeigen. Nichts in dieser Suche weiß, dass das Paket aus einem Browser-Tab und nicht aus einem Sicherungsjob kam. Die Regel, die gewinnt, ist die, welche den Pfad festlegt, und Sie können sie vor und nach der Änderung lesen.

Deshalb kann ein geteilter Tunnel willkürlich wirken. Zwei Ziele in einer Anwendung nehmen möglicherweise verschiedene Pfade, nur weil das eine Präfix enger ist als das andere.

Dieselbe Wahl gibt es auf jeder Plattform, auch wenn die Namen wechseln. Windows schiebt die Entscheidung in seine Filterplattform, Android legt über seinen VPN-Dienst eine Allowlist pro App offen, und macOS hängt den Tunnel an ein Gerät, das weiterhin der Routingtabelle folgt. Microsofts Routing-Hinweise lohnen für den Windows-Fall die Lektüre, und ein für eine Plattform geschriebener Leitfaden lässt sich selten unverändert auf eine andere übertragen.

Binding pro App und Zielpräfixe sind verschiedene Werkzeuge

Eine Zielrichtlinie fragt, wohin das Paket geht, und zieht die Routingtabelle oder eine Richtlinienregel zu Rate. Eine Richtlinie pro App fragt, welches Programm den Socket geöffnet hat, und die Plattform hält dieses Programm an der Tunnelschnittstelle, selbst wenn eine spezifischere Route woanders hinzeigt. Die zweite ist stärker, weil sie Tabellenänderungen übersteht, aber sie erfasst nur Prozesse, die die Plattform zuordnen kann. Ein Hilfsprozess, ein eingebetteter Browser oder ein Dienst, der seine eigene Verbindung öffnet, erbt möglicherweise nicht die Bindung, die Sie angenommen haben.

Keiner der beiden Ansätze übersteht eine namensbasierte Richtlinie ohne Hilfe. Adressen großer Websites rotieren über Content-Netzwerke, sodass das Festnageln eines Hostnamens an wenige Präfixe eine Regel erzeugt, die stillschweigend aufhört zu passen. Eine Richtlinie, die Namen folgen muss, braucht eine resolverbewusste Komponente statt einer statischen Route.

DNS und der Not-Aus-Schalter folgen ihren eigenen Regeln

Namensauflösung ist eine vom Paketrouting getrennte Entscheidung, und ein geteilter Tunnel will meist zwei Resolver: den der Firma für interne Namen, den lokalen für alles andere. Der Client kann DNS-Einstellungen pro Schnittstelle installieren, Abfragen an einen Stub-Resolver übergeben oder die Systemvorgabe unangetastet lassen. Ein Browser mit eigenem verschlüsseltem Resolver umgeht alle drei Arrangements. Testen Sie eine Abfrage, statt anzunehmen, der Resolver sei der Route gefolgt.

Ein Not-Aus-Schalter setzt einen Filter obendrauf, und dieser Filter unterscheidet nicht immer eine beabsichtigte Ausnahme von einem versehentlichen Leck. Manche Clients blockieren alles außerhalb des Tunnels, andere erlauben die Ausnahmen, die die Richtlinie erklärt, also lesen Sie, welches Verhalten Ihrer umsetzt, bevor Sie sich auf eines von beiden verlassen.

Prüfen Sie die Teilung von beiden Seiten

Testen Sie den eingeschlossenen Pfad und den ausgeschlossenen Pfad getrennt und beurteilen Sie das Ergebnis am Schnittstellennamen statt an einer öffentlichen Adresse. Diese Befehle setzen einen Linux-Host mit bereits hochgekommener Tunnelvorrichtung voraus. Ersetzen Sie 203.0.113.10 durch ein Ziel, das Ihre Richtlinie nach innen routet, und 198.51.100.25 durch eines, das sie nach außen schickt.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Lesen Sie die ersten beiden Antworten zusammen, denn die in jeder genannte Schnittstelle zeigt, ob die Teilung dieses Ziel auf den Tunnel gelegt hat. Die Resolver-Abfrage zeigt, welcher Server den internen Namen beantwortet hat, und der letzte Befehl beweist, dass die Tunnelvorrichtung überhaupt eine Anfrage tragen kann. Ein Fehler in der zweiten Zeile, während die erste gelingt, bedeutet, dass die Richtlinie genau das tut, was ihr gesagt wurde.

Wiederholen Sie den Satz nach einem erneuten Verbinden und nach einer Netzwerkänderung. Lease-Erneuerung und Schnittstellenwechsel sind die Stellen, an denen eine Teilung aufhört, der Absicht zu entsprechen, für die sie gebaut wurde, und eine gespeicherte Ausgabe jedes Laufs macht die Drift offensichtlich.