Android-VPN sûnder root: wa besit tastimming, rûtes en blokkearring
Tastimming, de TUN-interface en it blokkearbelied fan it systeem binne trije ferskillende tastimmingen. Folgje hokker komponint elk besit foardat jo in Android-VPN-app beoardielje.
Root is net wat in Android-VPN-app yn steat stelt om ferkear te dragen, lekken te blokkearjen of in werstart te oerlibjen. Minsken fetsje dat allegear gear as „de app hat VPN-tastimming“, wat trije aparte meganismen ferberget: in tastimming fan de brûker, in pakketinterface dy't it systeem oanmakket, en in blokkearbelied fan it platform dat net fan de app is om te bepalen. In Android-VPN-ûntwerp beoardielje betsjut freegje op hokker fan de trije in bewearing echt rêstet, want elk hat in oare eigner en in oare flatermodus.
Tastimming komt troch in systeemaktiviteit
VpnService.prepare() jout neat. It jout in intent werom nei de systeemtastimmingsaktiviteit as tastimming ûntbrekt, en de app start dy dialooch sadat de brûker de tsjinst goedkrije kin. It eigen proses fan 'e app starte, in tastimming oan it manifest taheakje of in oanpast skerm „VPN ynskeakelje“ sjen litte makket de tastimming net.
De tastimming is ek beheind. It heart by in pakket yn in brûkersprofyl, dus de persoanlike kopy en de wurkkopy binne aparte besluten, en in apparaateigner kin in beheard profyl oars taret as in persoanlik ien. As de dialooch nea ferskynt en prepare() jout null werom, bestiet tastimming al foar dat pakket yn dat profyl; dat is gjin bewiis dat de app betrouber is, allinnich dat de tastimming der is.
De interface is in fersyk dat it systeem ferfollet
Nei tastimming beskriuwt de app wat er wol mei VpnService.Builder: adressen, rûtes, DNS-tsjinners, MTU en, wêr't stipe, de apps om op te nimmen of út te sluten. establish() freget it systeem om de tunnelinterface te meitsjen en it oerienkommende ferkear dêrhinne te lieden. It systeem besit de routedecision; de app krijt de triemdeskriptor en moat dan wat nuttichs dwaan mei de pakketten.
| 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 |
Dy tabel is de arsjitektuer op ien plak. De app docht mei oan pakketferwurking; se besit de interface, de routetabel of it oantal tsjinsten dat rinne mei net.
De tunnelsocket moat út syn eigen tunnel ûntkomme
De ferbining dy't it fersifere ferkear draacht is sels in socket. As dy werom liedt nei de interface dy't de app krekt makke hat, hinget de tunnel fan de tunnel ôf en stûket. VpnService.protect() bynt dy socket oan it ûnderlizzende netwurk sadat it de opfangst omgiet, en dêrom beskermet in korrekte klient syn bûtenste socket foar de earste hânskobbe.
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_lockdownDizze opdrachten litte it ynstalleare VPN-netwurk sjen, it pakket foar altyd-oan en oft de beskoatteling ynsteld is. It binne lês-inkeld-waarnimmings: as de wearden net oerienkomme mei wat it ûntwerp beweart, giet de bewearing oer de interface fan de app en net oer de tastân fan it systeem.
Blokkearring kin fan it platform wêze
Android dokumintearret in belied dat ferbiningen blokkearret dy't de VPN net brûke. Dy hanthavening is in platformkontrakt, net in app dy't ferbiningen yn in lus op 'e nij besiket. De skeakel sit yn 'e VPN-ynstellingen fan it apparaat as Blokkearje ferbiningen sûnder VPN, en op in beheard apparaat kin in eigner it foar it hiele profyl oansette. It ûnderskied is wichtich by it beoardieljen fan in marketingbewearing: in klient kin in slotikoan sjen litte en agressyf wer ferbine wylst direkte ferkear noch mooglik is, of oerdekte apps kinne offline bliuwe om't it systeem de beskoatteling hanthavent.
It slotikoan wurdt troch de app tekene, dus it bewiist allinnich dat de app tinkt dat er ferbûn is. Oft in oare app syn netwurktagong ferliest wurdt troch it platform besletten, dus de nuttige kontrôle is om dy app te sjen mislearjen wylst de tunnel oan is.
In „altyd oan“-label fan 'e appwinkel ferfangt dat kontrakt ek net. Altyd-oan en beskoatteling binne apparaatynstellingen, faak tapast troch in eigner, en har gedrach foar útsletten apps wurdt troch it platform bepaald. Lês de ynstelling, net it badge.
Fjouwer fragen foar in ûntwerpbewurking
Earst, wa joech tastimming: hokker pakket, hokker profyl, en wie it de brûker of in beheard-apparaatbelied? Twadde, wat frege de app: hokker rûtes, hokker adresfamyljes, hokker opnommen of útsletten apps? Tredde, wat bart der as de tunnel net beskikber is: blokkearret it systeem, of falt it ferkear werom op it ûnderlizzende netwurk? Fjouwerde, wat docht de app mei de pakketten dy't er ûntfangt?
De fjouwerde fraach is dy't it tastimmingsmodel net beantwurdzje kin. Tastimming en in TUN-interface bewize dat de app ferkear ûntfange kin, net dat it dat fersiferet, in pear autentisearret of him skjin herstelt. Dat binne ymplemintaasje-eigenskippen, en dêr't in earlike beoardieling syn tiid trochbringt.
In ûnnedige root-fersyk wurdt net legitym troch it resultaat in kill switch te neamen, en in tastimmingsdialooch is gjin feiligensaudit. Hâld de trije tastimmingen apart en elke bewearing wurdt kontrolearber.