Android VPN bez roota: kome pripadaju privola, rute i blokiranje

Root nije ono što omogućuje Android VPN aplikaciji da prenosi promet, blokira curenja ili preživi ponovno pokretanje. Ljudi sve to sažimaju kao „aplikacija ima VPN dozvolu“, što skriva tri odvojena mehanizma: privolu koju daje korisnik, paketno sučelje koje sustav uspostavlja i platformsku politiku blokiranja koju aplikacija ne definira. Pregledati dizajn Android VPN-a znači pitati na koje se od tih triju tvrdnja zapravo oslanja, jer svako ima drugog vlasnika i drugi način kvara.

Privola dolazi kroz sistemsku aktivnost

VpnService.prepare() ne daje ništa. Vraća intent sistemskoj aktivnosti za privolu kad privola nedostaje, a aplikacija pokreće taj dijalog kako bi korisnik odobrio uslugu. Pokretanje vlastitog procesa aplikacije, dodavanje dozvole u manifest ili prikaz vlastitog zaslona „omogući VPN“ ne stvara odobrenje.

Odobrenje je i ograničenog opsega. Pripada paketu u korisničkom profilu, pa su osobna kopija i radna kopija odvojene odluke, a vlasnik uređaja može pripremiti upravljani profil drukčije od osobnog. Ako se dijalog nikad ne pojavi i prepare() vrati null, privola već postoji za taj paket u tom profilu; to nije dokaz da je aplikacija pouzdana, samo da je odobrenje na mjestu.

Sučelje je zahtjev koji sustav ispunjava

Nakon privole aplikacija opisuje što želi pomoću VpnService.Builder: adrese, rute, DNS poslužitelje, MTU i, gdje je podržano, aplikacije koje treba uključiti ili isključiti. establish() traži od sustava da stvori tunelsko sučelje i usmjeri odgovarajući promet u njega. Sustav posjeduje odluku o usmjeravanju; aplikacija dobiva deskriptor datoteke i zatim mora učiniti nešto korisno s paketima.

Ta je tablica arhitektura na jednom mjestu. Aplikacija sudjeluje u obradi paketa; ne posjeduje sučelje, tablicu usmjeravanja ni broj usluga koje smiju raditi.

Tunelski socket mora pobjeći iz vlastitog tunela

Veza koja prenosi šifrirani promet i sama je socket. Ako se usmjeri natrag u sučelje koje je aplikacija upravo stvorila, tunel ovisi o tunelu i staje. VpnService.protect() veže taj socket za donju mrežu tako da zaobiđe hvatanje, i zato ispravan klijent štiti svoj vanjski socket prije prvog rukovanja.

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

Ove naredbe prikazuju instaliranu VPN mrežu, paket za stalno uključeno stanje i je li zaključavanje postavljeno. To su zapažanja samo za čitanje: ako se vrijednosti ne poklapaju s onim što dizajn tvrdi, tvrdnja se odnosi na sučelje aplikacije, a ne na stanje sustava.

Blokiranje može pripadati platformi

Android dokumentira politiku koja blokira veze koje ne koriste VPN. To provođenje je ugovor platforme, a ne aplikacija koja u petlji ponovno pokušava veze. Prekidač je u VPN postavkama uređaja kao Blokiraj veze bez VPN-a, a na upravljanom uređaju vlasnik ga može uključiti za cijeli profil. Razlika je važna kad procjenjujete marketinšku tvrdnju: klijent može prikazati ikonu lokota i agresivno se ponovno povezivati dok je izravni promet još moguć, ili pokrivene aplikacije mogu ostati izvan mreže jer sustav provodi zaključavanje.

Ikonu lokota crta aplikacija, pa ona dokazuje samo da aplikacija vjeruje da je povezana. O tome hoće li druga aplikacija izgubiti mrežni pristup odlučuje platforma, pa je korisna provjera gledati tu aplikaciju kako ne uspijeva dok je tunel aktivan.

Oznaka „stalno uključeno“ iz trgovine aplikacija također ne zamjenjuje taj ugovor. Stalno uključeno i zaključavanje su postavke uređaja, koje često primjenjuje vlasnik uređaja, a njihovo ponašanje za izuzete aplikacije definira platforma. Čitajte postavku, ne značku.

Četiri pitanja za pregled dizajna

Prvo, tko je dao privolu: koji paket, koji profil i je li to bio korisnik ili politika upravljanog uređaja? Drugo, što je aplikacija zatražila: koje rute, koje porodice adresa, koje uključene ili isključene aplikacije? Treće, što se događa kad tunel nije dostupan: blokira li sustav ili promet pada natrag na donju mrežu? Četvrto, što aplikacija radi s paketima koje primi?

Četvrto pitanje je ono na koje model dozvola ne može odgovoriti. Privola i TUN sučelje dokazuju da aplikacija može primati promet, ne da ga šifrira, autentificira drugu stranu ili se čisto oporavlja. To su svojstva implementacije i tu iskren pregled troši svoje vrijeme.

Nepotreban zahtjev za root ne postaje legitiman ako se rezultat nazove prekidačem za ubijanje, a dijalog privole nije sigurnosni audit. Držite tri odobrenja odvojeno i svaka tvrdnja postaje provjerljiva.