Split-tunneling voor hotspot-clients is geen uitsluiting per app
Een app buiten de VPN houden verandert alleen de telefoon. De aangesloten laptop heeft een eigen doorstuurregel nodig, afgestemd op bron, bestemming en NAT.
Twee eisen die hetzelfde klinken zijn niet hetzelfde: „sluit deze app uit van de VPN” en „stuur deze ene bestemming buiten de VPN voor de laptop op mijn hotspot”. De eerste verandert hoe een socket op de telefoon een netwerk kiest. De tweede moet een beslissing over doorsturen veranderen voor een pakket dat van een ander apparaat kwam nadat de telefoon het al had geaccepteerd. De twee verwarren is hoe een hotspot-client eindigt met een uitzondering die altijd alleen voor de browser van de telefoon zelf gold.
Twee subsystemen bezitten de twee vragen
Android houdt app-netwerken en tethering gescheiden. App-sockets worden door de connectiviteitsstack aan een netwerk toegewezen, en een VPN-app bepaalt welke van zijn eigen sockets de tunnel in gaan. Doorgestuurde pakketten van een aangesloten client worden afgehandeld door het tethering-subsysteem, dat netd om routes, beleidsregels en vertaling op de downstream-interface vraagt.
Uitsluiting per app wordt beoordeeld wanneer een app een socket opent. Een doorgestuurd pakket bereikt die controle nooit, omdat het niet afkomstig is van een app-socket op dit apparaat. Dat is de hele reden waarom de twee instellingen elkaar niet kunnen vervangen, en het is geen fout in een van beide.
Wat uitsluiting per app werkelijk verandert
Een VpnService-builder kan pakketten benoemen die met addDisallowedApplication buiten de tunnel blijven, of de enige pakketten benoemen die met addAllowedApplication binnen zijn toegestaan. Die apps openen dan sockets op het onderliggende netwerk terwijl de VPN de standaardroute voor al het andere blijft bezitten.
De reikwijdte is precies: de eigen sockets van het pakket, op dit apparaat, zolang de tunnel actief is. Hij zegt niets over doorgestuurd verkeer, niets over een tweede apparaat en niets over pakketten die het systeem namens tethering verstuurt.
Het is ook geen bestemmingsbeheer. Een browser uitsluiten sluit elk adres uit dat die browser bereikt, inclusief het adres dat je in de tunnel wilde houden. Wanneer de eis een bestemming in plaats van een app noemt, is de app-kiezer naar zijn aard het verkeerde gereedschap.
Hoe een doorgestuurd pakket er voor de telefoon uitziet
Het pakket van de client komt op de hotspot-interface aan met een privébronadres dat de telefoon heeft toegewezen, zeg 192.168.43.20, en een openbare bestemming. Om het door te sturen heeft de telefoon een route naar een uplink en een vertaalregel nodig zodat antwoorden de weg terug vinden, omdat het privéadres van de client op het mobiele netwerk niets betekent.
Android drukt dat uit in beleidsregels die een routingtabel kiezen, en netd bouwt de relevante tabellen en regels opnieuw op wanneer netwerken en VPN's veranderen. Een tabelnummer, regelprioriteit of interfacenaam die uit een forumbericht is gekopieerd, of van hetzelfde model in een oudere release, vestigt geen blijvend eigenaarschap. Die herbouw is ook de reden waarom een handgeschreven regel een uur kan werken en na de volgende herverbinding stopt.
Welk beleid een hotspot-uitzondering echt nodig heeft
Schrijf de beslissing op als bron, bestemming en beoogd pad voordat je een regel aanraakt. De minimale vorm voor één goedgekeurde bestemming ziet er zo uit:
| 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 richtingen moeten volledig zijn. De directe tak heeft een bruikbare route nodig via de mobiele uplink die toevallig actueel is; de VPN-tak heeft de tunnelroute plus toestemming om door te sturen nodig. Elke bronvertaling moet bij de gekozen uitgang passen, omdat NAT op een tunnel-interface het tunneladres toont en niet het mobiele, en de retourweg dan niet overeenkomt met de heenweg.
Antwoorden moeten dezelfde downstream-client bereiken via gevolgde toestand of een expliciete route, en een teller voor uitgaande pakketten bewijst daar niets van. Houd ook het eigen buitenste transport van de VPN buiten de reikwijdte van de uitzondering, anders erven de dragerpakketten van de tunnel een beleid dat voor een webverzoek van een client is geschreven.
Eén gevangen adres is geen bestemming
Eén IPv4-adres uit een browser is een momentopname. Grote diensten antwoorden vanaf anycast of uit een roterende set edge-adressen, veel zijn dual-stack, en een login-stroom kan authenticatie- en telemetriehosts raken die de pagina nooit toont. Een uitzondering rond het adres dat je toevallig zag, breekt de volgende keer dat de dienst opnieuw balanceert.
Gebruik de gedocumenteerde adressen van de eigenaar van de dienst, of een bereik dat hij publiceert, en reken op beide adresfamilies. Als de eis niet als een stabiele set kan worden uitgedrukt, is het waarschijnlijk een beleidsvraag voor de dienst en geen routingtruc op een telefoon.
Verifieer vanaf de downstream-kant
Drie controles, in deze volgorde: de gekozen dienst vanaf de laptop, een gewone bestemming die in de VPN moet blijven, en een telefoon-app die onaangetast moet blijven. Herhaal daarna na een herverbinding en na een wijziging van de uplink, want dan worden de beleidstabellen opnieuw opgebouwd.
Als de deelimplementatie van de telefoon dat contract niet over een herverbinding kan vasthouden, verplaats het selectieve beleid naar een ondersteunde downstream-router in plaats van root-regels op het toestel te stapelen. Een router kan bron- en bestemmingsmatching met een stabiele eigenaar uitdrukken, en de documentatie van de tethering-module is de juiste referentie voor wat de telefoon werkelijk doet.