VPN Android heb root: pwy sy'n berchen ar ganiatâd, llwybrau a blocio

Nid root yw'r peth sy'n caniatáu i ap VPN Android gario traffig, blocio gollyngiadau neu oroesi ailgychwyn. Mae pobl yn crynhoi hyn i gyd fel „mae gan yr ap ganiatâd VPN“, sy'n cuddio tri mecanwaith ar wahân: grant caniatâd gan ddefnyddiwr, rhyngwyneb pecynnau mae'r system yn ei sefydlu, a pholisi blocio'r platfform nad yw'n perthyn i'r ap ei ddiffinio. Mae adolygu dyluniad VPN Android yn golygu gofyn ar ba un o'r tri y mae honiad yn gorffwys mewn gwirionedd, oherwydd mae gan bob un berchennog gwahanol a dull methiant gwahanol.

Daw caniatâd trwy weithgaredd system

VpnService.prepare() nid yw'n rhoi unrhyw beth. Mae'n dychwelyd intent i'r gweithgaredd caniatâd system pan fo caniatâd ar goll, ac mae'r ap yn lansio'r deialog hwnnw fel y gall y defnyddiwr gymeradwyo'r gwasanaeth. Nid yw cychwyn proses yr ap ei hun, ychwanegu caniatâd at y maniffest, na dangos sgrin „galluogi VPN“ addasedig yn creu'r grant.

Mae'r grant hefyd wedi'i gwmpasu. Mae'n perthyn i becyn mewn proffil defnyddiwr, felly mae'r copi personol a'r copi gwaith yn benderfyniadau ar wahân, a gall perchennog dyfais baratoi proffil rheoledig yn wahanol i un personol. Os na fydd y deialog byth yn ymddangos ac mae prepare() yn dychwelyd null, mae caniatâd eisoes yn bodoli ar gyfer y pecyn hwnnw yn y proffil hwnnw; nid yw'n dystiolaeth bod yr ap yn ddibynadwy, dim ond bod y grant yn ei le.

Mae'r rhyngwyneb yn gais mae'r system yn ei gyflawni

Ar ôl caniatâd, mae'r ap yn disgrifio'r hyn y mae ei eisiau gyda VpnService.Builder: cyfeiriadau, llwybrau, gweinyddwyr DNS, MTU a, lle mae'n cael ei gefnogi, yr apiau i'w cynnwys neu eu heithrio. Mae establish() yn gofyn i'r system greu'r rhyngwyneb tiwnel ac anfon y traffig sy'n cyfateb iddo yno. Y system sy'n berchen ar y penderfyniad llwybro; mae'r ap yn derbyn y disgrifydd ffeil ac yna'n rhaid iddo wneud rhywbeth defnyddiol gyda'r pecynnau.

Mae'r tabl hwnnw'n dangos y bensaernïaeth mewn un man. Mae'r ap yn cymryd rhan mewn trin pecynnau; nid yw'n berchen ar y rhyngwyneb, y tabl llwybro, na nifer y gwasanaethau a gaiff redeg.

Rhaid i soced y tiwnel ddianc o'i diwnel ei hun

Mae'r cysylltiad sy'n cario'r traffig wedi'i amgryptio ei hun yn soced. Os caiff ei lwybro'n ôl i'r rhyngwyneb y mae'r ap newydd ei greu, mae'r tiwnel yn dibynnu ar y tiwnel ac yn stopio. Mae VpnService.protect() yn rhwymo'r soced hwnnw i'r rhwydwaith sylfaenol fel ei fod yn osgoi'r dal, a dyna pam mae cleient cywir yn amddiffyn ei soced allanol cyn yr ysgwyd llaw cyntaf.

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

Mae'r gorchmynion hyn yn dangos y rhwydwaith VPN sydd wedi'i osod, y pecyn bob amser ymlaen ac a yw'r clo wedi'i osod. Arsylwadau darllen yn unig ydyn nhw: os nad yw'r gwerthoedd yn cyfateb i'r hyn y mae'r dyluniad yn ei honni, mae'r honiad yn ymwneud â rhyngwyneb yr ap yn hytrach na chyflwr y system.

Gall blocio berthyn i'r platfform

Mae Android yn dogfennu polisi sy'n blocio cysylltiadau nad ydynt yn defnyddio'r VPN. Mae'r gorfodi hwnnw'n gontract platfform, nid ap yn ceisio cysylltu dro ar ôl tro mewn dolen. Mae'r switsh yn nhestun VPN y ddyfais fel Blocio cysylltiadau heb VPN, ac ar ddyfais reoledig gall perchennog ei droi ymlaen ar gyfer y proffil cyfan. Mae'r gwahaniaeth yn bwysig wrth werthuso honiad marchnata: gall cleient ddangos eicon clo ac ailgysylltu'n ymosodol tra bo traffig uniongyrchol yn dal yn bosibl, neu gall apiau sydd wedi'u cynnwys aros all-lein oherwydd bod y system yn gorfodi'r clo.

Mae'r ap yn tynnu'r eicon clo, felly dim ond profi bod yr ap yn credu ei fod wedi cysylltu y mae'n ei wneud. Y platfform sy'n penderfynu a yw ap arall yn colli mynediad rhwydwaith, felly'r gwiriad defnyddiol yw gwylio'r ap hwnnw'n methu tra bo'r tiwnel ymlaen.

Nid yw label „bob amser ymlaen“ o'r siop apiau yn disodli'r contract hwnnw chwaith. Mae modd bob amser ymlaen a chlo yn osodiadau dyfais, yn aml yn cael eu cymhwyso gan berchennog dyfais, a'r platfform sy'n diffinio eu hymddygiad ar gyfer apiau wedi'u heithrio. Darllenwch yr osodiad, nid y bathodyn.

Pedwar cwestiwn ar gyfer adolygu dyluniad

Yn gyntaf, pwy a roddodd ganiatâd: pa becyn, pa broffil, ac ai'r defnyddiwr neu bolisi dyfais reoledig oedd hi? Yn ail, beth wnaeth yr ap ofyn amdano: pa lwybrau, pa deuluoedd cyfeiriadau, pa apiau wedi'u cynnwys neu eu heithrio? Yn drydydd, beth sy'n digwydd pan nad yw'r tiwnel ar gael: a yw'r system yn blocio, neu a yw traffig yn cwympo'n ôl i'r rhwydwaith sylfaenol? Yn bedwerydd, beth mae'r ap yn ei wneud gyda'r pecynnau a ddaw i mewn?

Y pedwerydd cwestiwn yw'r un na all y model caniatâd ei ateb. Mae caniatâd a rhyngwyneb TUN yn profi y gall yr ap dderbyn traffig, nid ei fod yn ei amgryptio, yn dilysu cymar neu'n gwella'n lân. Priodweddau gweithredu yw'r rhain, a dyna lle mae adolygiad gonest yn treulio'i amser.

Nid yw cais root diangen yn dod yn gyfreithlon trwy alw'r canlyniad yn switsh lladd, ac nid yw deialog caniatâd yn archwiliad diogelwch. Cadwch y tri grant ar wahân ac mae pob honiad yn dod yn wirioadwy.