Android 12 և IKEv1 VPN․ թողարկման տարբերակ, IKEv2 և երրորդ կողմի հավելվածներ

Երկու հեռախոսներն էլ Կարգավորումներում ցույց են տալիս Android 12, և դրանցից միայն մեկն է դեռ գործարկում ձեր դարպասի առաջարկած հին IPsec XAuth պրոֆիլը։ Տարբերությունը կարգավորում չէ, որին օգտատերը կհասնի․ պահակը, որը կառավարում է ներկառուցված IKEv1 ուղին, նայում է SDK մակարդակին, որով սարքը մատակարարվել է, ոչ միայն հիմա աշխատող տարբերակին։ Այդ մեկ մանրամասն է որոշում՝ իմաստ ունի՞ պարկի համեմատությունը, և նաև որոշում է, թե միգրացիայի երեք ուղիներից որն է ձեզ իրոք պետք։

Երկու Android 12 հեռախոս նույն փորձարկման դեպքը չեն

AOSP-ի փոփոխությունը, որը թույլ չտվեց նոր սարքերին գործարկել հին IKEv1 պրոֆիլներ, համեմատում է DEVICE_INITIAL_SDK_INT-ը Android S-ի հետ, այսինքն՝ API 31։ Ներկառուցված մեկնարկային ուղում համապատասխան պրոֆիլը առաջացնում է չաջակցվող գործողության սխալ նախքան որևէ օգտակար կապի առաջանալը։ Android 11-ով մատակարարված և ավելի ուշ թարմացված հեռախոսը դեռ անցնում է այդ պահակով, Android 12-ով թողարկված մոդելը՝ ոչ։

Երկու թիվը կարող եք կարդալ վրիպազերծումը միացված սարքում․

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

Առաջին ուղի․ պահել ներկառուցված կույտը այնտեղ, որտեղ դեռ աշխատում է

Հին կույտը այն է, որը համակարգի VPN էկրանից կարդում է IPsec XAuth PSK, IPsec Hybrid RSA և L2TP/IPsec PSK պրոֆիլները։ API 31-ից ցածր մատակարարված սարքում թարմացումից հետո այն մնում է աշխատունակ ուղի, դրա համար հին հեռախոսի փորձարկումը կարող է հաջողվել, մինչ նոր հեռախոսը չի գործարկում նույն պրոֆիլը։

Կարևոր համեմատությունը սարքի դասով է, ոչ Android տարբերակով․ թվարկեք պարկի մոդելները, կարդացեք դրանց մեկնարկային API մակարդակները և բաժանեք սարքերի, որոնք դեռ գործարկում են պրոֆիլը, և նրանց, որոնք չեն կարող։ Ցանկացած այլ մոտեցում ստեղծում է աջակցության քաղաքականություն, որը հակասում է ինքն իրեն այն պահին, երբ օգտատերը նոր հեռախոս է գնում։

Երկրորդ ուղի․ հարթակի IKEv2 պրոֆիլները

Android-ի հանրային IKEv2 մատակարարման մոդելը այլ օբյեկտ է, ոչ վերանվանված IKEv1 պրոֆիլ։ IKEv2 պրոֆիլների հարթակի API-ն եկավ API 30-ի հետ և սպասում է IKEv2 դարպասի առաջարկած նույնականացման եղանակով, սովորաբար վկայագրի հիմքով կամ EAP։ IKEv1 XAuth-ից կամ Hybrid-ից IKEv2 լարով համատեղելի թարմացում չկա․ դարպասը պետք է կարգավորվի նոր արձանագրության համար, և պրոֆիլը պետք է կրի համապատասխան ինքնությունը։

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

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

Երրորդ ուղի․ երրորդ կողմի հաճախորդային հավելված

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

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

Ընտրեք՝ ելնելով նրանից, ինչ դարպասը կարող է առաջարկել

Որոշումը նեղանում է, երբ գիտեք երկու բան․ որ սարքերն են թողարկվել API 31-ով կամ ավելի ուշ, և արդյո՞ք դարպասը կարող է առաջարկել IKEv2 ծառայություն նույն գրանցման մոդելով։ Եթե կարող է, միգրացվեք և դադարեցրեք ներդրումները հին պրոֆիլում։ Եթե դեռ չի կարող, պահեք IKEv1-ը այն սարքերի համար, որոնք դեռ գործարկում են այն, և նոր սարքերին տվեք երրորդ կողմի հաճախորդ՝ որպես փաստաթղթավորված, ժամանակով սահմանափակ բացառություն, ոչ որպես չհայտարարված շրջանցում։

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