IKEv1 ning gibrid autentifikatsiyasi IKEv2 foydalanuvchi autentifikatsiyasiga qanday o'tadi
Gibrid rejim shlyuz isbotini foydalanuvchi isbotidan ajratgan. IKEv2 ga o'tish bu ajratishni saqlaydi, lekin almashinuv, EAP usuli va sertifikat tekshiruvlarini o'zgartiradi.
Avval server sertifikatini, keyin foydalanuvchi nomini so'raydigan har bir eski VPN profili bitta almashinuvda ikkita autentifikatsiya hodisasini olib yuradi va bu shakl uni kiritgan protokoldan uzoqroq yashaydi. IKEv1 ning gibrid rejimi aynan shu uchun qurilgan: shlyuz o'zini ochiq kalit bilan isbotlaydi, foydalanuvchi esa keyinroq XAuth orqali o'zini isbotlaydi. IKEv2 xuddi shu ikki bosqichli g'oyani boshqa mexanizm bilan ifodalaydi va migratsiyalar aynan shu farqlarda muvaffaqiyatsiz bo'ladi. Hech qanday versiya raqami birini ikkinchisiga aylantirmaydi va eski parametr nomlarini yangi profilga ko'chirish kelishib, keyin hech narsani autentifikatsiya qilmaydigan klient beradi.
Gibrid rejim IKEv1 ichida nima qilgan
Gibrid profilda javob beruvchi tomon birinchi faza almashinuvini o'z sertifikati bilan imzolaydi, tashabbuskor esa ataylab hech qanday sertifikat taqdim etmaydi. Shuning uchun shaxs isboti asimmetrik, va bu shlyuzga mavjud PKI ni saqlab qolishga, foydalanuvchilarga esa katalog parollarini saqlashga imkon berdi. Birinchi faza tugagach, XAuth so'rov va javob sifatida ishlaydi, ular endi shifrlangan ISAKMP kanali ichida foydalanuvchi nomi va parol atributlarini olib yuradi.
Ishonch qayerga tushishiga e'tibor bering. Sertifikat klient qaysi shlyuzga yetib kelganini javob beradi; XAuth qaysi foydalanuvchi kirishni xohlashini javob beradi. Hech biri ikkinchisini almashtirmaydi va har qanday server sertifikatini qabul qilishga sozlangan klient birinchi javobni jimgina tashlab yuborgan. Gibrid yorlig'i oldindan bo'lishilgan kalit va XAuth bilan agressiv rejim uchun ham ishlatiladi, bu bir xil foydalanuvchi tajribasiga ega boshqa tartib, shuning uchun nomni emas, profilni o'qing. Ikkala variant ham hech qachon standart bo'lmagan loyihalardan keladi va shuning uchun ikki ishlab chiqaruvchi gibrid rejimni joriy qilib, hech biri bilan o'zaro ishlay olmasligi mumkin.
IKEv2 xuddi shu ikki isbotga qanday yetadi
IKEv2 ishni IKE_SA_INIT va IKE_AUTH o'rtasida bo'ladi. Birinchi almashinuv hech qanday shaxssiz takliflar va kalitlarni kelishadi; ikkinchisi IDi, IDr va AUTH yuklamalarini olib yuradi. EAP ostida tashabbuskorning birinchi AUTH yuklamasi bo'sh chiqadi, javob beruvchi birinchi bo'lib o'z sertifikati va imzosi bilan autentifikatsiya qiladi, keyin EAP suhbati IKE_AUTH xabarlari ichida davom etadi.
Buni xavfsiz qiladigan mexanizm kalit materialidir. Muvaffaqiyatli EAP usuli sessiya kalitini eksport qiladi va tashabbuskorning oxirgi AUTH yuklamasi shundan hisoblanadi, shuning uchun foydalanuvchi isboti va tunnel kalitlari bir-biriga bog'lanadi. XAuth da bunga o'xshash narsa yo'q: uning atributlari birinchi fazadan keyin keladi va kalitlarga hech narsa qo'shmaydi. Aynan shu bo'shliqni IKEv2 asosi yopish uchun loyihalangan va shuning uchun ishlaydigan IKEv2 kirishi biror narsa so'rashdan oldin server sertifikatini tekshiradi.
Bu tartib ham foydali diagnostika. Klient sizga sertifikat ko'rsatishdan oldin hisob ma'lumotlaridan shikoyat qilsa, u umuman IKEv2 EAP almashinuvini qilmayapti.
Uch shaxsni alohida saqlang
Migratsiya uch shaxs bitta maydonga birlashganda buziladi. Klient tekshiradigan shlyuz shaxsi bor, odatda sertifikatning subject yoki SAN qismidagi DNS nomi. EAP da taqdim etiladigan foydalanuvchi shaxsi bor, ehtimol domen kirishi, manzil yoki aniq EAP shaxs satri. Va o'sha foydalanuvchini tarmoqlar va marshrutlarga bog'laydigan ruxsat manbasi bor.
strongSwan ning swanctl sintaksisi ajratishni ko'rinadigan qiladi: ulanish shlyuz uchun remote { auth = pubkey } va foydalanuvchi uchun local { auth = eap-mschapv2 } o'rnatadi, EAP shaxsi esa alohida olib boriladi.
Yangi profildagi foydalanuvchi shaxsi eski XAuth atributlaridan farq qilsa, masalan qisqa nom o'rniga UPN, autentifikatsiya serveri noma'lum foydalanuvchini ko'radi va nosozlik noto'g'ri parol kabi ko'rinadi. Hisob ma'lumotlarini tekshirishdan oldin shaxs satrini tekshiring.
Parametrlarni xaritalang, keyin tuzoqlarni kuting
Xarita qisqa va har bir satrda faqat autentifikatsiya paytida ko'rinadigan tuzoq bor.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
O'sha satrlarning hech biri shunchaki nom o'zgartirish emas. Konfiguratsiya yuklamasi manzillar va rezolverlarni tiplashtirilgan atributlar ro'yxati orqali yetkazadi, XAuth ning atribut maydoni esa o'z ixtirosi edi; ularni almashtirsa bo'ladigan deb hisoblash profilning shlyuz hech qachon yubormaydigan sozlamani so'rashiga olib keladigan yo'ldir.
Trafik selektorlari o'z ogohlantirishiga loyiq. IKEv1 qiziqarli trafikni quick mode almashinuviga bog'langan proxy ID lar orqali ifodalagan, IKEv2 esa selektorlarni IKE_AUTH davomida kelishadi va javob beruvchi ularni toraytirishi mumkin. Mos kelmaslik child SA siz o'rnatilgan IKE SA hosil qiladi, ba'zi klientlar uni xursandchilik bilan ulangan deb ko'rsatadi.
Eski ulanishga chegara sifatida qarang
RFC 9395 IKEv1 ni eskirgan deb e'lon qiladi, shuning uchun eski gibrid ulanish sanasi bor muvofiqlik chegarasi, poydevor emas. O'zgarish davomida ikkala profilni yonma-yon ishga tushiring, chunki muhim sinov yangi profil ko'tariladimi emas, balki o'sha foydalanuvchi o'sha qurilmada o'sha resurslarga yetadimi.
Sertifikat tekshiruvini oxirigacha qat'iy saqlang. Klient o'z sertifikatini taqdim etishni to'xtatgach, handshake tugaguncha server tekshiruvini yumshatish vasvasasi paydo bo'ladi va bu qolgan yagona isbotni yashil belgi bilan almashtiradi.
Eski profilni iste'foga chiqarishdan oldin to'rt narsani yozib qo'ying: EAP usuli, shaxs satri, ruxsat manbasi va qo'llab-quvvatlash tugaydigan sana.