Android 12 va IKEv1 VPN: chiqarilgan versiya, IKEv2, uchinchi tomon ilovalari

Ikkala telefon ham Sozlamalarda Android 12 ni ko'rsatadi, ammo faqat bittasi shlyuzingiz taklif qiladigan eski IPsec XAuth profilini hali ham ishga tushiradi. Farq foydalanuvchi yeta oladigan sozlama emas: o'rnatilgan eski IKEv1 yo'lini to'sadigan himoya qurilma qaysi SDK darajasi bilan chiqarilganiga qaraydi, faqat hozir ishlayotgan versiyasiga emas. Shu bitta tafsilot flotni solishtirish mantiqiy yoki yo'qligini hal qiladi va uchta migratsiya yo'lidan qaysi biri sizga haqiqatan kerakligini ham hal qiladi.

Ikkita Android 12 telefon bir xil sinov holati emas

Yangi qurilmalarning eski IKEv1 profillarini ishga tushirishini to'xtatgan AOSP o'zgarishi DEVICE_INITIAL_SDK_INT ni Android S bilan solishtiradi, ya'ni API 31. O'rnatilgan eski ishga tushirish yo'lida mos profil har qanday foydali ulanish yuzaga kelishidan oldin qo'llab-quvvatlanmaydigan operatsiya xatosini keltirib chiqaradi. Android 11 bilan kelgan va keyinroq yangilangan telefon bu himoyadan hali ham o'tadi; Android 12 bilan chiqarilgan model o'tmaydi.

Ikkala raqamni disk raskadrovka yoqilgan qurilmada o'qish mumkin:

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

Birinchi qiymat himoya uchun muhim bo'lgan chiqarilish darajasi, ikkinchisi telefon bugun ishlatayotgan narsa. Xususiyat yo'q joyda marketing nomidan taxmin qilish o'rniga modelning qo'llab-quvvatlash hujjatlariga tayaning va ishlab chiqaruvchi build asosiy versiyadagi har bir moslik yo'lini saqlaydi deb o'ylamang.

Yana bir farq bir soat behuda ketgan qo'llab-quvvatlash vaqtini tejaydi: VPN sozlamalarida hali ham ro'yxatda turgan saqlangan profil platforma uni ishga tushiradimi-yo'qmi degani haqida hech narsani isbotlamaydi. PSK ni qayta kiritish yoki marshrutlarni tahrirlash avvalroq ishlaydigan protokol qo'llab-quvvatlash tekshiruvini olib tashlay olmaydi va xato aslida bo'lmaganda ham hisob ma'lumotlari muammosiga o'xshaydi.

Birinchi yo'l: o'rnatilgan eski stekni hali ishlaydigan joyda saqlang

Eski stek tizim VPN ekranidan IPsec XAuth PSK, IPsec Hybrid RSA va L2TP/IPsec PSK profillarini o'qiydigan stekdir. API 31 dan pastda chiqarilgan qurilmada yangilanishdan keyin ham u amaliy yo'l bo'lib qoladi, shuning uchun eski apparatdagi sinov muvaffaqiyatli bo'lishi mumkin, yangi apparat esa xuddi shu profilni rad etadi.

Muhim taqqoslash Android versiyasi bo'yicha emas, qurilma sinfi bo'yicha: flotdagi modellarni sanab chiqing, ularning chiqarilish API darajalarini o'qing va ularni profilni hali ishga tushiradigan qurilmalar hamda tushirolmaydigan qurilmalarga ajrating. Boshqa har qanday narsa foydalanuvchi yangi telefon sotib olgan paytda o'ziga zid bo'ladigan qo'llab-quvvatlash siyosatini keltirib chiqaradi.

Ikkinchi yo'l: platforma IKEv2 profillari

Android ning IKEv2 uchun ommaviy ta'minlash modeli boshqa obyekt, qayta nomlangan IKEv1 profili emas. IKEv2 profillari uchun platforma API si API 30 bilan keldi va shlyuz taklif qiladigan autentifikatsiya usuli bilan IKEv2 ni kutadi, odatda sertifikatga asoslangan yoki EAP. IKEv1 XAuth yoki Hybrid dan IKEv2 ga sim bo'yicha mos yangilanish yo'q: shlyuz yangi protokol uchun sozlanishi kerak, profil esa mos identifikatsiyani olib yurishi kerak.

Bu eng uzoq umrli yo'l va ayni paytda haqiqiy ishni ochib beradigan yo'l. Identifikatsiyani tekshirish, foydalanuvchi autentifikatsiyasi, DNS, bo'lingan tunnel marshrutlari va resurslarni avtorizatsiya qilish barchasi migratsiyadan o'tishi kerak; faqat qo'l berib ko'rishish muvaffaqiyatli bo'lsa, foydalanuvchilar hech qayerga yetmaydigan tunnelga ulangan holda qoladi.

Joylashtirish odatda MDM yoki boshqariladigan konfiguratsiya orqali boradi, foydalanuvchi maydonlarni yozishi bilan emas. Agar bu infratuzilma hali bo'lmasa, migratsiya rejasi uni o'z ichiga olishi kerak, chunki har bir qurilmada IKEv2 profilini qo'lda qayta kiritish yordam stoli ko'tara oladigan operatsiya emas.

Uchinchi yo'l: uchinchi tomon mijoz ilovasi

Ba'zi VPN ilovalari o'z protokol amalga oshirilishini olib keladi va o'rnatilgan eski stekka umuman bog'liq emas. Bu ularni tez migratsiya qila olmaydigan flot uchun qonuniy vaqtinchalik yechimga aylantiradi, lekin moslik savoli ilovaga o'tadi: u shlyuzingiz gapiradigan aynan o'sha IKEv1 rejimini, shlyuz talab qiladigan autentifikatsiya va shifr to'plamlari bilan amalga oshiradimi.

Do'kon tavsifidan ko'ra ilovaning o'z qo'llab-quvvatlash matritsasini vakolat deb hisoblang va tavsiya qilishdan oldin bitta haqiqiy qurilmani haqiqiy shlyuz bilan sinab ko'ring. Olib tashlangan platforma yo'lini tiklash uchun telefonni root qilish ham barqaror yechim emas; u muammoni keyingi tizim yangilanishi jimgina buzishi mumkin bo'lgan qo'llab-quvvatlanmaydigan konfiguratsiyaga ko'chiradi.

Shlyuz nima taklif qila olishiga qarab tanlang

Qaror ikki narsani bilganingizda torayadi: qaysi qurilmalar API 31 yoki undan keyin chiqarilgan va shlyuz xuddi shu ro'yxatga olish modeli bilan IKEv2 xizmatini taqdim qila oladimi. Qila olsa, migratsiya qiling va eski profilga sarmoya kiritishni to'xtating. Hali qila olmasa, uni hali ishga tushiradigan qurilmalar uchun IKEv1 ni saqlang va yangi qurilmalarga uchinchi tomon mijozini hujjatlashtirilgan, muddatli istisno sifatida bering, aytilmagan yechim sifatida emas.

Ikki jihat rejani himoya qilinadigan qiladi. Birinchidan, har bir istisnoning sababini model va chiqarilish darajasi bilan yozib qo'ying, shunda auditor chegara tushuntirilmagan afzallik emas, platforma himoyasi ekanini ko'radi. Ikkinchidan, migratsiyani rejalashtirilgan ish deb biling: IKEv1 standartlar yo'nalishida eskirgan (RFC 9395), ya'ni qolgan qurilmalar kamayishda davom etadi va istisnolar ular bilan birga tugashi kerak.