Split-Tunneling an Android VpnService: wat sech tatsächlech routeiere léisst

Split-Tunneling an enger VpnService-App geet op e puer bestëmmte Plazen entzwei, an d'Reparatur ass fir jidderee verschidden. De Client weist just eng eenzeg Zil déi feelt, dofir ass déi éischt Aufgab erauszefannen, wéi eng Grenz Dir getraff hutt: d'Routen déi de Builder kritt huet, de Proxy deen Dir net authentifizéiere kënnt, de Resolver deen Dir just annoncéiert hutt, oder d'App-Lëscht déi d'Plattform pro Benotzer uwennnt. Genau dowéinst halen ech eng Kontroll an véier Schrëtt. Si leeft an der Rei hei drënner a stoppt beim éischte Feeler.

Confirméiert, wat de Builder der Plattform ginn huet

VpnService.Builder ass eng Lëscht vun Deklaratiounen. establish() gëtt e ParcelFileDescriptor fir eng virtuell Interface zréck, an d'Plattform schéckt nëmmen de Verkéier, deen zu den Präfixen aus addAddress an addRoute passt, an deen Deskriptor; addDnsServer seet de Clienten, wéi en Resolver se froe sollen. Eng Zil baussen all de Präfixen, déi Dir derbäigesat hutt, erreecht ni Är App, wat och ëmmer d'Interface versprécht. Dës eenzeg Tatsaach erkläert déi meescht Meldungen iwwer futti Split-Tunneling, ier nach Code geännert gëtt.

Logt d'Adress-, Routen- an DNS-Lëschten, déi Äre Builder zesummegesat huet, a vergläicht se mat den Zilen déi feelen. En /32 deen e Manager-Host feelt ass vill méi heefeg wéi en futti Tunnel. Ass d'Lëscht richteg, gitt weider; ass se falsch, ass de Rescht vun der Checkliste verschwend Aarbecht.

excludeRoute gëtt et eréischt vun API 33 un

D'Ausschlosser no Zil ass d'Ufro, déi am heefegsten an engem Support-Thread endet. builder.excludeRoute(IpPrefix) koum an API 33; virdru war déi eenzeg ënnerstëtzt Approximatioun, Routen fir alles ausser dem ausgeschlossene Präfix derbäizesetzen, wat heescht d'komplementär Präfixen selwer ze berechnen. Déi zwou Opruffen si keng Spigelbilder: deen een zitt vum Routen-Set vun der Interface of, deen anere baut de Set vun Null op, an en eelere Gerät werft en Opruff deen et net kennt oder ignoréiert en stëll. Verzweigt no Build.VERSION.SDK_INT a test béid Weeër op richteger Hardware.

Wann Dir Komplementer berechent, oppasst op d'Präfix-Ausriichtung. Eng /24-Ausschlosser bannent enger /16-Route brauch déi deckend Präfixen, déi de Rescht wierklech beschreiwen, net een eenzegen defekten /8. Logt déi lescht Lëscht a bestätegt, datt den ausgeschlossenen Host nach ëmmer iwwer e Wee baussen dem Tunnel opgeléist gëtt.

Proxy-Logindaten loosse sech net ausdrécken

setHttpProxy(ProxyInfo) riicht d'Interface op en HTTP- oder SOCKS-Proxy, an eng PAC-URL kann pro Zil tëschent deenen zwéin wielen. Weder ProxyInfo nach de PAC-Format droen e Benotzernumm a Passwuert, dofir bleift en authentifizéierte Proxy baussen der Plattform-API. Apps déi esou e brauchen, bauen meeschtens e Benotzerraum-Stack, tun2socks oder eng ähnlech Engine an, an äntweren selwer op d'407-Herausfuerderung.

Dës Wiel huet Konsequenzen. E Benotzerraum-Stack gesäit nëmme Verkéier deen Dir zu him routeet, dofir muss en an der selwechter Deskriptor-Grenz liewen, an en ierft déi selwecht protect()-Ufuerderung fir säin eegene Uplink-Socket. Loosst protect() ewech an den Tunnel fänkt säin eegenen Transport, wat als Handshake erschéngt deen nom éischte Paket hänkt. Testt géint e Proxy deen Zougangsdaten verlaangt, well en oppene Proxy duerch de Plattform-Wee kënnt an näischt beweist.

App-Lëschten an DNS sinn och Deklaratiounen

De Builder huet addAllowedApplication an addDisallowedApplication, an se schléissen sech géigesäiteg aus: béid opzeruffen gëtt eng Ausnam. Souwisou gëtt d'Lëscht pro Benotzer beim Ariichte vun der Interface ugewannt, dofir gëtt eng App aus dem Aarbechtsprofil vum Tunnel vum Aarbechtsprofil regéiert an net vun Ärem. Wat keng API gëtt, ass Kontroll iwwer d'Entscheedung vun enger anerer App: Dir kënnt e Paket net vun dobaussen an Ären Tunnel drécken, an Dir kënnt eng VPN déi schonn aktiv ass net zoumaachen oder ëmkonfiguréieren.

DNS follegt dem selwechte Muster. addDnsServer annoncéiert eng Resolver-Adress; et erlaabt Ärer App net, Ufroen ze beäntweren. Wann Dir Nimm selwer opléise wëllt, loosst en Resolver lafen an routeet seng Adress an den Tunnel. Apps déi DoT oder DoH op en fixen Hostnumm benotzen, kënnen d'Adress déi Dir annoncéiert hutt ëmgoen, dofir behandelt d'Numm-Opléisung als bescht Beméiung, ausser Dir fänkt och de Wee vun der Ufro of.

Manifest, always-on an den Test an véier Schrëtt

D'Eligibilitéit gëtt am Manifest deklaréiert: BIND_VPN_SERVICE, den Intent-Filter android.net.VpnService an en Hannergrond-Service, wann den Tunnel am Hannergrond muss iwwerliewe. Always-on VPN verlaangt zousätzlech en proppere onRevoke, well de System en oprufft wann de Benotzer Astellungen ännert oder eng aner App d'Kontroll iwwerhëlt.

Maacht d'Kontrollen an der Rei a stoppt beim éischte Feeler. Éischtens, gitt d'Adress-, Routen- an DNS-Lëschten aus, déi dem Builder ginn goufen. Zweetens, bestätegt datt establish() en Deskriptor zréckginn huet an de Transportsocket protegéiert ass. Drëttens, frot eng Zil bannent engem abegraffene Präfix an eng bannent engem ausgeschlossene Präfix un. Véiertens, préift wéi en Resolver wierklech geäntwert huet, andeem Dir en Hostnumm frot, deen nëmmen Äre Resolver opléise kann.

En ofgeschlossenen Handshake beweist keen vun de spéidere Schrëtt. All Kontroll isoléiert eng Schicht, dofir seet en Erfolleg am zweete Schrëtt näischt iwwer de véierten.

D'VpnService.Builder-Referenz listet déi ganz Uewerfläch vum Builder. Alles wat Dir doriwwer eraus braucht, ass eng aner API, eng aner App oder Ären eegene Benotzerraum-Stack, an dat ass eng Design-Entscheedung an net e Split-Tunnel-Fehler.