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

Երկու շատ տարբեր աշխատանքներ դրվում են ծրագրային VPN անվան տակ, և դրանցից միայն մեկն է հասանելի սովորական հավելվածին երկու բջջային հարթակներից որևէ մեկում։ Առաջինը պահված պրոֆիլը միացնելն է, որը օգտատերն արդեն պահել է, երկրորդը ձեր սեփական գործընթացի ներսում թունել կառուցելն է։ Android-ը երկրորդը տալիս է VpnService-ի միջոցով, իսկ iOS-ը երկրորդը տալիս է Network Extension իրավունքի միջոցով, մինչդեռ առաջինը մնում է համակարգին, սարքի սեփականատիրոջը կամ MDM սերվերին։ Պարզելը, թե որն է ձեզ իրականում պետք, սովորաբար նախագիծը դարձնում է ավելի փոքր։

Երկու աշխատանք մեկ անունով

Պահված պրոֆիլի ակտիվացումը նշանակում է ասել գոյություն ունեցող թունելին, որ բարձրանա՝ հոսթ, հավատարմագրեր, արձանագրություն, ամեն ինչ արդեն կարգավորված է մի տեղում, որը օգտատերը կարող է տեսնել։ Թունել կառուցելը նշանակում է, որ ձեր կոդը տիրապետում է ինտերֆեյսին, փաթեթների հանգույցին և արձանագրությանը։ Արտադրանքի ցանկում նրանք նման են երևում և գրեթե ոչ մի իրականացում չեն կիսում։

Բջջային հարթակներից ոչ մեկը առաջինը չի բացում SDK հավելվածի առաջ։ Կապը, որը հայտնվում է առանց օգտատիրոջ որևէ գործողության, հնարավոր չէ տարբերել վնասակար ծրագրերից, դրա համար երկու համակարգերն էլ համաձայնության դարպաս են դնում ցանկացած հավելվածի առաջ, որը տրաֆիկ է տեղափոխում։

Android՝ համաձայնության դարպաս, և ոչ մի պրոֆիլի API

VpnService գոյություն ունի Android 4.0-ից և թույլ է տալիս հավելվածին ստեղծել tun ինտերֆեյս, ապա կարդալ և գրել փաթեթներ։ Ծառայությունը պետք է հայտարարվի BIND_VPN_SERVICE-ով, և VpnService.prepare()-ը ստեղծում է համակարգի երկխոսությունը, որը օգտատիրոջից թույլտվություն է խնդրում։ Հարթակի օրինակը՝ ToyVpn-ը, նախատեսված ձևի ամենապարզ շարադրանքն է, ձեր կոդը տիրապետում է ինտերֆեյսին և այն ամենին, ինչ հոսում է դրա միջով։

Այն, ինչ այն չի անում, համակարգի VPN կարգավորումների էկրանին գրառում ավելացնելն է։ Դրա համար հանրային API չկա, և Կարգավորումներ հավելվածը պահում է իր պրոֆիլները պահոցում, որտեղ սովորական հավելվածը չի հասնում։ Թաքնված դասերին կանչերը սովորական հավելվածից ստեղծում են պրոֆիլներ, որոնք համակարգը երբեք չի ցուցադրում, դրա համար կոդը, որը թվում էր աշխատում է մեկ կառուցվածքում, հանգիստ դադարում է աշխատել հաջորդում։

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

iOS՝ իրավունքն է սահմանը

iOS-ը նույն աշխատանքը բաժանում է այլ կերպ։ VPN հաճախորդը իրականացնում է փաթեթային թունելի մատակարար կամ հավելվածի փոխանորդ Network Extension շրջանակում, և համապատասխան իրավունքը պետք է տրվի մշակողի հաշվին։ Անձնական VPN կարգավորումը NEVPNManager-ի միջոցով գոյություն ունի ավելի պարզ դեպքի համար, և այն դեռ աշխատում է նույն թույլտվությունների մոդելում։ Apple-ը ամբողջ մակերեսը փաստաթղթավորում է Network Extension տեղեկատուում, որը արժե կարդալ աշխատանքի ծավալը որոշելուց առաջ։

VPN կարգավորումների էկրանը բացելու, օգտատիրոջ պահված կարգավորումները կարդալու կամ դրանցից մեկը սկսելու աջակցվող եղանակ չկա։ Այն, ինչ հաճախորդը կարող է անել, տեղադրման համար կարգավորման պրոֆիլ ուղարկելն է, ապա ստեղծված թունելն օգտագործել սովորական ցանցային կանչերով։ Յուրաքանչյուր հավելվածի թունելավորումը նշանակում է MDM սերվերը պահանջով կանոնի միջոցով, ոչ թե հավելվածն է ընտրում այն գործարկման ժամանակ։

Խոշոր մատակարարի VPN հաճախորդը ապացույց չէ, որ ձեր հաշիվը կարող է ուղարկել նույնը։ Այդ իրավունքները խնդրվում են յուրաքանչյուր մշակողի հաշվի համար և վերանայվում, ուստի ժամանակացույցի ռիսկը Apple-ի մոտ է, ոչ թե ձեր սպրինտի պլանում։

Աշխատասեղանը ավելի հեռու է հասնում, բայց սեփականությունը նույնն է

Windows-ը թույլատրող դեպքն է։ Add-VpnConnection-ը ստեղծում է հեռախոսագրքի գրառում բարձրացված PowerShell նստաշրջանից, և rasdial-ը միացնում կամ անջատում է այն սկրիպտից։ Հավելվածը կարող է նաև վարել մատակարարի հաճախորդը նրա փաստաթղթավորված հրամանների տողով։ Պրոֆիլի ստեղծումը դեռ վարչական գործողություն է, որովհետև գրառումը ապրում է մեքենայի ամբողջ պահոցում։

macOS-ը նույն կերպ է վարվում այլ գործիքների հետ։ scutil --nc start-ը և stop-ը աշխատում են արդեն գոյություն ունեցող ծառայությունների վրա, մինչդեռ մեկը ստեղծելը համակարգի կառավարման խնդիր է։ Գործընթացին տիրապետելը նոթբուքում ձեզ չի դարձնում կարգավորման սեփականատեր։

Ինչ կառուցել փոխարենը

Եթե իրական պահանջն այն է, որ ձեր հավելվածը հասնի ներքին API-ին, օգտատերի արդեն գործարկած թունելը բավական է։ Ուղարկեք սովորական HTTPS հարցումներ, թող համակարգը ընտրի ուղին, և դադարեք փորձել կառավարել թունելը։ Եթե պահանջն այն է, որ միայն ձեր հավելվածի տրաֆիկն օգտագործի թունելը, կառավարման ալիքով խնդրեք յուրաքանչյուր հավելվածի VPN, կամ ավարտեք TLS-ը հավելվածի ներսում այնպիսի ծառայության դիմաց, որը հասանելի է առանց դրա։

Թաքնված API-ները արժանի կարճ ճանապարհ չեն։ Դրանք փոխվում են թողարկումների միջև, ձախողվում են հավելվածների ստուգմանը, և դրանց առաջացրած խափանումները կոդը ժառանգողի համար սովորական ցանցային խափանումներ են թվում։ Համեմատությունը Android-ի և iOS-ի միջև չէ, այն թունելին տիրապետելը ընդդեմ հարթակից տրաֆիկի ուղղորդում խնդրելու է, և միայն առաջինն է ձերը կառուցելու։