Split tunneling en Android VpnService: kion vi vere povas enkursigi

Split tunneling en aplikaĵo VpnService rompiĝas en kelkaj konkretaj lokoj, kaj la riparo malsamas por ĉiu. La kliento montras nur unu celon, kiu malsukcesas, do la unua tasko estas trovi, kiun limon vi trafas: la itinerojn, kiujn la builder ricevis, la proksilon, kiun vi ne povas aŭtentikigi, la solvilon, kiun vi nur anoncis, aŭ la aplikaĵan liston, kiun la platformo aplikas po uzanto. Ĝuste tial mi tenas kontrolon en kvar paŝoj. Ĝi iras laŭ la ordo sube kaj haltas ĉe la unua malsukceso.

Konfirmu, kion la builder donis al la platformo

VpnService.Builder estas listo de deklaroj. establish() redonas ParcelFileDescriptor por virtuala interfaco, kaj la platformo sendas en tiun priskribilon nur trafikon kongruan al la prefiksoj de addAddress kaj addRoute; addDnsServer diras al klientoj, kiun solvilon ili demandu. Celo ekster ĉiu prefikso, kiun vi aldonis, neniam atingas vian aplikaĵon, kion ajn la interfaco promesas. Tiu unu fakto klarigas la plejmulton de raportoj pri rompita split tunneling antaŭ ajna koda ŝanĝo.

Protokolu la listojn de adresoj, itineroj kaj DNS, kiujn via builder kunmetis, kaj komparu ilin kun la celoj, kiuj malsukcesas. Mankanta /32 por administra gastiganto estas multe pli ofta ol rompita tunelo. Se la listo ĝustas, daŭrigu; se ĝi malĝustas, la resto de la kontrolo estas vana peno.

excludeRoute ekzistas nur de API 33

Celbazita ekskludo estas la peto, kiu plej ofte fariĝas subtena fadeno. builder.excludeRoute(IpPrefix) alvenis en API 33; antaŭe la sola subtenata proksimumo estas aldoni itinerojn por ĉio krom la ekskludita prefikso, kio signifas mem kalkuli la komplementajn prefiksojn. La du vokoj ne estas spegulbildoj: unu subtrahas de la itineraro de la interfaco, la alia konstruas la aron de nulo, kaj pli malnova aparato ĵetos aŭ silente ignoros vokon, kiun ĝi ne konas. Branĉu laŭ Build.VERSION.SDK_INT kaj testu ambaŭ vojojn sur reala aparataro.

Kiam vi kalkulas komplementojn, atentu prefiksan ĝisrandigon. Ekskludo /24 ene de itinero /16 bezonas la kovrantajn prefiksojn, kiuj vere priskribas la restaĵon, ne unu misformitan /8. Protokolu la finan liston kaj certiĝu, ke la ekskludita gastiganto ankoraŭ solviĝas per vojo ekster la tunelo.

Proksilaj akreditaĵoj ne esprimeblas

setHttpProxy(ProxyInfo) direktas la interfacon al HTTP aŭ SOCKS proksilo, kaj PAC URL povas elekti inter ili po celo. Nek ProxyInfo nek la PAC-formato portas uzantnomon kaj pasvorton, do aŭtentikigita proksilo restas ekster la platforma API. Aplikaĵoj, kiuj bezonas unu, kutime enkorpigas uzantspacan stakon, tun2socks aŭ similan motoron, kaj mem respondas la defion 407.

Tiu elekto havas sekvojn. Uzantspaca stako vidas nur trafikon, kiun vi direktas al ĝi, do ĝi devas vivi ene de la sama priskribila limo, kaj ĝi heredas la saman postulon pri protect() por sia propra suprenliga ingo. Preterlasu protect() kaj la tunelo kaptas sian propran transporton, kio montriĝas kiel manpremo, kiu haltas post la unua pakaĵo. Testu kontraŭ proksilo, kiu postulas akreditaĵojn, ĉar malfermita proksilo trapasas la platforman vojon kaj pruvas nenion.

Aplikaĵaj listoj kaj DNS ankaŭ estas deklaroj

Builder havas kaj addAllowedApplication kaj addDisallowedApplication, kaj ili reciproke ekskludas: voki ambaŭ ĵetas escepton. Ĉiel ajn la listo aplikiĝas po uzanto ĉe interfaca agordo, do laborprofila aplikaĵo estas regata de la tunelo de la laborprofilo, ne de la via. Kion neniu API donas estas kontrolo super la decido de alia aplikaĵo: vi ne povas puŝi pakaĵon en vian tunelon de ekstere, nek fermi aŭ rekondiĉi VPN-on, kiu jam estas aktiva.

DNS sekvas la saman ŝablonon. addDnsServer anoncas solvilan adreson; ĝi ne permesas al via aplikaĵo respondi demandojn. Se vi volas mem solvi nomojn, rulu solvilon kaj direktu ĝian adreson en la tunelon. Aplikaĵoj, kiuj uzas DoT aŭ DoH al fiksa gastigantnomo, povas preterpasi la adreson, kiun vi anoncis, do traktu nomosolvon kiel plejbonan penon, krom se vi ankaŭ interkaptas la demandan vojon.

Manifesto, always-on kaj la kvarpaŝa testo

Taŭgeco deklariĝas en la manifesto: BIND_VPN_SERVICE, la intenta filtrilo android.net.VpnService kaj fona servo, se la tunelo devas travivi en la fono. Always-on VPN krome postulas puran onRevoke, ĉar la sistemo vokas ĝin, kiam la uzanto ŝanĝas agordojn aŭ alia aplikaĵo prenas kontrolon.

Plenumu la kontrolojn laŭ ordo kaj haltu ĉe la unua malsukceso. Unue, eligu la listojn de adresoj, itineroj kaj DNS donitajn al la builder. Due, konfirmu, ke establish() redonis priskribilon kaj ke la transporta ingo estas protektita. Trie, petu unu celon ene de inkludita prefikso kaj unu ene de ekskludita prefikso. Kvare, kontrolu, kiu solvilo fakte respondis, demandante gastigantnomon, kiun nur via solvilo povas solvi.

Kompletigita manpremo pruvas neniun el la postaj paŝoj. Ĉiu kontrolo izolas unu tavolon, do sukceso ĉe la dua paŝo diras nenion pri la kvara.

La referenco de VpnService.Builder listigas la tutan surfacon de la builder. Ĉio, kion vi bezonas preter ĝi, estas alia API, alia aplikaĵo aŭ via propra uzantspaca stako, kaj tio estas dizajna decido, ne split-tunnela cimo.