Android IKEv2 экраны бир убакта колдонуучу сертификатын жана CA сертификатын сураганда, бир эле нерсени эки жолу сурап жаткандай көрүнөт. Бирок андай эмес. IKEv2 бир алмашуунун ичинде эки тарапты эки багытта текшерет, телефон ар бир багытта башка ролду ойнойт: ким экенин далилдеп, кайсы дарбазага ишенерин чечиши керек. Колдонуучунун сертификаты биринчи суроого, ишенимдүү CA экинчисине жооп берет, жана экөө бири-бирин алмаштырбайт.

Бир алмашуудагы текшерүүнүн эки багыты

IKEv2 башкаруу каналын эки баскычта курат. Биринчиси алгоритмдер менен ачкычтарды сүйлөшөт; экинчиси, IKE_AUTH, ар бир тараптан бир AUTH жүгүн анын идентификациясы менен алып жүрөт. Жүк алмашуунун үстүндө жасалган кол тамга же MAC болуп саналат жана кабыл алуучу мурун ишенген нерсе менен салыштырылып текшерилет.

Дарбаза өзүн өз сертификаты менен далилдейт, телефон тизмекти өзү кабыл алган тамырга чейин текшерип, сертификаттагы идентификация жетүүнү көздөгөн дарбазага туура келерин карайт; телефон өзүн өз маалыматтары менен далилдейт, дарбаза аларды кардар сертификатын берген CA менен текшерет.

Эки талаанын артындагы бүт механизм ушул. Колдонуучунун сертификаты — телефондун өзү жөнүндөгү билдирүүсү; CA талаасы — кимге ишенери тууралуу билдирүү. Бирөө бар, экинчиси жок профиль өз ара текшерүүнү бүтүрө албайт, кайталоо аны өзгөртпөйт. Жада калса каталар башкача көрүнөт: колдонуучунун ачкычы жок болсо телефон кол тамга баса албайт, ишеним тиреги жок болсо дарбазанын сертификатын кабыл албайт.

MaterialRoleWhat it cannot do
User certificate plus its private keyProves possession of the enrolled client identityEstablish that the gateway is the right one
Trusted CA certificateValidates the gateway chain under the intended identity checksProve the client's identity to the gateway
Expected gateway identityPins which server the phone acceptsGrant 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 талаасы кызмат кылган текшерүүнү алып салат; жетишпеген ишеним тирегин оңдобойт. Байланыш анысыз иштегендиктен каалаган сервер сертификатын кабыл алууга да ушул эле тиешелүү.

Анан туура жерде текшериңиз: материалды импорттоп, бир жолу туташып, байланыш деталдарында дарбазанын идентификациясы күткөндөй экенин жана профиль көздөгөн ыкманы билдирип жатканын ырастаңыз. Туура эмес ыкма менен ийгиликтүү байланыш — сиз али түшүнбөгөн конфигурация, жана оператор саясатты катаалдатканда ал ийгиликсиз болот.

Тектеш макалалар