Split-Tunneling für Hotspot-Clients ist kein App-Ausschluss
Eine App vom VPN auszunehmen, ändert nur das Telefon. Ein angebundener Laptop braucht eine eigene Weiterleitungsregel, abgeglichen über Quelle, Ziel und NAT.
Zwei Anforderungen, die gleich klingen, sind es nicht: „diese App vom VPN ausnehmen“ und „dieses eine Ziel für den Laptop an meinem Hotspot am VPN vorbeischicken“. Die erste ändert, wie ein Socket auf dem Telefon ein Netzwerk auswählt. Die zweite muss eine Weiterleitungsentscheidung für ein Paket ändern, das von einem anderen Gerät kam, nachdem das Telefon es bereits angenommen hat. Beides zu verwechseln führt dazu, dass ein Hotspot-Client mit einer Ausnahme endet, die immer nur für den eigenen Browser des Telefons galt.
Zwei Teilsysteme besitzen die beiden Fragen
Android hält App-Netzwerke und Tethering getrennt. App-Sockets werden vom Konnektivitäts-Stack einem Netzwerk zugewiesen, und eine VPN-App entscheidet, welche ihrer eigenen Sockets in den Tunnel gehen. Weitergeleitete Pakete eines angebundenen Clients bearbeitet das Tethering-Teilsystem, das netd nach Routen, Policy-Regeln und Übersetzung auf der Downstream-Schnittstelle fragt.
Ein App-Ausschluss wird ausgewertet, wenn eine App einen Socket öffnet. Ein weitergeleitetes Paket erreicht diese Prüfung nie, weil es nicht von einem App-Socket auf diesem Gerät stammt. Genau deshalb können die beiden Einstellungen einander nicht ersetzen, und es ist kein Fehler in einer von beiden.
Was der App-Ausschluss tatsächlich ändert
Ein VpnService-Builder kann Pakete benennen, die mit addDisallowedApplication außerhalb des Tunnels bleiben, oder die einzigen Pakete benennen, die mit addAllowedApplication innerhalb erlaubt sind. Diese Apps öffnen dann Sockets im zugrunde liegenden Netzwerk, während das VPN weiterhin die Standardroute für alles andere besitzt.
Der Geltungsbereich ist präzise: die eigenen Sockets des Pakets, auf diesem Gerät, solange der Tunnel steht. Er sagt nichts über weitergeleiteten Verkehr, nichts über ein zweites Gerät und nichts über Pakete, die das System im Namen des Tetherings sendet.
Es ist auch keine Zielsteuerung. Eine App auszuschließen nimmt jede Adresse aus, die dieser Browser erreicht, einschließlich der, die im Tunnel bleiben sollte. Wenn die Anforderung ein Ziel statt einer App nennt, ist die App-Auswahl schon von der Konstruktion her das falsche Werkzeug.
Wie ein angebundenes Paket für das Telefon aussieht
Das Paket des Clients kommt an der Hotspot-Schnittstelle mit einer privaten Quelladresse an, die das Telefon vergeben hat, etwa 192.168.43.20, und einem öffentlichen Ziel. Zum Weiterleiten braucht das Telefon eine Route zu einem Uplink und eine Übersetzungsregel, damit Antworten zurückfinden, weil die private Adresse des Clients im Mobilfunknetz bedeutungslos ist.
Android drückt das mit Policy-Regeln aus, die eine Routing-Tabelle auswählen, und netd baut die relevanten Tabellen und Regeln neu auf, wenn sich Netzwerke und VPNs ändern. Eine Tabellennummer, Regelpriorität oder ein Schnittstellenname, aus einem Forumsbeitrag kopiert oder vom selben Modell in einer älteren Version, begründet keinen dauerhaften Besitz. Dieser Neuaufbau ist auch der Grund, warum eine handgeschriebene Regel eine Stunde lang funktionieren und nach der nächsten Wiederverbindung aufhören kann.
Welche Policy eine Hotspot-Ausnahme wirklich braucht
Schreiben Sie die Entscheidung als Quelle, Ziel und beabsichtigten Pfad auf, bevor Sie eine Regel anfassen. Die minimale Form für ein genehmigtes Ziel sieht so aus:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Beide Richtungen müssen vollständig sein. Der direkte Zweig braucht eine nutzbare Route über den Mobilfunk-Uplink, der gerade aktuell ist; der VPN-Zweig braucht die Tunnelroute plus die Erlaubnis weiterzuleiten. Jede Quellübersetzung muss zum gewählten Ausgang passen, weil NAT an einer Tunnelschnittstelle die Tunneladresse zeigt und nicht die Mobilfunkadresse, und der Rückweg dann nicht mit dem Hinweg übereinstimmt.
Antworten müssen denselben Downstream-Client über verfolgten Zustand oder eine ausdrückliche Route erreichen, und ein Zähler für ausgehende Pakete beweist davon nichts. Halten Sie auch den eigenen äußeren Transport des VPN außerhalb des Geltungsbereichs der Ausnahme, sonst erben die Trägerpakete des Tunnels eine Policy, die für eine Webanfrage eines Clients geschrieben wurde.
Eine erfasste Adresse ist kein Ziel
Eine einzelne aus einem Browser gelesene IPv4-Adresse ist eine Momentaufnahme. Große Dienste antworten per Anycast oder aus einem rotierenden Satz von Edge-Adressen, viele sind Dual-Stack, und ein Anmeldevorgang kann Authentifizierungs- und Telemetrie-Hosts berühren, die die Seite nie anzeigt. Eine Ausnahme, die um die zufällig gesehene Adresse gebaut ist, bricht beim nächsten Mal, wenn der Dienst neu ausbalanciert.
Nutzen Sie die dokumentierten Adressen des Diensteinhabers oder einen Bereich, den er veröffentlicht, und rechnen Sie mit beiden Adressfamilien. Lässt sich die Anforderung nicht als stabile Menge ausdrücken, ist es wohl eine Policy-Frage an den Dienst und kein Routing-Trick auf einem Telefon.
Prüfen Sie von der Downstream-Seite
Drei Prüfungen, in dieser Reihenfolge: der gewählte Dienst vom Laptop, ein gewöhnliches Ziel, das im VPN bleiben muss, und eine Telefon-App, die unberührt bleiben muss. Wiederholen Sie das dann nach einer Wiederverbindung und nach einem Uplink-Wechsel, denn dann werden die Policy-Tabellen neu aufgebaut.
Kann die Freigabe-Implementierung des Telefons diesen Vertrag über eine Wiederverbindung nicht halten, verlagern Sie die selektive Policy auf einen unterstützten Downstream-Router, statt Root-Regeln auf dem Handset anzuhäufen. Ein Router kann Quell- und Zielabgleich mit einem stabilen Eigentümer ausdrücken, und die Dokumentation des Tethering-Moduls ist die richtige Referenz dafür, was das Telefon tatsächlich tut.