Android-VPN sen root: kiu posedas konsenton, vojojn kaj blokadon
Konsento, la TUN-interfaco kaj la blokada politiko de la sistemo estas tri malsamaj permesoj. Spuru, kiun komponanton posedas ĉiu el ili, antaŭ ol revizii Android-VPN-aplikaĵon.
Root ne estas tio, kio ebligas al Android-VPN-aplikaĵo porti trafikon, bloki likojn aŭ postvivi restarigon. Homoj resumas ĉion ĉi kiel „la aplikaĵo havas VPN-permeson“, kio kaŝas tri apartajn mekanismojn: konsenton donitan de la uzanto, paketan interfacon, kiun la sistemo starigas, kaj blokadan politikon de la platformo, kiun ne la aplikaĵo difinas. Revizii Android-VPN-dezajnon signifas demandi, sur kiu el la tri aserto efektive apogiĝas, ĉar ĉiu havas alian posedanton kaj alian fiaskmanieron.
Konsento alvenas per sistema agado
VpnService.prepare() donas nenion. Ĝi redonas intenton al la sistema konsenta agado kiam mankas konsento, kaj la aplikaĵo lanĉas tiun dialogon por ke la uzanto aprobu la servon. Lanĉi la propran procezon de la aplikaĵo, aldoni permeson al la manifestaĵo aŭ montri propran ekranon „ŝalti VPN“ ne kreas la permeson.
La permeso ankaŭ estas limigita. Ĝi apartenas al pako en uzantprofilo, do la persona kopio kaj la labora kopio estas apartaj decidoj, kaj posedanto de aparato povas prepari administritan profilon alie ol personan. Se la dialogo neniam aperas kaj prepare() redonas null, konsento jam ekzistas por tiu pako en tiu profilo; tio ne pruvas, ke la aplikaĵo estas fidinda, nur ke la permeso ekzistas.
La interfaco estas peto, kiun la sistemo plenumas
Post konsento, la aplikaĵo priskribas, kion ĝi volas per VpnService.Builder: adresoj, vojoj, DNS-serviloj, MTU kaj, kie subtenate, la aplikaĵoj enmetotaj aŭ ekskludotaj. establish() petas al la sistemo krei la tunelan interfacon kaj enigi la konforman trafikon en ĝin. La sistemo posedas la enkursigan decidon; la aplikaĵo ricevas la dosierpriskribilon kaj poste devas fari ion utilan kun la pakaĵoj.
| 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 |
Tiu tabelo estas la arkitekturo en unu loko. La aplikaĵo partoprenas en pakaĵa traktado; ĝi ne posedas la interfacon, la enkursigan tabelon aŭ la nombron de servoj, kiuj rajtas funkcii.
La tunela ingo devas eskapi el sia propra tunelo
La konekto, kiu portas la ĉifritan trafikon, mem estas ingo. Se ĝi estas enkursigita reen en la interfacon, kiun la aplikaĵo ĵus kreis, la tunelo dependas de la tunelo kaj haltas. VpnService.protect() ligas tiun ingon al la suba reto por ke ĝi preterpasu la kaptadon, kaj tial ĝusta kliento protektas sian eksteran ingon antaŭ la unua manpremo.
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_lockdownTiuj komandoj montras la instalitan VPN-reton, la pakon de ĉiam-ŝalta kaj ĉu la ŝloso estas agordita. Ili estas nur-legeblaj observoj: se la valoroj ne kongruas kun tio, kion la dezajno asertas, la aserto koncernas la interfacon de la aplikaĵo, ne la staton de la sistemo.
Blokado povas aparteni al la platformo
Android dokumentas politikon, kiu blokas konektojn ne uzantajn la VPN. Tiu plenumado estas platforma kontrakto, ne aplikaĵo, kiu en buklo ripetas konektprovojn. La ŝaltilo troviĝas en la VPN-agordoj de la aparato kiel Bloki konektojn sen VPN, kaj sur administrita aparato la posedanto povas ŝalti ĝin por la tuta profilo. La distingo gravas, kiam vi taksas merkatan aserton: kliento povas montri ŝlosilan ikonon kaj agreseme rekonekti dum rekta trafiko ankoraŭ eblas, aŭ kovritaj aplikaĵoj povas resti eksterrete ĉar la sistemo plenumas la ŝlosadon.
La ŝlosilan ikonon desegnas la aplikaĵo, do ĝi pruvas nur, ke la aplikaĵo kredas esti konektita. Ĉu alia aplikaĵo perdas sian retaliron decidas la platformo, do la utila kontrolo estas vidi tiun aplikaĵon fiaski dum la tunelo funkcias.
Ankaŭ la etikedo „ĉiam ŝaltita“ el la aplikaĵejo ne anstataŭas tiun kontrakton. Ĉiam-ŝalta kaj ŝlosado estas aparataj agordoj, ofte aplikataj de aparata posedanto, kaj ilian konduton por ekskluditaj aplikaĵoj difinas la platformo. Legu la agordon, ne la insignon.
Kvar demandoj por dezajna revizio
Unue, kiu konsentis: kiu pako, kiu profilo, kaj ĉu ĝi estis la uzanto aŭ administrita-aparata politiko? Due, kion la aplikaĵo petis: kiujn vojojn, kiujn adresfamiliojn, kiujn enmetitajn aŭ ekskluditajn aplikaĵojn? Trie, kio okazas kiam la tunelo ne disponeblas: ĉu la sistemo blokas, aŭ ĉu trafiko refalas al la suba reto? Kvare, kion la aplikaĵo faras kun la pakaĵoj, kiujn ĝi ricevas?
La kvara demando estas tiu, kiun la permesa modelo ne povas respondi. Konsento kaj TUN-interfaco pruvas, ke la aplikaĵo povas ricevi trafikon, ne ke ĝi ĉifras ĝin, aŭtentigas samtavolanon aŭ resaniĝas pure. Tiuj estas efektivigaj ecoj, kaj tie honesta revizio pasigas sian tempon.
Nenecesa root-peto ne fariĝas legitima per nomado de la rezulto mortigilo, kaj konsenta dialogo ne estas sekureca revizio. Tenu la tri permesojn aparte kaj ĉiu aserto fariĝas kontrolebla.