Android-ում IKEv2 VPN պրոֆիլները օգտվողի համար են, ոչ սարքի

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

Ինչ է հարթակը կառուցում ձեզ համար

Android 11-ից հարթակը VPN-ի տրամադրումը բացում է VpnManager-ի միջոցով։ Հաստատված հավելվածը նկարագրում է IKEv2 պրոֆիլ, և հարթակն ինքն է կատարում IPsec և IKE փոխանակումը, ուստի հավելվածը երբեք չի դիպչում փաթեթներին։ Սա էական տարբերությունն է սեփական VPN հավելվածից, որը իրականացնում է VpnService և թունելը կառուցում է իր գործընթացում։

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

Վերևի կանչը ձևի ուրվագիծ է, ոչ պատճենման բլոկ․ կառուցիչն ունի նույնականացման մի քանի տարբերակ, դրանք տարբերվում են API մակարդակով, և պրոֆիլը կրում է նաև սերվերի վկայագրի վստահության նյութը։ Սեփականության հարցի համար կարևորը շարադրանքից նեղ է։

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

Սեփականատերը օգտվողն է, ապա փաթեթը

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

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

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

Երեք դարպաս՝ մինչև փաթեթի շարժվելը

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

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

Շրջանակը այն տեղն է, որտեղ հանդիպում են երեքը։ Պրոֆիլը որոշում է դարպասը և ինքնությունը, մինչդեռ քաղաքականության շերտը որոշում է, թե որ հավելվածները կարող են օգտագործել թունելը և արդյոք երթևեկությունը հարկադրվում է դրա միջով։ Ուստի նույն դարպասի հասցեով երկու հեռախոս կարող են շատ տարբեր վարվել։

Ինչու անձնական կապը չի ծածկում աշխատանքային հավելվածները

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

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

Ստուգեք իրական գրանցման վրա, ոչ լաբորատոր հեռախոսի

Սարքում նախ պարզեք գրառման սեփականատիրոջը․ որը օգտվող, որը փաթեթ, և արդյոք պրոֆիլը հարթակի տրամադրողից է, թե սեփական VPN ծառայությամբ հավելվածից։ Ապա հաստատեք, որ պրոֆիլի սպասած ինքնությունը իսկապես կա այդ օգտվողի բանալիների պահոցում։

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

Վերջում փորձարկեք հենց աշխատանքային հավելվածը հայտնի ներքին վերջնակետի դեմ և համեմատեք անձնական պրոֆիլի արդյունքի հետ։ Երկուսը կարող են տարբերվել․ չպետք է տարբերվի սեփականության մոդելը։ Եթե թունելը սխալ օգտվողինն է, վկայագրերի վերաթողարկումը ոչինչ չի ուղղի։

Մի՛ ստիպեք հարցը՝ գործարկելով թաքնված կարգավորումների ակտիվություններ ընտրացանկը բացահայտելու համար, և մի՛ պատճենեք մասնավոր բանալիներ պրոֆիլների միջև, որպեսզի կապը երևա։ VpnManager-ի տեղեկատուն նկարագրում է, թե ինչ կարող է տրամադրել կանչողը․ եթե հաստատված ուղին չի ներառում ձեր դեպքը, դա ադմինիստրատորի որոշումն է, ոչ կարգավորումների խնդիր։