Ինչպես ներմուծել VPN վկայագիր Android-ում և ստուգել բանալին

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

Քայլ 1՝ կարդացեք P12-ը, նախքան այն կլքի ձեր մեքենան

Սկսեք հենց ֆայլից։ Եթե չեք կարող անվանել դրա ներսում եղած սուբյեկտը, թողարկողին և ժամկետը, դուք ներմուծում եք մի բան, որը հետագայում չեք կարողանա ստուգել։

PKCS#12 փաթեթը սովորաբար կրում է հաճախորդի վկայագիր, նրա մասնավոր բանալին և թողարկողի շղթան։ openssl pkcs12 -in client.p12 -info -noout տպում է MAC-ը և գաղտնագրման ալգորիթմները՝ առանց բանալու նյութը թափելու, այնպես որ տեսնում եք՝ փաթեթը պաշտպանվա՞ծ է գաղտնաբառով և ինչ գաղտնագրով։ Դրանից հետո գործարկեք keytool -list -v -keystore client.p12 -storetype PKCS12-ը՝ կեղծանունը, SHA-256 մատնահետքը և հեռախոսի հետ համեմատելի վավերականության պատուհանը ստանալու համար։

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

Քայլ 2՝ տեղադրեք այն բնիկում, որը VPN հավելվածը իրականում կարդում է

Ստանդարտ Android 11-ից 14-ում ուղին անցնում է Կարգավորումներ, Անվտանգություն, Գաղտնագրում և հավատարմագրեր, Տեղադրել վկայագիր, ապա VPN և հավելվածի օգտագործողի վկայագիր։ Ձևակերպումը և ներդնումը փոխվում են թողարկումների և արտադրողների կեղևների միջև, այնպես որ հետևեք հավատարմագրի տեսակի պիտակին, ոչ թե անգիր արված ընտրացանկի դիրքին։ Աշխատանքային պրոֆիլում տեղադրեք աշխատանքային կողմի ներսից, որովհետև հավատարմագրերը չեն անցնում պրոֆիլի սահմանը։

Մի դրեք հաճախորդի ինքնությունը CA վկայագրի բնիկում։ Այդ բնիկը սնուցում է օգտագործողի վստահության պահոցը, և Android 7-ից ի վեր հավելվածները անտեսում են օգտագործողի ավելացրած CA-ները, եթե նրանց ցանցային անվտանգության կոնֆիգուրացիան չի թույլատրում, ուստի այնտեղ թողնված հաճախորդի վկայագիրը երբեք չի հայտնվում VPN բանալիների ընտրիչում։

Որոշ VPN հաճախորդներ երբեք չեն դիպչում համակարգի պահոցին և փոխարենը P12-ը ներմուծում են իրենց սեփական հավելվածի պանակ։ Դա օրինական ձևավորում է, բայց փոխում է յուրաքանչյուր հաջորդ քայլը. բանալին այժմ ապրում է հավելվածի ավազարկղի տակ և ուղիղ այնքան ամուր է, որքան այդ հավելվածը վարում է իր սեփական պահոցը։ Ստուգեք հաճախորդի փաստաթղթերը, նախքան ենթադրելը, որ KeyChain-ը խաղի մեջ է։

Քայլ 3՝ ապացուցեք, թե որ մատակարարն է պահում բանալին

Ներմուծումը հաստատում է վերլուծությունը, ոչ թե ապարատային աջակցությունը։ Android 12-ից սկսած՝ KeyInfo.getSecurityLevel()-ը հաղորդում է՝ բանալին գտնվում է Վստահելի կատարման միջավայրում, StrongBox-ում, թե ծրագրային ապահովման մեջ, և այն փոխարինում է ավելի հին isInsideSecureHardware() կանչին։ Եթե VPN հաճախորդը չի ցուցադրում այդ արժեքը, 1-ին քայլի մատնահետքը ձեր պահուստն է։ Ներմուծման ընթացքում վերակոդավորված վկայագիրը չի համապատասխանի բայթ առ բայթ, բայց հանրային բանալին և սուբյեկտը դեռ կհամապատասխանեն։

Չարտահանվողը նույնը չէ, ինչ անօգտագործելին։ Բանալին, որը չի կարող լքել սարքը, դեռ կարող է օգտագործել ցանկացած հավելված, որին օգտագործողը լիազորում է ընտրել այդ կեղծանունը, և դրա համար է, որ կեղծանվան հուշումը իրական վերահսկողություն է, ոչ թե ձևականություն։ Android Keystore-ի փաստաթղթերը արժե մեկ անգամ կարդալ, եթե այդ ձևավորման որոշումն եք կայացնում։

Ապա հաշվի առեք արված պատճենները։ Ձեր նոութբուքի P12-ը, տոմսի կցորդի և անցած ամսվա պահուստային պատճենի վրա եղածները բոլորն էլ վավեր ինքնություններ են, մինչև թողարկողը չեղարկի դրանք։ Հեռախոսի օրինակի ապարատային պաշտպանությունը ոչինչ չի անում դրանց համար։

Քայլ 4՝ պարզեք, թե ում է պատկանում էկրանի կողպեքի պահանջը

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

Երբ սարքի ադմինիստրատորը կամ կառավարվող պրոֆիլի քաղաքականությունը պահանջում է կողպեք, պահանջը պատկանում է այդ քաղաքականությանը, ոչ թե վկայագրին։ adb shell dumpsys device_policy-ը թվարկում է ակտիվ ադմինիստրատորներին և նրանց պարտադրած գաղտնաբառի որակը, ինչը ամենաարագ ձևն է տեսնելու՝ MDM գործակալն է ձեր PIN կանոնների փոփոխության պատճառը, թե ոչ։ Վկայագրի հեռացումը չի թուլացնի քաղաքականությունը, իսկ քաղաքականության հեռացումը վարչական որոշում է, ոչ թե կարգավորման շտկում։

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

Խուսափեք locksettings.db-ը խմբագրելու կամ մոռացված նախշի հին շրջանցումը կրկին նվագելու կարճ ուղուց։ Այդ ռուտինները գրվել են կոնկրետ բիլդերի համար, նրանք կարող են հավատարմագրերի պահոցը թողնել մի վիճակում, որը շրջանակն այլևս չի սպասում, և նրանք երբեք չեն փոխում այն քաղաքականությունը, որը կողպեքը սկզբում պահանջել էր։

Քայլ 5՝ հանեք ինքնությունը և ստուգեք մերժումը

Հանումը երեք մաս ունի, և միայն առաջինն է տեղական։ Հեռացրեք VPN պրոֆիլը, ջնջեք օգտագործողի վկայագիրը Կարգավորումներ, Անվտանգություն, Գաղտնագրում և հավատարմագրեր, Օգտագործողի հավատարմագրեր բաժնից, ապա թողարկողից պահանջեք չեղարկել վկայագրի սերիական համարը։ Միայն տեղական ջնջումը թողնում է հավատարմագիր, որը սերվերը դեռ ընդունում է, եթե ինչ-որ մեկը պահել է P12-ը։

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

Եթե հետ եք գլորում ձախողված ներմուծումը, նորից ներմուծեք բնօրինակ գաղտնագրված փաթեթից և նորից ստուգեք մատնահետքը՝ սկավառակի վրա թողած վերծանված բանալու ֆայլը նորից օգտագործելու փոխարեն։