Android VPN առանց root-ի. ումն են պատկանում համաձայնությունը, երթուղիները և արգելափակումը
Համաձայնությունը, TUN միջերեսը և համակարգի արգելափակման քաղաքականությունը երեք տարբեր թույլտվություններ են։ Բացահայտեք, թե որ բաղադրիչին է պատկանում դրանցից յուրաքանչյուրը, նախքան Android VPN հավելվածը վերանայելը։
Root-ը այն չէ, ինչը Android VPN հավելվածին թույլ է տալիս փոխադրել երթևեկը, արգելափակել արտահոսքերը կամ վերապրել վերագործարկումը։ Մարդիկ այս ամենը ամփոփում են որպես «հավելվածը ունի VPN թույլտվություն», ինչը թաքցնում է երեք առանձին մեխանիզմ՝ օգտատիրոջ տված համաձայնություն, համակարգի ստեղծած փաթեթային միջերես և հարթակի արգելափակման քաղաքականություն, որը հավելվածին չէ որոշելը։ Android VPN-ի ձևավորումը վերանայելը նշանակում է հարցնել, թե այդ երեքից որի վրա է իրականում հենվում պնդումը, քանի որ յուրաքանչյուրն ունի այլ սեփականատեր և այլ ձախողման եղանակ։
Համաձայնությունը գալիս է համակարգային ակտիվության միջոցով
VpnService.prepare() ոչինչ չի տալիս։ Երբ համաձայնությունը բացակայում է, այն intent է վերադարձնում համակարգի համաձայնության ակտիվությանը, և հավելվածը բացում է այդ երկխոսությունը, որպեսզի օգտատերը հաստատի ծառայությունը։ Հավելվածի սեփական գործընթացը սկսելը, մանիֆեստում թույլտվություն ավելացնելը կամ «միացնել VPN»-ի հատուկ էկրան ցուցադրելը չի ստեղծում թույլտվությունը։
Թույլտվությունը նաև սահմանափակ է։ Այն պատկանում է օգտատիրոջ պրոֆիլի փաթեթին, ուստի անձնական պատճենը և աշխատանքային պատճենը առանձին որոշումներ են, և սարքի սեփականատերը կարող է կառավարվող պրոֆիլը այլ կերպ պատրաստել, քան անձնականը։ Եթե երկխոսությունը երբեք չի հայտնվում, և prepare()-ը վերադարձնում է null, ապա այդ պրոֆիլում այդ փաթեթի համար համաձայնություն արդեն կա. սա հավելվածի վստահելիության ապացույց չէ, միայն այն, որ թույլտվությունը տեղում է։
Միջերեսը համակարգի կատարած հարցումն է
Համաձայնությունից հետո հավելվածը VpnService.Builder-ով նկարագրում է, ինչ ուզում է՝ հասցեներ, երթուղիներ, DNS սերվերներ, MTU և, որտեղ աջակցվում է, ներառվող կամ բացառվող հավելվածները։ establish()-ը համակարգից խնդրում է ստեղծել թունելի միջերեսը և ուղղել համապատասխան երթևեկը դրա մեջ։ Երթուղավորման որոշումը համակարգինն է. հավելվածը ստանում է ֆայլի նկարագրիչը և հետո պետք է ինչ-որ օգտակար բան անի փաթեթների հետ։
| 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 |
Այդ աղյուսակը ճարտարապետությունն է մեկ տեղում։ Հավելվածը մասնակցում է փաթեթների մշակմանը. այն չի տիրապետում միջերեսին, երթուղավորման աղյուսակին կամ թույլատրված ծառայությունների քանակին։
Թունելի socket-ը պետք է փախչի իր իսկ թունելից
Գաղտնագրված երթևեկը փոխադրող կապը ինքնին socket է։ Եթե այն հետ ուղղվի հենց նոր ստեղծված միջերես, թունելը կախված է թունելից և կանգ է առնում։ VpnService.protect()-ը կապում է այդ socket-ը հիմքում ընկած ցանցին, որպեսզի այն շրջանցի որսումը, և այդ պատճառով ճիշտ հաճախորդը պաշտպանում է իր արտաքին socket-ը առաջին ձեռքսեղմումից առաջ։
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Այս հրամանները ցույց են տալիս տեղադրված VPN ցանցը, մշտապես միացված փաթեթը և արդյոք կողպումը սահմանված է։ Դրանք միայն ընթերցման դիտարկումներ են. եթե արժեքները չեն համապատասխանում նախագծի պնդմանը, պնդումը վերաբերում է հավելվածի միջերեսին, ոչ թե համակարգի վիճակին։
Արգելափակումը կարող է պատկանել հարթակին
Android-ը փաստաթղթավորում է քաղաքականություն, որն արգելափակում է կապերը, որոնք չեն օգտագործում VPN-ը։ Այդ կիրարկումը հարթակի պայմանագիր է, ոչ թե հավելված, որն օղակում նորից փորձում է կապերը։ Անջատիչը սարքի VPN կարգավորումներում է՝ «Արգելափակել կապերը առանց VPN-ի», և կառավարվող սարքում սեփականատերը կարող է այն միացնել ամբողջ պրոֆիլի համար։ Տարբերությունը կարևոր է մարքեթինգային պնդումը գնահատելիս. հաճախորդը կարող է ցույց տալ կողպեքի պատկերակ և ագրեսիվ վերամիանալ, մինչ ուղիղ երթևեկը դեռ հնարավոր է, կամ ծածկված հավելվածները կարող են մնալ անցանց, որովհետև համակարգը կիրառում է կողպումը։
Կողպեքի պատկերակը նկարում է հավելվածը, ուստի այն ապացուցում է միայն, որ հավելվածը կարծում է, թե միացված է։ Արդյոք մեկ այլ հավելված կկորցնի ցանցային հասանելիությունը, որոշում է հարթակը, ուստի օգտակար ստուգումը դիտելն է, թե ինչպես է այդ հավելվածը ձախողվում, երբ թունելը միացված է։
«Մշտապես միացված» պիտակը հավելվածների խանութից նույնպես չի փոխարինում այդ պայմանագրին։ Մշտապես միացվածը և կողպումը սարքի կարգավորումներ են, որոնք հաճախ կիրառում է սարքի սեփականատերը, և դրանց վարքը բացառված հավելվածների համար սահմանում է հարթակը։ Կարդացեք կարգավորումը, ոչ թե նշանը։
Չորս հարց ձևավորման վերանայման համար
Առաջին՝ ով տվեց համաձայնություն. ո՞ր փաթեթը, ո՞ր պրոֆիլը, և դա օգտատե՞րն էր, թե կառավարվող սարքի քաղաքականությունը։ Երկրորդ՝ ինչ խնդրեց հավելվածը. որ երթուղիները, որ հասցեների ընտանիքները, որ ներառված կամ բացառված հավելվածները։ Երրորդ՝ ինչ է լինում, երբ թունելը հասանելի չէ. համակարգը արգելափակու՞մ է, թե՞ երթևեկը վերադառնում է հիմքում ընկած ցանց։ Չորրորդ՝ ինչ է անում հավելվածը ստացած փաթեթների հետ։
Չորրորդ հարցն այն է, որին թույլտվությունների մոդելը չի կարող պատասխանել։ Համաձայնությունը և TUN միջերեսը ապացուցում են, որ հավելվածը կարող է ստանալ երթևեկ, ոչ թե որ այն գաղտնագրում է այն, նույնականացնում է զուգընկերոջը կամ մաքուր վերականգնվում։ Դրանք իրականացման հատկություններ են, և հենց այնտեղ է ազնիվ վերանայումը ծախսում ժամանակը։
Ավելորդ root-ի հարցումը օրինավոր չի դառնում արդյունքը «kill switch» անվանելով, և համաձայնության երկխոսությունը անվտանգության աուդիտ չէ։ Պահեք երեք թույլտվությունները առանձին, և յուրաքանչյուր պնդում դառնում է ստուգելի։