Android 12 жана IKEv1 VPN: жеткирүү версиясы, IKEv2 жана үчүнчү тарап колдонмолору

Эки телефон тең жөндөөлөрдө Android 12 көрсөтөт, бирок алардын бири гана шлюзуңуз сунуштаган эски IPsec XAuth профилин дагы деле иштетет. Айырмачылык колдонуучу жете алган жөндөө эмес: native IKEv1 жолун башкарган күзөтчү түзмөк жеткирилген SDK деңгээлин карайт, азыр иштеп жаткан версияны гана эмес. Ошол бир деталь флотту салыштыруунун мааниси барбы-жокпу аныктайт, жана үч көчүү жолунун кайсынысы сизге чын эле керек экенин да аныктайт.

Эки Android 12 телефон бир сыноо учуру эмес

Жаңы түзмөктөрдүн эски IKEv1 профилдерин иштетүүсүнө жол бербеген AOSP өзгөртүүсү DEVICE_INITIAL_SDK_INT маанисин Android S менен салыштырат, башкача айтканда API 31. Native иштетүү жолунда ылайыктуу профиль пайдалуу байланыш пайда боло электе эле колдоого алынбаган операция катасын пайда кылат. 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ны кайра киргизүү же маршруттарды оңдоо мурун иштеген протокол колдоосун текшерүүнү алып сала албайт, жана ката эсеп жазууларынын көйгөйүнө окшош, бирок андай эмес.

Биринчи жол: native стекти дагы деле иштеген жерде кармоо

Эски стек — системанын 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 колдонмолору өз протокол ишке ашыруусун алып келет жана native стекке такыр көз каранды эмес. Бул аларды тез көчө албаган флот үчүн мыйзамдуу убактылуу чечим кылат, бирок шайкештик суроосу колдонмого өтөт: ал шлюзуңуз сүйлөгөн так IKEv1 режимин шлюз талап кылган аутентификация жана шифр топтомдору менен ишке ашырабы.

Колдонмонун өз колдоо матрицасын бийлик катары кабыл алыңыз, дүкөндүн сүрөттөмөсүн эмес, жана сунуштоодон мурун бир реалдуу түзмөктү реалдуу шлюзга каршы сынаңыз. Жок кылынган платформа жолун калыбына келтирүү үчүн телефонду root кылуу да тейленүүчү чечим эмес; ал көйгөйдү кийинки система жаңыртуусу үнсүз буза ала турган колдоого алынбаган конфигурацияга өткөрөт.

Шлюз эмнени сунуштай аларына жараша тандаңыз

Чечим эки нерсени билгенде тарыйт: кайсы түзмөктөр API 31де же андан кийин чыкканын, жана шлюз ошол эле каттоо модели менен IKEv2 кызматын сунуштай алабы. Эгер сунуштай алса, көчүңүз жана эски профилге инвестиция салууну токтотуңуз. Эгер али албаса, аны дагы деле иштеткен түзмөктөр үчүн IKEv1 кармаңыз, ал эми жаңы түзмөктөргө үчүнчү тараптын кардарын документтелген, убакыт менен чектелген өзгөчөлүк катары бериңиз, айтылбаган айланып өтүү жолу катары эмес.

Эки нерсе планды коргоого боло турган кылат. Биринчиден, ар бир өзгөчөлүктүн себебин модель жана жеткирүү деңгээли менен жазып алыңыз, аудитор чек ара түшүндүрүлбөгөн тандоо эмес, платформа күзөтчүсү экенин көрсүн. Экинчиден, көчүүнү пландалган иш катары караңыз: IKEv1 стандарттар жолунда эскирген (RFC 9395), бул калган түзмөктөрдүн азая берерин жана өзгөчөлүктөрдүн алар менен бирге бүтүшү керектигин билдирет.