VPN në Android pa root: kush zotëron pëlqimin, rrugët dhe bllokimin
Pëlqimi, ndërfaqja TUN dhe politika e bllokimit të sistemit janë tre leje të ndryshme. Gjurmo cili komponent zotëron secilën para se të shqyrtosh një aplikacion VPN për Android.
Root nuk është ajo që lejon një aplikacion VPN për Android të transportojë trafik, të bllokojë rrjedhje ose t'i mbijetojë një rindezjeje. Njerëzit e përmbledhin të gjithë këtë si „aplikacioni ka leje VPN“, çka fsheh tre mekanizma të veçantë: një pëlqim të dhënë nga përdoruesi, një ndërfaqe paketash që sistemi vendos dhe një politikë bllokimi e platformës që nuk është e aplikacionit ta përcaktojë. Shqyrtimi i një dizajni VPN për Android do të thotë të pyesësh se në cilën nga të treja mbështetet vërtet një pretendim, sepse secila ka pronar dhe mënyrë dështimi të ndryshme.
Pëlqimi vjen përmes një aktiviteti sistemi
VpnService.prepare() nuk jep asgjë. Ai kthen një intent te aktiviteti i pëlqimit të sistemit kur pëlqimi mungon, dhe aplikacioni hap atë dialog që përdoruesi të miratojë shërbimin. Nisja e procesit të vetë aplikacionit, shtimi i një leje në manifest ose shfaqja e një ekrani të personalizuar „aktivizo VPN“ nuk e krijojnë lejen.
Leja ka edhe shtrirje. I përket një pakete në një profil përdoruesi, prandaj kopja personale dhe kopja e punës janë vendime të ndara, dhe pronari i pajisjes mund të përgatisë një profil të menaxhuar ndryshe nga një personal. Nëse dialogu nuk shfaqet kurrë dhe prepare() kthen null, pëlqimi ekziston tashmë për atë paketë në atë profil; kjo nuk është provë se aplikacioni është i besueshëm, vetëm se leja është aty.
Ndërfaqja është një kërkesë që sistemi e plotëson
Pas pëlqimit, aplikacioni përshkruan çfarë dëshiron me VpnService.Builder: adresa, rrugë, serverë DNS, MTU dhe, ku mbështetet, aplikacionet që përfshihen ose përjashtohen. establish() i kërkon sistemit të krijojë ndërfaqen e tunelit dhe të drejtojë trafikun përkatës në të. Sistemi zotëron vendimin e rrugëtimit; aplikacioni merr përshkruesin e skedarit dhe më pas duhet të bëjë diçka të dobishme me paketat.
| 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 |
Ajo tabelë është arkitektura në një vend. Aplikacioni merr pjesë në trajtimin e paketave; ai nuk zotëron ndërfaqen, tabelën e rrugëtimit ose numrin e shërbimeve që mund të ekzekutohen.
Socket-i i tunelit duhet të shpëtojë nga tuneli i vet
Lidhja që transporton trafikun e kriptuar është vetë një socket. Nëse drejtohet përsëri në ndërfaqen që aplikacioni sapo krijoi, tuneli varet nga tuneli dhe ngec. VpnService.protect() e lidh atë socket me rrjetin bazë që ai të anashkalojë kapjen, dhe prandaj një klient i saktë mbron socket-in e tij të jashtëm para dorështrëngimit të parë.
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_lockdownKëto komanda tregojnë rrjetin VPN të instaluar, paketën gjithmonë aktive dhe nëse bllokimi është vendosur. Janë vëzhgime vetëm-lexim: nëse vlerat nuk përputhen me atë që pretendon dizajni, pretendimi ka të bëjë me ndërfaqen e aplikacionit dhe jo me gjendjen e sistemit.
Bllokimi mund t'i përkasë platformës
Android dokumenton një politikë që bllokon lidhjet që nuk përdorin VPN. Ai zbatim është kontratë e platformës, jo një aplikacion që përsërit përpjekjet për lidhje në cikël. Ndërprerësi ndodhet te cilësimet VPN të pajisjes si Blloko lidhjet pa VPN, dhe në një pajisje të menaxhuar pronari mund ta aktivizojë për të gjithë profilin. Dallimi ka rëndësi kur vlerëson një pretendim marketingu: klienti mund të shfaqë një ikonë dryni dhe të rilidhet në mënyrë agresive ndërsa trafiku i drejtpërdrejtë është ende i mundur, ose aplikacionet e mbuluara mund të mbeten jashtë linje sepse sistemi zbaton bllokimin.
Ikonën e drynit e vizaton aplikacioni, prandaj vërteton vetëm se aplikacioni beson se është i lidhur. Nëse një aplikacion tjetër humbet aksesin në rrjet vendos platforma, prandaj kontrolli i dobishëm është të shohësh atë aplikacion duke dështuar ndërsa tuneli është aktiv.
As etiketa „gjithmonë aktiv“ nga dyqani i aplikacioneve nuk e zëvendëson atë kontratë. Gjithmonë aktiv dhe bllokimi janë cilësime të pajisjes, shpesh të zbatuara nga pronari, dhe sjellja e tyre për aplikacionet e përjashtuara përcaktohet nga platforma. Lexo cilësimin, jo shenjën.
Katër pyetje për një rishikim dizajni
Së pari, kush dha pëlqimin: cila paketë, cili profil dhe a ishte përdoruesi apo një politikë e pajisjes së menaxhuar? Së dyti, çfarë kërkoi aplikacioni: cilat rrugë, cilat familje adresash, cilat aplikacione të përfshira ose të përjashtuara? Së treti, çfarë ndodh kur tuneli nuk është i disponueshëm: sistemi bllokon apo trafiku bie përsëri në rrjetin bazë? Së katërti, çfarë bën aplikacioni me paketat që merr?
Pyetja e katërt është ajo të cilën modeli i lejeve nuk mund t'i përgjigjet. Pëlqimi dhe një ndërfaqe TUN vërtetojnë se aplikacioni mund të marrë trafik, jo se e kripton, vërteton palën tjetër ose rikuperohet pastër. Këto janë veti implementimi, dhe aty një rishikim i ndershëm e kalon kohën e tij.
Një kërkesë e panevojshme për root nuk bëhet legjitime duke e quajtur rezultatin kill switch, dhe një dialog pëlqimi nuk është auditim sigurie. Mbaji tre lejet të ndara dhe çdo pretendim bëhet i verifikueshëm.