App-basiertes vs. zielbasiertes Split-Tunneling: Was Sie wählen sollten

App-basiertes und zielbasiertes Split-Tunneling sind keine zwei Einstellungen für dieselbe Aufgabe. Das eine fragt, welcher Prozess ein Paket sendet; das andere fragt, wohin dieses Paket geht. Eine Regel für die erste Frage versagt still, wenn der Verkehr von einem Hilfsprozess kommt, und eine Regel für die zweite versagt, wenn ein Hostname auf eine Adresse auflöst, die Sie nie eingetragen haben. Wählen Sie das Objekt, das zur Anforderung passt, und beweisen Sie es mit zwei Testpaketen: eines, das den Tunnel nutzen muss, und eines, das ihn nicht nutzen darf.

Die beiden Regeln greifen auf verschiedenen Ebenen

Eine App-Regel wird oberhalb der Netzwerkschicht durchgesetzt, gegen die Identität, die das Betriebssystem dem Absender zuweist. Unter Android ist das die UID hinter einem Paket, und der VPN-Dienst entscheidet pro UID, ob Verkehr in den Tunnel gelangt. Zur Zieladresse wird nichts abgefragt, daher kann die ausgewählte App alles erreichen, und keine andere App erreicht das interne Netz.

Eine Zielregel wird auf dem Paket selbst durchgesetzt. Die Tunnel-Schnittstelle besitzt eine Menge von Präfixen, die Routingtabelle schickt passenden Verkehr hinein, und der sendende Prozess ist irrelevant. Deshalb deckt eine Zielregel einen Dienst, einen Drucker oder einen Batch-Job ab, den niemand eingetragen hat, und deshalb lässt sie sich auf einer Plattform, deren Client den Prozess nie ansieht, nicht als genau dieses Programm ausdrücken.

App-Regeln passen zu mobilen Clients und verwalteten Agenten

Android bietet die Wahl direkt an: VpnService.Builder.addAllowedApplication() und addDisallowedApplication() nehmen Paketnamen entgegen und setzen die Entscheidung pro UID durch, wie im VPN-Entwicklerleitfaden von Android beschrieben. iOS hat ein Äquivalent über VPN-Regeln pro App, die an Bundle-Identifier gebunden sind und meist über ein MDM-Profil statt von Hand verteilt werden.

Desktop-Clients sind die Schwachstelle. Die meisten VPN-Clients für Windows und macOS routen nach Ziel und bieten überhaupt keine Auswahl pro Prozess, weil der Tunnel-Treiber Pakete sieht, nicht Prozesse. Wenn Ihr Plan davon abhängt, eine Anwendung auf einem Laptop zu tunneln, prüfen Sie die tatsächlichen Fähigkeiten des Clients, bevor Sie darum herum planen; möglicherweise wählen Sie zwischen einer Zilliste und einem zweiten Rechner.

Ein oft übersehener Nebeneffekt: Auf diesen Plattformen können Sie eine App-Regel nicht mit Routen nachbilden. Eine Host-Route für den Server der App tunnelt den Verkehr aller zu diesem Server, einschließlich Browser und Updater.

Zielregeln passen zu Subnetzlisten und Standorterreichbarkeit

WireGuard macht das Modell explizit. AllowedIPs ist Kryptoschlüssel-Routing: Ein inneres Paket, dessen Ziel in der Liste eines Peers liegt, wird zu diesem Peer verschlüsselt, und alles andere verlässt das Netz unverschlüsselt über den normalen Pfad. Es gibt keinen Prozess zu benennen und keine Unklarheit darüber, was enthalten ist.

OpenVPN erreicht dasselbe über die geschobene Routingtabelle. route-nopull hindert den Server daran, Routen vorzugeben, danach deckt ein clientseitiges route 10.20.0.0 255.255.0.0 vpn_gateway genau das Büro-Präfix ab. IPv6 ist in jedem dieser Clients eine eigene Anweisung, und sie zu vergessen ist der häufigste Weg, um ein korrekt aussehendes IPv4-Split zu leaken.

Ein Hostname ist keine Route. Bietet das Profil ein Domänenfeld, behandeln Sie es als Namen, den der Client einmal auflöst, nicht als dauerhaften Adressbereich; Content-Delivery-Netzwerke und Load Balancer vergeben morgen andere Adressen.

Wo beide Modelle brechen: Helfer, gemeinsame Dienste, Resolver

Hilfsprozesse brechen App-Regeln auf eine Weise, die wie ein Serverfehler aussieht. Der Updater eines Browsers, ein Crash-Reporter, ein Synchronisierungsdienst unter SYSTEM und ein in ein anderes Paket eingebettetes WebView sind getrennte Identitäten, sodass das Tunneln des Browsers die eigentliche Anfrage außerhalb des Tunnels lassen kann. Umgekehrt ist es genauso verwirrend: Eine ausgeschlossene App, die eine gemeinsame Bibliothek innerhalb eines getunnelten Prozesses aufruft, hat ihren Verkehr weiterhin im Tunnel.

Zielregeln brechen bei gemeinsamen Diensten und bei Namen. Dateifreigaben, Drucker, internes DNS und der Lizenzserver liegen alle auf Adressen, daher gibt ein Ein-App-Tunnel dem Browser Zugriff, während das gemappte Laufwerk tot bleibt. Dieser Abdeckungsunterschied ist kein Fehler eines der Modelle, aber er ist der Grund, warum ein Ein-App-Tunnel so oft das VPN läuft und die Freigabe ist weg erzeugt.

Resolver durchkreuzen beides. Setzt der Client interne DNS-Server, nutzt das Betriebssystem aber DNS über HTTPS zu einem öffentlichen Resolver, kommt die Antwort von außerhalb des Tunnels, und die Zielregel passt möglicherweise nie. Prüfen Sie, welcher Resolver tatsächlich geantwortet hat, bevor Sie schließen, dass die Regel falsch ist, und bestätigen Sie clientseitig, ob er den Tunnel-Resolver überhaupt installiert hat. Ein Split, der DNS außerhalb des Tunnels lässt, sieht in der Routingtabelle perfekt aus und scheitert trotzdem an jedem internen Namen.

Ablauf: auswählen, anwenden, prüfen

Beginnen Sie bei der Anforderung, nicht beim Menü. Ist das Ziel nur diese App darf den Tunnel nutzen, brauchen Sie App-Regeln und eine Plattform, die sie unterstützt. Ist das Ziel diese Netze sind durch den Tunnel erreichbar, brauchen Sie Präfixe. Ist die Antwort beides, implementieren Sie es als zwei getrennte Steuerungen und notieren Sie, welche welchen Fehler verantwortet.

Wenden Sie die engste Form an, die Sie ausdrücken können, und prüfen Sie dann, indem Sie die Routingtabelle fragen statt das Status-Symbol des Clients:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Die ersten beiden Zeilen benennen die Schnittstelle, die ein echtes Ziel nutzen würde; wg show gibt die konfigurierte Präfixliste aus; unter Windows beantwortet Find-NetRoute dieselbe Frage, die der Stack beim Senden des Pakets beantwortet. Ist die Schnittstelle der Tunnel, hat die Regel gegriffen.

Testen Sie dann ein zweites Paket, das ausgeschlossen sein sollte, aus einer anderen Anwendung, an dasselbe Ziel. Notieren Sie im Ticket die Client-Version, den Regeltyp, die Präfix- oder Paketliste und die beiden beobachteten Ergebnisse. Genau dieses Ergebnispaar sagt dem nächsten Ingenieur, ob die Richtlinie falsch konfiguriert ist oder der Verkehr nie dazugehörte.