Ինչու ձեր Android հավելվածը չի կարող ավելացնել համակարգային VPN պրոֆիլ

Դուք սեղմում եք Կարգավորումներում VPN տողը, տեսնում եք պրոֆիլ, որը տեղադրել է մեկ ուրիշը, և սկսում եք փնտրել այն կանչը, որը մեկն ավելացնում է։ Այդպիսի կանչ գոյություն չունի։ Հավելվածը կարող է բացել իր սեփական թունելը VpnService-ի միջոցով, բայց այդ ցանկի գրառումները պատկանում են հարթակին և այն հաճախորդին, որը ստեղծել է դրանք։ Ճշգրիտ իմանալը, թե որտեղ է անցնում սահմանը, ձեզ խնայում է մեկ շաբաթ թաքնված դասերի հետևից ընկնելը։

Սկսեք նրանից, ինչ ցույց է տալիս Կարգավորումների էկրանը

VPN ցանկը պրոֆիլների գրանցամատյան է, որոնք տեղադրել է համակարգը կամ արտադրողի հաճախորդը՝ PPTP, L2TP/IPsec, IKEv2, և ցանկացած տող, որը մղել է OEM հավելվածը կամ MDM-ը։ Յուրաքանչյուր տող կրում է սերվերի հասցե, հավատարմագրեր և արձանագրության իրականացում, որը ապրում է ձեր գործընթացից դուրս։ Երբ օգտատերը այնտեղ սեղմում է Միանալ, թունելը բարձրացնում է հարթակի հաճախորդը, ոչ թե ձեր կոդը։ Այդ պատճառով տողը վերապրում է վերագործարկումը և այդ պատճառով ձեր հավելվածի տեղահանումը երբեք չի հեռացնում այն։

Օգտատիրոջ կողմից ցանկը թվում է API մակերես, տեղ, որտեղ VPN ավելացնելը պետք է մեկ մտադրության հեռավորության վրա լինի։ Այդպես չէ։ Միակ հանրային մուտքի կետերը, որոնք դիպչում են դրան, նավիգացիոն մտադրություններն են, և այն ամենը, ինչ գրում է դրա մեջ, պատկանում է հարթակին կամ արտոնյալ բաղադրիչի։

Գործնական հետևանք. եթե աջակցության տեքստն ասում է օգտատերերին ավելացնել պրոֆիլը Կարգավորումներում, ձեր հավելվածը բոլորովին այդ հոսքի մասը չէ։

Ինչ է ձեզ իրականում տալիս VpnService-ը

VpnService-ը և VpnService.Builder-ը նկարագրում են մեկ թունել, որը պատկանում է ձեր հավելվածին։ Դուք ավելացնում եք հասցեներ, երթուղիներ, DNS սերվերներ և MTU, սահմանափակում եք երթևեկությունը addAllowedApplication()-ով կամ addDisallowedApplication()-ով, և հետո establish()-ը վերադարձնում է ParcelFileDescriptor TUN ինտերֆեյսի համար։ Այդ պահից հավելվածը կարդում է IP փաթեթներ և գրում պատասխաններ, այսինքն արձանագրությունը ձերն է՝ իրականացնելու կամ ներառելու. OpenVPN, WireGuard, սեփական տրանսպորտ։

Այդ հաջորդականության մեջ ոչինչ չի խոսում PPTP, L2TP/IPsec կամ IKEv2։ Builder-ում չկա անջատիչ, որն ասի օգտագործիր համակարգի L2TP հաճախորդը, և չկա հետկանչ, որը թույլ տա ղեկավարել պրոֆիլ, որն արդեն պատկանում է հարթակին։ Սա է իրական սահմանը, և սա նախագծային սահման է, ոչ թե թույլտվությունների բացակայություն։

Այսպիսով հավելվածը կարող է միանգամայն լինել VPN հաճախորդ Android-ում։ Այն պարզապես չի կարող լինել հեռախոսի հետ եկող հաճախորդների կառավարիչ։

Համաձայնության երկխոսությունը զարդարանք չէ

Քանի որ ձեր թունելը կարող է որսալ այլ հավելվածների երթևեկությունը, համակարգը ստիպում է օգտատիրոջը բացահայտ հաստատել այն։ prepare()-ը վերադարձնում է Intent, որը դուք պետք է գործարկեք, հաստատումը կապված է ձեր փաթեթի հետ, և քանի դեռ թունելը միացած է, կարգավիճակի գոտին ցույց է տալիս մշտական ցուցիչ։ Երկրորդ VPN-ի բարձրանալը անջատում է առաջինը, քանի որ Android-ը միաժամանակ մեկ ակտիվ VPN է աշխատեցնում։

Մեկ ակտիվի այդ կանոնը սայթաքեցնում է մարդկանց փորձարկման ժամանակ։ Դուք բարձրացնում եք ձեր թունելը, երբ կորպորատիվ հաճախորդը միացած է, և եզրակացնում, որ ձեր կոդը կոտրված է, մինչդեռ հարթակը պարզապես փոխել է մյուս հաճախորդից։ Հաստատումները կարելի է հետո չեղարկել, և prepare()-ը կարող է վերադարձնել null այն սարքերում, որտեղ բացակայում է համաձայնության ակտիվությունը, այնպես որ establish()-ը դեռ պետք է կարգավորի ձախողումը։

Թաքնված API-ներ և կարգավորումների մտադրություններ

Ավելի հին պատասխանները մատնանշում են com.android.internal դասերին և AIDL ինտերֆեյսներին, որոնք օգտագործում է ներկառուցված հաճախորդը։ Դրանք SDK-ում չեն, թողարկումների միջև փոխվում են առանց ծանուցման, և հավելվածների խանութները այդ հասանելիությունը համարում են ռիսկ։ Սարքը root անելը նույնպես դրանք կայուն չի դարձնում, որովհետև root-ը և թաքնված API-ի հասանելիությունը անկապ խնդիրներ են։

Աջակցվող նավիգացիոն օգնականը Settings.ACTION_VPN_SETTINGS-ն է, որի արժեքը android.net.vpn.SETTINGS է։ Լուծեք այն գործարկելուց առաջ, որովհետև որոշ OEM կառուցվածքներ չեն մատակարարում այդ ակտիվությունը, և անցեք գրավոր քայլերին, երբ լուծումը ձախողվի։ Այն տանում է օգտատիրոջը էկրան և ոչինչ չի կարգավորում։

Սարքի սեփականատիրոջ և MDM ուղիները այն բացառությունն են, որ մարդիկ սովորաբար նկատի ունեն։ DevicePolicyManager-ը կարող է նշանակել մշտապես միացված VPN փաթեթ, և կառավարվող կոնֆիգուրացիաները կարող են նախաբեռնել կարգավորումներ այն հաճախորդի համար, որը դրանք աջակցում է, բայց սա դեռ հանրային SDK-ն չէ, որը գրում է PPTP պրոֆիլ։

Անցեք որոշումը օգտատիրոջ կողմից

Եթե ձեր արտադրանքը պետք է տեղափոխի երթևեկություն, պլանավորեք VpnService-ը գումարած իրական արձանագրության կույտ, և ժամանակ հատկացրեք համաձայնության հոսքին և մեկ VPN-ի կանոնին։ Եթե նպատակը գոյություն ունեցող կորպորատիվ պրոֆիլին միանալն է, ձեր գործը ուղղորդումն է. խորը հղում կարգավորումների էկրանին, դաշտերի փաստաթղթավորում, և թող հարթակի հաճախորդը կատարի թունելավորումը։ Եթե հավելվածին պետք է միայն հասնել մասնավոր վերջնակետի, այն ընդհանրապես իր թունելի կարիքը չունի։

Գրեք այդ որոշումը նախքան կոդ գրելը, որովհետև երեք ուղիները առաջին սպրինտից հետո գրեթե ոչինչ ընդհանուր չունեն։

Վերջին ստուգումը մեկնարկից առաջ. պահանջը ասում է, որ միանում է մեր հավելվածը, թե սարքը։ Առաջինը VpnService-ն է, երկրորդը՝ պրոֆիլ, որը դուք չեք կարող ստեղծել։ Այդ նախադասությունը ճիշտ ձևակերպելը ավելի էժան է, քան ցանկացած վերակառուցում։