Android VPN արտահանում. ինչ է իրականում փոխանցվում նոր հեռախոսին

Android-ից VPN պրոֆիլի արտահանումը թվում է պահուստավորման քայլ, և այն մենյուն, որն առաջարկում է դա, ոչինչ չի անում այդ տպավորությունը շտկելու համար։ Ձեզ մոտ մնում է parser-ի մուտք, բանալի, որը օպերացիոն համակարգը գուցե երբեք չվերադարձնի, և լիազորում, որը տրվել է հենց այդ հեռախոսին։ Բաժանեք այս երեքը, և առաջանում է օգտակար հարցը՝ ո՞ր մասն է դեռ բացակայում նոր սարքում։

Ֆայլը հեշտ մասն է։ Մյուս երկուսը որոշում են՝ կաշխատի արդյոք միգրացիան։

Ինչ է իրականում պարունակում արտահանված պրոֆիլը

Բացեք ֆայլը տեքստային խմբագրիչում նախքան վստահելը։ OpenVPN պրոֆիլը փոքր կոնֆիգուրացիոն լեզու է՝ remote, proto, data-ciphers, և հաճախ ներկառուցված <ca>, <cert>, <key> կամ <tls-crypt> բլոկներ, որոնք հաճախորդը տալիս է իր TLS կույտին։ WireGuard կարգավորումն ավելի հարթ է՝ [Interface]-ը պարունակում է PrivateKey և Address, ապա մեկ [Peer] յուրաքանչյուր վերջնակետի համար՝ PublicKey, AllowedIPs և Endpoint-ով։ IKEv2-ը գալիս է որպես .mobileconfig՝ բանալու բլոկների փոխարեն օգտակար բեռի բառարաններով։

Այդ տեքստերից ոչ մեկն ինքնին վկայական չէ։ Վկայականը մասնավոր բանալին է, և յուրաքանչյուր ձևաչափ կամ կպցնում է այն ներսում, կամ մատնանշում է կեղծանուն, որը լուծվում է միայն այն հաճախորդի ներսում, որը ստեղծել է այն։

Որտեղ է բանալին իրականում ապրում Android-ում

Android-ը պահում է հավելվածի տվյալները /data/data/<package>-ի տակ, որոնք կարդում է միայն այդ հավելվածի UID-ն։ Root չարված հեռախոսից այլ հավելվածի մասնավոր պանակը պատճենելու աջակցվող եղանակ չկա, և adb backup-ը դադարել է ընդհանուր պատասխան լինելուց այն բանից հետո, երբ Android 12-ը չեղարկեց այն, և հաճախորդները սկսեցին հայտարարել allowBackup="false"։ Այսպիսով, Android հաճախորդից արտահանումը նշանակում է այն, ինչ այդ հաճախորդն իրականացնում է, ոչ թե ֆայլային համակարգի պատճեն։

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

Սա կոտրված արտահանում չէ։ Սա այն հատկությունն է, որ խնդրել են հարթակից ապահովել։

Ինչ պրոֆիլը չի կարող տեղափոխել

Համեմատեք օբյեկտները այն բանի հետ, ինչ նպատակակետը կընդունի՝

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

Ներմուծումը վերլուծություն է, ապա համաձայնության հարցում

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

Ապա գալիս է լիազորման քայլ, որը ոչ մի ֆայլ չի կարող բաց թողնել։ Android-ը պահանջում է, որ հավելվածը կանչի VpnService.prepare() և ստանա ձեր համաձայնությունը նախքան թունել հաստատելը, ուստի նոր ներմուծված պրոֆիլը դեռ մեկ անգամ ցույց է տալիս համակարգի երկխոսությունը։ Այնուհետև թունելը հստակ կառուցվում է addAddress, addRoute, addDnsServer և addAllowedApplication կամ addDisallowedApplication-ով՝ յուրաքանչյուր հավելվածի երթուղավորման համար։ Դրանցից ոչ մեկը չի բխում վերջնակետից, ուստի նույն պրոֆիլը կարող է տարբեր արդյունավետ երթուղիներ ստեղծել երկու հաճախորդներում։

Վկայագրերի վրա հիմնված կարգավորումները ավելացնում են ևս մեկ ճյուղավորում։ Երբ սերվերը վկայագիր է տալիս կոնկրետ սարքի, ինչպես անում են MDM-ը և SCEP գրանցումը, դրա վերաօգտագործումը երկրորդ հեռախոսում կամ աշխատում է այնքան ժամանակ, մինչև սերվերը պարտադրի մեկ սեսիա յուրաքանչյուր ինքնության համար, կամ ձախողվում է TLS ձեռքսեղմման ժամանակ։ Ստուգեք թողարկողի քաղաքականությունը նախքան վերաօգտագործում պլանավորելը։

Ստուգեք նոր սարքը նախքան հինը թոշակի ուղարկելը

Թողեք հին հեռախոսը միացված, մինչև նորը անցնի կանաչ պատկերակից ավելի լավ բան։ Հաստատեք ելքի հասցեն նոր սարքից և DNS լուծիչը, որն այն իրականում օգտագործել է։ Եթե split tunneling-ը կարևոր է, գործարկեք հավելված, որը պետք է շրջանցի թունելը, և մեկը, որը չպետք է, ապա տեսեք, թե որն է հասնում ձեր ծառայության մատակարարին։

Մեկ ստուգում որոշում է ելքի հասցեն։ Բացեք https://ifconfig.me-ը հեռախոսի դիտարկիչում, ապա գործարկեք curl -s https://ifconfig.me-ը նույն Wi-Fi-ում գտնվող նոթբուքից և համեմատեք երկու պատասխանները ձեր մատակարարի հատկացրած հասցեի հետ։

Միայն այն ժամանակ թոշակի ուղարկեք հին ինքնությունը, և արեք դա թողարկողի միջոցով. չեղարկեք վկայագիրը կամ հեռացրեք սարքը հաշվից։ Ներբեռնումներից ֆայլ ջնջելը ոչինչ չի ավարտում, քանի որ նույն վկայագիր կրող երկու սարք սերվերի մատյանում նույնական են երևում։

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

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