Android VPN bez root: kam pieder piekrišana, maršruti un bloķēšana
Piekrišana, TUN saskarne un sistēmas bloķēšanas politika ir trīs dažādas atļaujas. Noskaidrojiet, kuram komponentam pieder katra no tām, pirms pārskatāt Android VPN lietotni.
Root nav tas, kas ļauj Android VPN lietotnei pārvadāt datplūsmu, bloķēt noplūdes vai pārdzīvot pārstartēšanu. Cilvēki to visu apkopo kā „lietotnei ir VPN atļauja“, kas slēpj trīs atsevišķus mehānismus: lietotāja piekrišanu, sistēmas izveidotu pakešu saskarni un platformas bloķēšanas politiku, ko lietotne nenosaka. Pārskatīt Android VPN dizainu nozīmē jautāt, uz kuru no šiem trim apgalvojums patiešām balstās, jo katram ir cits īpašnieks un cits kļūmes veids.
Piekrišana nāk caur sistēmas aktivitāti
VpnService.prepare() neko nepiešķir. Tas atgriež intent uz sistēmas piekrišanas aktivitāti, ja piekrišanas nav, un lietotne atver šo dialogu, lai lietotājs apstiprinātu pakalpojumu. Pašas lietotnes procesa palaišana, atļaujas pievienošana manifestam vai pielāgota ekrāna „iespējot VPN“ rādīšana neveido atļauju.
Atļaujai ir arī tvērums. Tā pieder pakotnei lietotāja profilā, tāpēc personīgā kopija un darba kopija ir atsevišķi lēmumi, un ierīces īpašnieks var pārvaldīto profilu sagatavot citādi nekā personīgo. Ja dialogs nekad neparādās un prepare() atgriež null, piekrišana šai pakotnei šajā profilā jau pastāv; tas nav pierādījums, ka lietotne ir uzticama, tikai tas, ka atļauja ir vietā.
Saskarne ir pieprasījums, ko sistēma izpilda
Pēc piekrišanas lietotne apraksta, ko tā vēlas, ar VpnService.Builder: adreses, maršrutus, DNS serverus, MTU un, kur atbalstīts, lietotnes, kas jāiekļauj vai jāizslēdz. establish() lūdz sistēmu izveidot tuneļa saskarni un novirzīt tajā atbilstošo datplūsmu. Sistēma pārvalda maršrutēšanas lēmumu; lietotne saņem faila deskriptoru un pēc tam tai ar paketēm jādara kaut kas lietderīgs.
| 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 |
Šī tabula ir arhitektūra vienā vietā. Lietotne piedalās pakešu apstrādē; tai nepieder saskarne, maršrutēšanas tabula vai pakalpojumu skaits, kurus drīkst palaist.
Tuneļa socketam jāizbēg no sava tuneļa
Savienojums, kas pārvadā šifrēto datplūsmu, pats ir socket. Ja tas tiek novirzīts atpakaļ uz saskarni, ko lietotne tikko izveidoja, tunelis ir atkarīgs no tuneļa un apstājas. VpnService.protect() piesaista šo socketu apakšējam tīklam, lai tas apietu uztveršanu, un tāpēc pareizs klients aizsargā savu ārējo socketu pirms pirmās rokasspiediena.
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Šīs komandas parāda instalēto VPN tīklu, vienmēr ieslēgto pakotni un to, vai ir iestatīta bloķēšana. Tie ir tikai lasāmi novērojumi: ja vērtības neatbilst tam, ko apgalvo dizains, apgalvojums attiecas uz lietotnes saskarni, nevis sistēmas stāvokli.
Bloķēšana var piederēt platformai
Android dokumentē politiku, kas bloķē savienojumus, kuri neizmanto VPN. Šī izpilde ir platformas līgums, nevis lietotne, kas cilpā atkārto savienojuma mēģinājumus. Slēdzis ir ierīces VPN iestatījumos kā Bloķēt savienojumus bez VPN, un pārvaldītā ierīcē īpašnieks to var ieslēgt visam profilam. Šī atšķirība ir svarīga, vērtējot mārketinga apgalvojumu: klients var rādīt slēdzenes ikonu un agresīvi atkārtoti pieslēgties, kamēr tiešā datplūsma joprojām ir iespējama, vai aptvertās lietotnes var palikt bezsaistē, jo sistēma izpilda bloķēšanu.
Slēdzenes ikonu zīmē lietotne, tāpēc tā pierāda tikai to, ka lietotne uzskata sevi par pieslēgtu. To, vai cita lietotne zaudēs tīkla piekļuvi, izlemj platforma, tāpēc lietderīgā pārbaude ir vērot, kā šī lietotne neizdodas, kamēr tunelis ir ieslēgts.
Arī lietotņu veikala uzlīme „vienmēr ieslēgts“ neaizstāj šo līgumu. Vienmēr ieslēgts un bloķēšana ir ierīces iestatījumi, ko bieži piemēro ierīces īpašnieks, un to uzvedību izslēgtajām lietotnēm nosaka platforma. Lasiet iestatījumu, nevis uzlīmi.
Četri jautājumi dizaina pārskatam
Pirmkārt, kas piekrita: kura pakotne, kurš profils un vai tas bija lietotājs vai pārvaldītas ierīces politika? Otrkārt, ko lietotne pieprasīja: kādus maršrutus, kādas adrešu saimes, kādas lietotnes iekļāva vai izslēdza? Treškārt, kas notiek, kad tunelis nav pieejams: vai sistēma bloķē, vai datplūsma atgriežas apakšējā tīklā? Ceturtkārt, ko lietotne dara ar saņemtajiem paketēm?
Ceturtais jautājums ir tas, uz ko atļauju modelis nevar atbildēt. Piekrišana un TUN saskarne pierāda, ka lietotne var saņemt datplūsmu, nevis to, ka tā to šifrē, autentificē otru pusi vai tīri atjaunojas. Tie ir ieviešanas atribūti, un tur godīgs pārskats pavada savu laiku.
Nevajadzīgs root pieprasījums nekļūst likumīgs, ja rezultātu nosauc par izslēgšanas slēdzi, un piekrišanas dialogs nav drošības audits. Turiet trīs atļaujas atsevišķi, un katrs apgalvojums kļūst pārbaudāms.