Android VPN án root: hver á samþykki, leiðir og lokanir
Samþykki, TUN-viðmótið og lokunarstefna kerfisins eru þrjú mismunandi leyfi. Greindu hvaða hluti á hvert þeirra áður en þú ferir yfir Android VPN-forrit.
Root er ekki það sem gerir Android VPN-forriti kleift að bera umferð, loka leka eða lifa endurræsingu af. Fólk dregur þetta allt saman sem „forritið hefur VPN-leyfi“, sem felur þrjár aðskildar aðferðir: samþykki frá notanda, pakkaviðmót sem kerfið setur upp og lokunarstefnu vettvangsins sem forritið á ekki að skilgreina. Að fara yfir Android VPN-hönnun þýðir að spyrja hverri af þremur fullyrðing raunverulega byggist á, því hver hefur annan eiganda og annan bilunarhátt.
Samþykki kemur í gegnum kerfisaðgerð
VpnService.prepare() veitir ekkert. Það skilar intent til samþykkisaðgerðar kerfisins þegar samþykki vantar, og forritið opnar þann glugga svo notandinn geti samþykkt þjónustuna. Að ræsa eigið ferli forritsins, bæta leyfi í manifestið eða sýna sérsniðinn skjá „virkja VPN“ býr ekki til leyfið.
Leyfið er líka afmarkað. Það tilheyrir pakka í notandaprófíli, svo einkaeintakið og vinnueintakið eru aðskildar ákvarðanir, og eigandi tækis getur undirbúið stýrt prófíl öðruvísi en einkaprófíl. Ef glugginn birtist aldrei og prepare() skilar null, er samþykki þegar til fyrir þann pakka í þeim prófíl; það er ekki sönnun þess að forritið sé áreiðanlegt, aðeins að leyfið sé til staðar.
Viðmótið er beiðni sem kerfið uppfyllir
Eftir samþykki lýsir forritið því sem það vill með VpnService.Builder: vistföngum, leiðum, DNS-þjónum, MTU og þar sem stuðningur er, forritunum sem á að hafa með eða undanskilja. establish() biður kerfið að búa til gönguviðmótið og beina samsvarandi umferð inn í það. Kerfið á leiðarákvörðunina; forritið fær skráarlysingu og verður þá að gera eitthvað gagnlegt við pakkana.
| 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 |
Þessi tafla er arkitektúrinn á einum stað. Forritið tekur þátt í meðferð pakka; það á ekki viðmótið, leiðartöfluna eða fjölda þjónustna sem mega keyra.
Gangasokkurinn verður að komast út úr eigin göngum
Tengingin sem ber dulkóðaða umferð er sjálf sokkur. Ef henni er beint aftur í viðmótið sem forritið var að búa til, fer gangurinn að hanga á ganginum og stöðvast. VpnService.protect() bindur þann sokki við undirliggjandi netið svo hann fari fram hjá handtökunni, og þess vegna verndar réttur biðlari ytri sokk sinn fyrir fyrsta handabandi.
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_lockdownÞessar skipanir sýna uppsetta VPN-net, pakkann fyrir alltaf-á og hvort læsingin er stillt. Þetta eru aðeins lestrargreind: ef gildin passa ekki við það sem hönnunin fullyrðir, er fullyrðingin um viðmót forritsins en ekki ástand kerfisins.
Lokun getur verið vettvangsins
Android skjalfestir stefnu sem lokar á tengingar sem nota ekki VPN. Sú framfylgd er samningur vettvangsins, ekki forrit sem endurtekur tengingartilraunir í lykkju. Rofinn er í VPN-stillingum tækisins sem Loka tengingum án VPN, og á stýrðu tæki getur eigandi kveikt á honum fyrir allt prófílið. Mismunurinn skiptir máli þegar þú metur markaðsfullrðingu: biðlari getur sýnt læsistákn og endurtengst af krafti á meðan bein umferð er enn möguleg, eða þakin forrit geta verið án nettengingar vegna þess að kerfið framfylgir læsingunni.
Forritið teiknar læsistáknið, svo það sannar aðeins að forritið telji sig tengt. Hvort annað forrit missir nettenginguna ræður vettvangurinn, svo gagnleg prófun er að sjá það forrit mistakast meðan gangurinn er opinn.
Merkið „alltaf á“ frá forritabúðinni kemur heldur ekki í stað þess samnings. Alltaf-á og læsing eru tækisstillingar, oft settar af eiganda tækis, og hegðun þeirra fyrir undanskilin forrit er skilgreind af vettvanginum. Lestu stillinguna, ekki merkið.
Fjórar spurningar fyrir hönnunarferil
Fyrst, hver samþykkti: hvaða pakki, hvaða prófíll, og var það notandinn eða stefna stýrðs tækis? Annað, hvað bað forritið um: hvaða leiðir, hvaða vistfangafjölskyldur, hvaða forrit með eða undanskilin? Þriðja, hvað gerist þegar gangurinn er ekki tiltækur: lokar kerfið eða fellur umferðin aftur á undirliggjandi netið? Fjórða, hvað gerir forritið við pakkana sem það tekur við?
Fjórða spurningin er sú sem leyfislíkanið getur ekki svarað. Samþykki og TUN-viðmót sanna að forritið geti tekið við umferð, ekki að það dulkóði hana, auðkenni mótaðila eða jafni sig hreint. Þetta eru eiginleikar útfærslunnar og þar eyðir heiðarleg yfirferð tíma sínum.
Óþarfri root-beiðni verður ekki lögmæt með því að kalla niðurstöðuna neyðarrof, og samþykkisglugginn er ekki öryggisúttekt. Haltu leyfunum þremur aðskildum og hver fullyrðing verður prófanleg.