Root nije ono što omogućava Android VPN aplikaciji da prenosi saobraćaj, blokira curenja ili preživi restart. Ljudi sve to sažimaju u „aplikacija ima VPN dozvolu“, što skriva tri odvojena mehanizma: pristanak koji daje korisnik, paketni interfejs koji sistem uspostavlja i platformsku politiku blokiranja koju aplikacija ne definiše. Pregledati dizajn Android VPN-a znači pitati na koje se od ta tri zaista oslanja neka tvrdnja, jer svako ima drugog vlasnika i drugi način kvara.

Pristanak dolazi kroz sistemsku aktivnost

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

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

Interfejs je zahtev koji sistem ispunjava

Nakon pristanka aplikacija opisuje šta želi pomoću VpnService.Builder: adrese, rute, DNS servere, MTU i, gde je podržano, aplikacije koje treba uključiti ili isključiti. establish() traži od sistema da stvori tunelski interfejs i usmeri odgovarajući saobraćaj u njega. Sistem poseduje odluku o rutiranju; aplikacija dobija deskriptor datoteke i zatim mora učiniti nešto korisno s paketima.

What you observeWho actually owns it
VPN consent dialogThe system, triggered by prepare()
Routes, DNS and app listsThe app requests them; the system applies them
One active VPN per profileThe platform; a new service replaces the old one
Always-on and block-without-VPNDevice policy enforced by the platform

Ta tabela je arhitektura na jednom mestu. Aplikacija učestvuje u obradi paketa; ne poseduje interfejs, tabelu rutiranja ni broj usluga koje smeju da rade.

Tunelski socket mora pobeći iz sopstvenog tunela

Veza koja prenosi šifrovani saobraćaj i sama je socket. Ako se usmeri natrag u interfejs koji je aplikacija upravo stvorila, tunel zavisi od tunela i staje. VpnService.protect() vezuje taj socket za donju mrežu tako da zaobiđe hvatanje, i zato ispravan klijent štiti svoj spoljni socket pre 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 komande prikazuju instaliranu VPN mrežu, paket za stalno uključeno stanje i da li je zaključavanje postavljeno. To su zapažanja samo za čitanje: ako se vrednosti ne poklapaju s onim što dizajn tvrdi, tvrdnja se odnosi na interfejs aplikacije, a ne na stanje sistema.

Blokiranje može pripadati platformi

Android dokumentuje politiku koja blokira veze koje ne koriste VPN. To sprovođenje je ugovor platforme, a ne aplikacija koja u petlji ponovo 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 ceo profil. Razlika je važna kada procenjujete marketinšku tvrdnju: klijent može prikazati ikonu katanca i agresivno se ponovo povezivati dok je direktan saobraćaj još moguć, ili pokrivene aplikacije mogu ostati van mreže jer sistem sprovodi zaključavanje.

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

Ni oznaka „stalno uključeno“ iz prodavnice aplikacija ne zamenjuje taj ugovor. Stalno uključeno i zaključavanje su postavke uređaja, koje često primenjuje vlasnik uređaja, a njihovo ponašanje za izuzete aplikacije definiše platforma. Čitajte postavku, ne značku.

Četiri pitanja za pregled dizajna

Prvo, ko je dao pristanak: koji paket, koji profil i da li je to bio korisnik ili politika upravljanog uređaja? Drugo, šta je aplikacija zatražila: koje rute, koje porodice adresa, koje uključene ili isključene aplikacije? Treće, šta se dešava kada tunel nije dostupan: da li sistem blokira ili saobraćaj pada natrag na donju mrežu? Četvrto, šta aplikacija radi s paketima koje primi?

Četvrto pitanje je ono na koje model dozvola ne može odgovoriti. Pristanak i TUN interfejs dokazuju da aplikacija može primati saobraćaj, ne da ga šifruje, autentifikuje drugu stranu ili se čisto oporavlja. To su svojstva implementacije i tu iskren pregled troši svoje vreme.

Nepotreban zahtev za root ne postaje legitiman ako se rezultat nazove prekidačem za ubijanje, a dijalog pristanka nije bezbednosni audit. Držite tri odobrenja odvojeno i svaka tvrdnja postaje proverljiva.

Povezani članci