VPN pe Android fără root: cine deține consimțământul, rutele și blocarea
Consimțământul, interfața TUN și politica de blocare a sistemului sunt trei permisiuni diferite. Identifică ce componentă deține fiecare înainte de a evalua o aplicație VPN pentru Android.
Root nu este ceea ce permite unei aplicații VPN pentru Android să transporte trafic, să blocheze scurgeri sau să supraviețuiască unei reporniri. Oamenii rezumă toate acestea ca „aplicația are permisiune VPN“, ceea ce ascunde trei mecanisme separate: un consimțământ dat de utilizator, o interfață de pachete pe care sistemul o stabilește și o politică de blocare a platformei pe care nu aplicația o definește. A evalua un design VPN pentru Android înseamnă a întreba pe care dintre cele trei se sprijină de fapt o afirmație, pentru că fiecare are alt proprietar și alt mod de eșec.
Consimțământul vine printr-o activitate de sistem
VpnService.prepare() nu acordă nimic. Returnează un intent către activitatea de consimțământ a sistemului atunci când consimțământul lipsește, iar aplicația deschide acel dialog pentru ca utilizatorul să aprobe serviciul. Pornirea propriului proces al aplicației, adăugarea unei permisiuni în manifest sau afișarea unui ecran personalizat „activează VPN“ nu creează acordul.
Acordul are și un domeniu. Aparține unui pachet dintr-un profil de utilizator, așa că copia personală și copia de lucru sunt decizii separate, iar proprietarul dispozitivului poate pregăti un profil administrat altfel decât unul personal. Dacă dialogul nu apare niciodată și prepare() returnează null, consimțământul există deja pentru acel pachet în acel profil; nu este dovada că aplicația este de încredere, doar că acordul este în vigoare.
Interfața este o cerere pe care sistemul o îndeplinește
După consimțământ, aplicația descrie ce vrea cu VpnService.Builder: adrese, rute, servere DNS, MTU și, unde este acceptat, aplicațiile de inclus sau exclus. establish() cere sistemului să creeze interfața de tunel și să direcționeze traficul corespunzător în ea. Sistemul deține decizia de rutare; aplicația primește descriptorul de fișier și apoi trebuie să facă ceva util cu pachetele.
| 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 |
Acest tabel este arhitectura într-un singur loc. Aplicația participă la gestionarea pachetelor; nu deține interfața, tabelul de rutare sau numărul de servicii care pot rula.
Socketul tunelului trebuie să scape din propriul tunel
Conexiunea care transportă traficul criptat este ea însăși un socket. Dacă este direcționată înapoi în interfața pe care aplicația tocmai a creat-o, tunelul depinde de tunel și se blochează. VpnService.protect() leagă acel socket de rețeaua subiacentă ca să ocolească capturarea, și de aceea un client corect își protejează socketul exterior înainte de primul handshake.
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_lockdownAceste comenzi arată rețeaua VPN instalată, pachetul pentru pornire permanentă și dacă blocarea este setată. Sunt observații doar pentru citire: dacă valorile nu corespund cu ce afirmă designul, afirmația este despre interfața aplicației și nu despre starea sistemului.
Blocarea poate aparține platformei
Android documentează o politică ce blochează conexiunile care nu folosesc VPN. Acea aplicare este un contract al platformei, nu o aplicație care reîncearcă conexiuni în buclă. Comutatorul se află în setările VPN ale dispozitivului ca Blochează conexiunile fără VPN, iar pe un dispozitiv administrat proprietarul îl poate activa pentru întregul profil. Distincția contează când evaluezi o afirmație de marketing: un client poate afișa o pictogramă cu lacăt și se poate reconecta agresiv în timp ce traficul direct rămâne posibil, sau aplicațiile acoperite pot rămâne offline pentru că sistemul aplică blocarea.
Pictograma cu lacăt este desenată de aplicație, deci dovedește doar că aplicația crede că este conectată. Dacă o altă aplicație pierde accesul la rețea decide platforma, așa că verificarea utilă este să vezi acea aplicație eșuând în timp ce tunelul este activ.
Nici eticheta „pornit mereu“ din magazinul de aplicații nu înlocuiește acel contract. Pornirea permanentă și blocarea sunt setări ale dispozitivului, adesea aplicate de proprietar, iar comportamentul lor pentru aplicațiile excluse este definit de platformă. Citește setarea, nu insigna.
Patru întrebări pentru o revizuire de design
Întâi, cine a consimțit: ce pachet, ce profil și a fost utilizatorul sau o politică de dispozitiv administrat? Al doilea, ce a cerut aplicația: ce rute, ce familii de adrese, ce aplicații incluse sau excluse? Al treilea, ce se întâmplă când tunelul nu este disponibil: sistemul blochează sau traficul revine la rețeaua subiacentă? Al patrulea, ce face aplicația cu pachetele pe care le primește?
A patra întrebare este cea la care modelul de permisiuni nu poate răspunde. Consimțământul și o interfață TUN dovedesc că aplicația poate primi trafic, nu că îl criptează, autentifică un partener sau se recuperează curat. Acestea sunt proprietăți de implementare, și acolo o revizuire onestă își petrece timpul.
O cerere de root inutilă nu devine legitimă dacă rezultatul se numește întrerupător de siguranță, iar un dialog de consimțământ nu este un audit de securitate. Ține cele trei acorduri separate și fiecare afirmație devine verificabilă.