iPhone'da IKEv2 sertifikatini sozlash: qo'lda yoki boshqariladigan ro'yxatga olish

RSA'ni faqat shlyuzning sertifikat vositasi uni standart sifatida ishlatgani uchun tanlash muhim savoldan oldin qabul qilingan qaror: bu iPhone'lar qanday ro'yxatga olinadi? Foydalanuvchi o'zi kiritgan ulanish va boshqaruv taqdim etgan konfiguratsiya profili turli sozlamalarni ko'rsatadi, ba'zi sertifikat tanlovlari esa ushbu ikki yo'ldan faqat birida mavjud. Tartibni to'g'ri tuzsangiz, sertifikat rejasi qisqa bo'ladi; xato qilsangiz, telefon ishlatmaydigan hisob ma'lumotlarini berasiz. Quyidagi qadamlarni ketma-ketlik deb qarang, chunki har biri keyingisi uchun mavjud tanlovlarni toraytiradi.

Birinchi qadam: ro'yxatga olish yo'lini tanlang

Qo'lda sozlash foydalanuvchi server manzilini kiritib, autentifikatsiya usulini tanlab, interfeys ruxsat bergan har qanday hisob ma'lumotlarini taqdim etishini bildiradi. Boshqariladigan ro'yxatga olish profil manzil, identifikatorlar va hisob ma'lumotlari yuklamasiga havolani olib yurishini bildiradi. Boshqariladigan yo'l qo'lda ekran ko'rsata olmaydigan birikmalarni ifodalay oladi, shuning uchun sertifikat qarori bu tanlovdan keyin kelishi kerak, oldin emas.

Ikki yo'l ham telefonni autentifikatsiya qila oladi. Ular nima sozlash mumkinligi va identifikator kimga tegishli ekanligi bilan farqlanadi, shuning uchun boshqariladigan profilni qo'lda hisob ma'lumotlari kiritish bilan aralashtirish o'rniga bittasini ataylab tanlang.

Ikkinchi qadam: tanlagan yo'lingiz uchun algoritmlarni tanlang

Qo'lda sozlangan iPhone'lar uchun strongSwan'ning iOS hamkorlik qaydlari RSA server sertifikatini tavsiya qiladi, chunki qo'lda mijoz ECDSA server sertifikatini qabul qilmasligi mumkin; o'sha qaydlar macOS'ni alohida ko'rib chiqadi. Buni qo'llab-quvvatlanadigan mijozlar to'plami uchun ko'rsatma deb o'qing, Apple qurilmalari haqidagi abadiy qonun deb emas. Boshqariladigan profilda ko'proq joy bor: yuklama va shlyuz ikkalasi qo'llab-quvvatlasa, u ECDSA mijoz identifikatorini ham o'z ichiga olgan sertifikat turini aniq tanlashi mumkin.

Biror narsani joylashtirishdan oldin siz haqiqatan qo'llab-quvvatlaydigan iOS versiyalarini tekshiring. Eng yangi versiyadagi laboratoriya telefoni eski qurilmalarni o'z ichiga olgan parkni tasvirlamaydi, laboratoriyada ishlaydigan algoritm esa daladagi eng eski telefonda baribir ishlamasligi mumkin. Versiya oralig'ini xotiradan emas, qurilmalar boshqaruvidan oling. Agar park bir nechta versiyani qamrasa, avval eng eskisini sinab ko'ring, chunki qo'lda interfeys eng ko'p aynan shu yerda cheklangan.

Uchinchi qadam: profil maydonlarini alohida narsalar deb o'qing

Bir xil nomdagi bir nechta kalit turli obyektlarni tavsiflaydi. Uzoq manzil telefon qo'ng'iroq qiladigan xost. Uzoq identifikator shlyuz taqdim etishi kutilayotgan IKE identifikatori. Yuklamadagi sertifikat havolasi mijoz hisob ma'lumotlariga ishora qiladi, sertifikat turi maydoni esa IKEv2 mashina autentifikatsiyasi uchun ishlatiladigan turni tanlaydi. So'zlar bir-biriga o'xshash bo'lsa ham, ularning hech biri CA imzo algoritmi emas.

Apple'ning IKEv2 yuklama havolasi RSA'ni aniq ECDSA turlari bilan standart sertifikat turi sifatida sanab o'tadi va emitent nomi kalitini muayyan autentifikatsiya sozlamalariga bog'laydi. Bu munosabatlarni ishlayotgan joylashtirishdan bitta kalit nusxalash o'rniga tanlagan usulingiz hujjatida o'qing.

To'rtinchi qadam: shlyuz identifikatorini sertifikatiga moslang

Aniq shlyuz nomidan foydalaning, masalan vpn.example.com va server sertifikatiga mos keladigan muqobil subyekt nomini qo'ying. strongSwan'ning Apple yo'riqnomasi server autentifikatsiyasi uchun kengaytirilgan kalit ishlatilishini ham kutadi. RSA yoki ECDSA tanlash bundan hech narsani o'zgartirmaydi: algoritm nom mos kelmasligini, yo'q EKU'ni yoki to'liq bo'lmagan zanjirni tuzata olmaydi.

Ishonch ankerini tarqatish identifikatorni tasdiqlashdan alohida vazifa. Telefonga u tekshira oladigan sertifikatlar zanjiri kerak va u sertifikatga haqiqatan qo'ygan nomni kutishga sozlangan bo'lishi kerak.

Boshqa platforma muvaffaqiyatli ulanishi o'sha platforma tekshiruv qoidalari haqidagi dalil, telefon qoidalarini yumshatishga ruxsat emas. Farqlash uchun hujjatlashtirilgan sabab bo'lmasa, tekshiruvlarni mijozlar orasida bir xil saqlang.

Beshinchi qadam: mijoz identifikatorini CA ishonchidan ajrating

Mijoz sertifikati va uning maxfiy kaliti telefon ishonadigan CA sertifikati bilan bir xil obyekt emas. CA sertifikatini PKCS#12 identifikatori ichiga joylash uni har bir qo'llab-quvvatlanadigan qurilmada avtomatik ishonch ankeri sifatida o'rnatmaydi, shuning uchun ishonch tarqatishni o'z tekshiruviga ega alohida qadam deb biling.

Agar dizayn buning o'rniga parolga asoslangan EAP ishlatsa, telefonga ko'zda tutilgan hisob autentifikatsiyasi va server tekshiruvi kerak. Bu yo'l butun parkka bitta umumiy mijoz maxfiy kalitini yuborishni oqlamaydi, bu boshqa dizayn va ancha yomon ishlamay qolish rejimiga ega.

Rejani yangilash va bekor qilishni hisobga olib yakunlang: mijoz hisob ma'lumotlarini kim qayta beradi, profil qanday yangilanadi va yo'qolgan telefon qanday uziladi. Siz tekshirgan profil versiyasi va qurilma versiyalarini yozib qo'ying, chunki aynan o'sha yozuv keyingi sertifikat almashtirishni odatiy ishga aylantiradi.