Android IKEv2: пайдаланушы сертификаты мен CA түрлі жұмыс атқарады
Бір өріс телефонның кім екенін дәлелдейді, екіншісі қай шлюзге сенуге болатынын шешеді. Android-тағы IKEv2 профилі оларды бөлек ұстайды.
Android-тағы IKEv2 экраны бірден пайдаланушы сертификатын да, CA сертификатын да сұрағанда, бір нәрсені екі рет сұрап тұрғандай көрінеді. Бірақ олай емес. IKEv2 бір алмасу ішінде екі тарапты екі бағытта да растайды, ал телефон әр бағытта басқа рөл атқарады: кім екенін дәлелдеуі және қай шлюзге сенетінін шешуі керек. Пайдаланушы сертификаты бірінші сұраққа, сенімді CA екіншісіне жауап береді, және ешқайсысы екіншісінің орнын баспайды.
Бір алмасудағы растаудың екі бағыты
IKEv2 басқару арнасын екі кезеңде құрады. Біріншісі алгоритмдер мен кілттерді келіседі; екіншісі, IKE_AUTH, әр тараптан бір AUTH жүктемесін өз сәйкестігімен бірге жеткізеді. Жүктеме алмасу үстінде жасалған қолтаңба немесе MAC болып табылады және қабылдаушы бұрыннан сенетін нәрсемен салыстырылып тексеріледі.
Шлюз өзін өз сертификатымен дәлелдейді, телефон тізбекті өзі қабылдайтын тамырға дейін тексереді және сертификаттағы сәйкестіктің жеткісі келген шлюзге сай екенін қарайды; телефон өзін өз деректерімен дәлелдейді, шлюз оларды клиент сертификатын берген CA-мен тексереді.
Екі өрістің артындағы бүкіл механизм осы. Пайдаланушы сертификаты — телефонның өзі туралы мәлімдемесі; CA өрісі — оның кімге сенетіні туралы мәлімдеме. Біреуі бар, екіншісі жоқ профиль өзара растауды аяқтай алмайды, қайталау оны өзгертпейді. Тіпті қателер де бөлек көрінеді: пайдаланушы кілті болмаса телефон қол қоя алмайды, сенім тірегі болмаса шлюз сертификатын қабылдай алмайды.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Android профиль құрастырушысы нені талап етеді
Android-тағы IKEv2 профиль құрастырушысы әр растау әдісін жеке ұсынады, бір сертификат режимі ретінде емес. Цифрлық қолтаңба әдісі пайдаланушы сертификатын, жеке кілтті және сервердің түбірлік CA-сын алады; қалғандары пайдаланушы аты мен құпиясөзді немесе алдын ала бөлісілген кілтті алады.
Сол қолтаңбаны мұқият оқыңыз, өйткені ол жоғарыдағы механизмді сипаттайды. Пайдаланушы аты мен құпиясөз әдісінде жеке кілт өрісі жоқ, ал PSK әдісінде шлюздің сенім тірегі өрісі жоқ, себебі бұл әдістер басқа нәрселерді дәлелдейді. Сертификат өрісіне қойылған құпиясөз IKE_AUTH кезінде сәтсіздікке ұшырайтын профиль береді, ал хабарлама екеуін де атамайды.
Цифрлық қолтаңба әдісі үшін құжатталған жеке кілт түрі — RSA. IPsec немесе сертификат деп жазылған мәзір ECDSA қолдауын білдірмейді, сол болжамға құрылған профиль желіге жетпей-ақ платформа API-інде сәтсіздікке ұшырайды.
Неге жалғыз ашық сертификат жеткіліксіз
AUTH жүктемесі — клиенттің жеке кілтімен алмасу үстінде жасалған қолтаңба. Ашық сертификат шлюзге қолтаңбаны тексеруге мүмкіндік береді, бірақ телефонға ештеңе бермейді, өйткені ол қолтаңба жасау үшін кілтке мұқтаж. Тек .crt импорттап, кілтті артта қалдыру — бұл қатенің ең көп тараған түрі.
Android кілт инфрақұрылымы соны көрсетеді: клиент сәйкестігін таңдау KeyChain арқылы өтеді, ол тиісті жеке кілтке қол жеткізуді талап етеді, тек сертификат жазбасын емес. Жұпты бірге орнататын тіркеу пакеті немесе құрылғыны басқару ағыны — жарамды сәйкестік алудың қалыпты жолы; файлды қолмен көшіру әдетте олай емес.
Сондықтан профильдегі екі элемент сертификаттар шоғыры мен оның көшірмесі емес. Бірі — платформа қол қоя алуы тиіс кілт жұбы, екіншісі — салыстыратын сенім тірегі. Оларды екі бөлек дерек ретінде тексеріңіз: бұл профиль қол қоя ала ма және кімге сенуді біле ме?
Сенім тіректері қолдандыққа жатады, телефонға емес
Пайдаланушы қоймасына орнатылған түбір әр Android қолданбасын оған сендірмейді: Android 7-ден бастап қолданба оны өзінің желілік қауіпсіздік конфигурациясы арқылы таңдауы керек, ал ол шығарылымға дейін пайдаланушы орнатқан CA әлдеқайда кең қабылданатын. Сенім конфигурациясы әртүрлі болуы мүмкін, ал өз сенім материалын өзі басқаратын VPN клиенті қоймаға мүлде қарамауы мүмкін. Сол себепті бір CA файлы бір клиентте жұмыс істеп, екіншісінде еленбегендей көрінеді.
Осыдан меншіктің екі моделі шығады. Жүйе басқаратын профиль құрылғының сертификат орнатуын немесе әкімші тіркеуін пайдаланып, кейін көзделген CA-ға сілтеме жасайды. Қолданба басқаратын VPN өз сенім материалын және өзінің құжатталған импортын ұстайды, ол Android параметрлері экранынан мүлде бөлек болуы мүмкін. Сынған тізбек те сонда жөнделеді.
Бірдеңе импорттамас бұрын қай модельде екеніңізді шешіңіз, содан кейін белсенді профильдің сенім таңдауын растаңыз. Егер оператор нұсқаулығы мен клиент мәзірі сәйкеспесе, сол орнату үшін клиенттің құжатталған әрекеті жеңеді, бірақ CA бәрібір оператордан сіз тексере алатын арна арқылы келуі керек. Файл атауы оны кім бергенінің дәлелі емес.
Алдымен режим, содан кейін файлдар
Сертификат режиміне клиенттің кілт жұбы, шлюз жағындағы беруші CA, шлюз сертификаты үшін сенім тірегі және сертификат алып жүруі тиіс сәйкестік туралы күту қажет. Пайдаланушы аты мен құпиясөз кілт жұбын деректермен алмастырады, бірақ шлюзге сену талабын сақтайды. PSK екеуін де ортақ құпиямен алмастырады және сенім моделін жеңілдетудің орнына өзгертеді.
Қайсысын таңдасаңыз да, қалыпты тексеруді қосылып қалдырыңыз. Тексерусіз опция CA өрісі қызмет ететін тексеруді алып тастайды; жетіспейтін сенім тірегін жөн демейді. Байланыс онсыз да жұмыс істейді деп кез келген сервер сертификатын қабылдауға да сол қатысты.
Содан кейін дұрыс жерде тексеріңіз: материалды импорттаңыз, бір рет қосылыңыз және байланыс мәліметтерінде шлюз сәйкестігі күткендей екенін, профиль көздеген әдісті хабарлайтынын растаңыз. Қате әдіспен сәтті байланыс — әлі түсінбеген конфигурация, және оператор саясатты қатайтқанда ол сәтсіздікке ұшырайды.