Android-VPN sonder root: wie besit toestemming, roetes en blokkering
Toestemming, die TUN-koppelvlak en die stelsel se blokkeringsbeleid is drie verskillende toestemmings. Spoor na watter komponent elkeen besit voordat jy 'n Android-VPN-app hersien.
Root is nie wat 'n Android-VPN-app in staat stel om verkeer te dra, lekkasies te blokkeer of 'n herlaai te oorleef nie. Mense som dit alles op as “die app het VPN-toestemming”, wat drie afsonderlike meganismes verberg: 'n gebruikerstoestemming, 'n pakketkoppelvlak wat die stelsel skep, en 'n platformblokkeringsbeleid wat nie die app s'n is om te bepaal nie. Om 'n Android-VPN-ontwerp te hersien beteken om te vra op watter van die drie 'n bewering werklik rus, want elkeen het 'n ander eienaar en 'n ander foutmodus.
Toestemming kom deur 'n stelselaktiwiteit
VpnService.prepare() gee niks. Dit gee 'n intent aan die stelsel se toestemmingsaktiwiteit wanneer toestemming ontbreek, en die app begin daardie dialoog sodat die gebruiker die diens kan goedkeur. Om die app se eie proses te begin, 'n toestemming by die manifest te voeg, of 'n pasgemaakte “aktiveer VPN”-skerm te wys, skep nie die toestemming nie.
Die toestemming is ook beperk. Dit behoort aan 'n pakket in 'n gebruikerprofiel, so die persoonlike kopie en die werkkopie is afsonderlike besluite, en 'n toestel-eienaar kan 'n bestuurde profiel anders voorberei as 'n persoonlike een. As die dialoog nooit verskyn nie en prepare() gee null, bestaan toestemming reeds vir daardie pakket in daardie profiel; dit is nie bewys dat die app betroubaar is nie, net dat die toestemming in plek is.
Die koppelvlak is 'n versoek wat die stelsel vervul
Na toestemming beskryf die app wat hy wil hê met VpnService.Builder: adresse, roetes, DNS-bediener, MTU en, waar ondersteun, die toepassings om in te sluit of uit te sluit. establish() vra die stelsel om die tonnelkoppelvlak te skep en die ooreenstemmende verkeer daarin te lei. Die stelsel besit die roetebesluit; die app ontvang die lêerbeskrywer en moet dan iets nuttigs met die pakkette doen.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
Daardie tabel is die argitektuur op een plek. Die app neem deel aan pakketverwerking; dit besit nie die koppelvlak, die roetetabel of die aantal dienste wat mag loop nie.
Die tonnelsok moet uit sy eie tonnel ontsnap
Die verbinding wat die versleutelde verkeer dra, is self 'n sok. As dit teruggelei word in die koppelvlak wat die app pas geskep het, hang die tonnel van die tonnel af en staak. VpnService.protect() bind daardie sok aan die onderliggende netwerk sodat dit die opvang omseil, en daarom beskerm 'n korrekte kliënt sy buitenste sok voor die eerste handdruk.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownHierdie opdragte wys die geïnstalleerde VPN-netwerk, die altijd-aan-pakket en of toesluiting ingestel is. Hulle is lees-alleen-waarnemings: as die waardes nie ooreenstem met wat die ontwerp beweer nie, gaan die bewering oor die app se koppelvlak eerder as die stelsel se toestand.
Blokkering kan aan die platform behoort
Android dokumenteer 'n beleid wat verbindings blokkeer wat nie die VPN gebruik nie. Daardie handhawing is 'n platformkontrak, nie 'n app wat verbindings in 'n lus herprobeer nie. Die skakelaar sit in die toestel se VPN-instellings as Blokkeer verbindings sonder VPN, en op 'n bestuurde toestel kan 'n toestel-eienaar dit vir die hele profiel aanskakel. Die onderskeid is belangrik wanneer jy 'n bemarkingsbewering evalueer: 'n kliënt kan 'n slotikoon wys en aggressief herverbind terwyl direkte verkeer steeds moontlik is, of gedekte toepassings kan vanlyn bly omdat die stelsel toesluiting handhaaf.
'n Slotikoon word deur die app geteken, so dit bewys net dat die app glo hy is verbind. Of 'n ander app sy netwerktoegang verloor, word deur die platform besluit, so die nuttige kontrole is om daardie app te sien misluk terwyl die tonnel op is.
'n App-winkel se “altyd aan”-etiket vervang ook nie daardie kontrak nie. Altyd-aan en toesluiting is toestelinstellings, dikwels deur 'n toestel-eienaar toegepas, en hul gedrag vir uitgeslote apps word deur die platform bepaal. Lees die instelling, nie die kenteken nie.
Vier vrae vir 'n ontwerphersiening
Eerstens, wie het ingestem: watter pakket, watter profiel, en was dit die gebruiker of 'n bestuurde-toestelbeleid? Tweedens, wat het die app versoek: watter roetes, watter families, watter ingeslote of uitgeslote apps? Derdens, wat gebeur wanneer die tonnel onbeskikbaar is: blokkeer die stelsel, of val verkeer terug na die onderliggende netwerk? Vierdens, wat doen die app met die pakkette wat hy ontvang?
Die vierde vraag is die een wat die toestemmingsmodel nie kan antwoord nie. Toestemming en 'n TUN-koppelvlak bewys dat die app verkeer kan ontvang, nie dat dit dit versleutel, 'n eweknie authentiseer of skoon herstel nie. Dit is implementeringseienskappe, en dit is waar 'n eerlike hersiening sy tyd spandeer.
'n Onnodige root-versoek word nie wettig deur die resultaat 'n doodskakelaar te noem nie, en 'n toestemmingsdialoog is nie 'n sekuriteitsoudit nie. Hou die drie toestemmings apart en elke bewering word nagegaanbaar.