Split tunneling yn Android VpnService: wat jo echt routearje kinne

Split tunneling yn in VpnService-app bruts op in pear konkrete plakken, en de reparaasje ferskilt per plak. De klient lit mar ien bestimming sjen dy't mislearret, dus de earste taak is útfine hokker grins jo reitsje: de rûtes dy't de builder krige, de proxy dy't jo net autentisearje kinne, de resolver dy't jo allinnich oankundige hawwe, of de applikaasjelist dy't it platfoarm per brûker tapast. Dêrom hâld ik in kontrôle yn fjouwer stappen. Dy rint yn 'e folchoarder hjirûnder en stoppet by de earste flater.

Kontrolearje wat de builder oan it platfoarm joech

VpnService.Builder is in list fan ferklearrings. establish() jout in ParcelFileDescriptor foar in firtuele ynterface werom, en it platfoarm stjoert allinnich ferkear dat by de prefiksen fan addAddress en addRoute past nei dy descriptor; addDnsServer fertelt kliïnten hokker resolver se freegje moatte. In bestimming bûten alle prefiksen dy't jo tafoege hawwe berikt nea jo app, wat de ynterface ek belooft. Dat iene feit ferklearret de measte rapporten oer brutsen split tunneling al foardat der koadeferoarring is.

Log de adres-, rûte- en DNS-listen dy't jo builder gearstalde, en fergelykje se mei de bestimmingen dy't mislearje. In ûntbrekkende /32 foar in behearhost komt folle faker foar as in brutsen tunnel. Is de list goed, gean dan troch; is er ferkeard, dan is de rest fan 'e kontrolelist ferspilde muoite.

excludeRoute bestiet pas fan API 33 ôf

Utsluting op bestimming is de oanfraach dy't it meast yn in stipe-tried einiget. builder.excludeRoute(IpPrefix) kaam yn API 33; dêrfoar is de iennichste stipe beneaderung rûtes tafoegje foar alles behalve it útsletten prefiks, wat betsjut dat jo de komplementêre prefiksen sels berekkenje moatte. De twa oproppen binne gjin spegelbylden: ien lûkt ôf fan 'e rûteset fan 'e ynterface, de oare bout de set fan nul ôf, en in âlder apparaat sil in oprop dy't it net ken smite of stilwei negearje. Fertakje op Build.VERSION.SDK_INT en test beide paden op echte hardware.

As jo komplementen berekkenje, let dan op 'e prefiksôflining. In /24-útsluting binnen in /16-rûte hat de dekjende prefiksen nedich dy't it oerbliuwende part echt beskriuwe, net ien ferkeard /8. Log de definitive list en kontrolearje dat de útsletten host noch altyd fia in paad bûten de tunnel oplost.

Proxy-ynloggegevens kinne net útdrukt wurde

setHttpProxy(ProxyInfo) rjochtet de ynterface op in HTTP- of SOCKS-proxy, en in PAC-URL kin per bestimming tusken har kieze. Noch ProxyInfo, noch it PAC-formaat draacht in brûkersnamme en wachtwurd, dus in proxy dy't autentikaasje freget bliuwt bûten de API fan it platfoarm. Apps dy't ien nedich hawwe, bouwe meastal in brûkersromtestapel, tun2socks of in ferlykbere motor yn, en beantwurdzje sels de 407-útdaging.

Dy kar hat gefolgen. In brûkersromtestapel sjocht allinnich ferkear dat jo derhinne routearje, dus hy moat binnen deselde descriptorgrins libje, en hy erft deselde protect()-eas foar syn eigen uplink-socket. Lit protect() weil en de tunnel fangt syn eigen transport, wat him sjen lit as in hânskodding dy't nei it earste pakket fêstrint. Test tsjin in proxy dy't ynloggegevens easket, want in iepen proxy slagget op it paad fan it platfoarm en bewissiget neat.

Applikaasjelisten en DNS binne ek ferklearrings

Builder hat sawol addAllowedApplication as addDisallowedApplication, en se slute inoar út: beide oanroppe smyt in útsûndering. Hoe dan ek, de list wurdt by it ynstellen fan 'e ynterface per brûker tapast, dus in app fan in wurkprofyl wurdt regele troch de tunnel fan it wurkprofyl en net troch dy fan jo. Wat gjin inkelde API jout, is kontrôle oer it beslút fan in oare app: jo kinne in pakket net fan bûten yn jo tunnel triuwe, en jo kinne in al aktive VPN net slute of werkonfigurearje.

DNS folget itselde patroan. addDnsServer kundiget in resolveradres oan; it lit jo app net antwurdzje op fragen. Wolle jo nammen sels oplosse, rin dan in resolver en routearje syn adres de tunnel yn. Apps dy't DoT of DoH nei in fêste hostnamme brûke, kinne it adres dat jo oankundige hawwe omgean, behannelje namme-oplossing dus as bêste besykjen, útsein as jo ek it fraachpaad ûnderskeppe.

Manifest, always-on en de test yn fjouwer stappen

Geskkiktheid wurdt yn it manifest ferklearre: BIND_VPN_SERVICE, it android.net.VpnService-intentfilter en in foargrûntsjinst as de tunnel efter de skermen oerlibje moat. Always-on VPN freget boppedat in skjinne onRevoke, want it systeem ropt dy oan as de brûker ynstellingen feroaret of in oare app de kontrôle oernimt.

Fier de kontrôles yn folchoarder út en stop by de earste flater. Earst: printsje de adres-, rûte- en DNS-listen dy't oan 'e builder jûn binne. Twadde: befêstigje dat establish() in descriptor weromjoech en dat de transportsocket beskerme is. Tredde: freegje ien bestimming binnen in opnommen prefiks en ien binnen in útsletten prefiks. Fjirde: kontrolearje hokker resolver echt antwurde troch in hostnamme te freegjen dy't allinnich jo resolver oplosse kin.

In foltôge hânskodding bewissiget gjin inkelde fan 'e lettere stappen. Eltse kontrôle isolearret ien laach, dus in sukses by stap twa seit neat oer stap fjouwer.

De VpnService.Builder-referinsje listet it folsleine oerflak fan 'e builder op. Alles wat jo dêrbûten nedich hawwe is in oare API, in oare app of jo eigen brûkersromtestapel, en dat is in ûntwerpbeslút, gjin split-tunnel-flater.