Android VPN per app: å utelukke ein app er ikkje å blokkere han

To personar stiller same spørsmål og får svar som ikkje passar saman, fordi dei står på ulike stader. Den eine har systemet sine VPN-innstillingar opne og redigerer ei liste over apper. Den andre skriv VpnService.Builder.addDisallowedApplication() i ein editor. Begge kallar det eit VPN-filter per app. Berre éin av dei eig kontrollen dei skildrar, og ingen av dei blokkerer noko.

Start på skjermen brukaren ser

Opne Innstillingar, finn VPN-oppføringa og sjå på tilkoplinga som faktisk er aktiv. Viss klienten tilbyr ei liste per app, høyrer lista til klienten sin eigen tunnel. Plattformen publiserer ikkje eit generelt API der ein urelatert app kan lese eller endre appvalet til ein annan VPN, så ein andre app kan ikkje reparere lista for brukaren.

Dette er den første greina i gjennomgangen. Viss den installerte VPN-en ikkje har ei slik innstilling, er det ingenting å kode rundt: funksjonen manglar i produktet som eig tunnelen. Viss han har det, er den rette rettinga på den skjermen, gjord av den som kan opne han.

Følg pakken inn i ein tunnel

Når din eigen app byggjer ein tunnel, lagar han eit TUN-grensesnitt og erklærer kva appars trafikk som går inn i det. Medlemskapskalla skjer før grensesnittet vert etablert, og etterpå er regelsettet fast for den økta:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

Desse kalla gjeld berre tunnelen appen din nettopp laga, og ingenting anna. Dei er ikkje ein policy for heile eininga, dei varer ikkje for andre klientar, og dei kan ikkje nå inn i nokon annan sin VPN. Når eit byggjar-kall kastar eit unntak fordi pakken ikkje kan løysast opp, vert grensesnittet aldri etablert, noko som er ein rein feil og ikkje ein stille.

Kvifor utelukkinga såg ut som ei blokkering

Ein utelukka app vert ruta rundt tunnelen din til det underliggjande nettverket. Det er det motsette av å blokkere han: trafikken forlèt framleis eininga, berre utanfor grensesnittet du kontrollerer. Ein app i brannmur-stil gjer det motsette. Han slepp trafikken til appen inn i tunnelen sin og kastar deretter pakkane, eller nektar å senda dei vidare, så grensesnittet er det same og retninga på policyen er snudd.

Arbeidet bak den snuinga er ikkje eit konfigurasjonsflagg. Du les IP-pakkar frå tunnelbeskrivinga, avgjer per flyt og sender dei vidare gjennom ein verna socket eller kastar dei. Alt du ikkje handterer stoppar berre, og difor ser ein halvferdig tunnel ut som eit øydelagt nettverk i staden for eit fungerande filter. Viss målet er blokkering, budsjetter med pakkehandtering, ein forgrunnsteneste og ein skriven policy for trafikk du ikkje kan klassifisere.

Kva som bryt når du byggjer det sjølv

Android tillèt vanlegvis berre éin aktiv VPN om gongen, så filtertunnelen din og ein personvernstunnel konkurrerer om same plassen med mindre produkta støttar kjetting. Alltid på-VPN med blokkering av tilkoplingar endrar feilmodusen på ein måte som tyder noko her: trafikk som ikkje kan kome inn i tunnelen vert kasta i staden for send direkte, som er det eit lekkasjeførebyggjande design vil og det ei feilsøkingsøkt sjeldan ventar.

Pakkesynlegheit er den andre fella. Oppslag av pakkenamnet til ein app kan feile med NameNotFoundException, og på nyare Android-versjonar er settet med pakkar du kan sjå avhengig av spørjingane du har deklarert. Handter unntaket i staden for å anta at kvart namn vert løyst opp, og les lista på nytt når apper vert installerte eller fjerna i staden for å bufre henne for alltid.

Administrerte einingar legg til ein tredje eigar. Ein policy for verksemdsmobilitet kan setje ein VPN per app eller ein alltid på-profil, og ein vanleg app kan ikkje overstyre han. Sjekk om eininga er administrert før du feilsøkjer din eigen kode, for i så fall er lista du prøver å endre kanskje ikkje redigerbar for nokon som held telefonen.

Test det med ein app du kontrollerer

Ikkje test med appen du prøver å filtrere. Bruk ein andre app der du kan observere nettverksåtferda, og sjekk om trafikken går ut gjennom tunnelen din medan målet sin ikkje gjer det. Viss begge blir inne, verkar policyen og målet er utelukka; viss ingen kjem ut, er tunnelen sjølv feil og app-lista er ikkje problemet.

Avgjer deretter kva av tre ting du faktisk byggjer. Ein tunnel per app er byggjar-API-et, med lista som del av profilen din. Ein einingbrannmur er pakkehandtering pluss ein livssyklus du kan forsvare. Å endre nokon annan sin VPN er ikkje ein støtta veg i det heile, og det ærlege svaret der er at innstillinga høyrer til det produktet.