Bitta IKEv2 kirishida ikkita shaxs: avval mashina, keyin foydalanuvchi

Mijoz sertifikati tekshiriladi, birinchi almashinuv yakunlanadi, so‘ngra ulanish qo‘shimcha autentifikatsiya raundi haqidagi xato bilan to‘xtaydi. Sertifikatlar zanjirida hech narsa noto‘g‘ri emas va tarmoqda hech narsa o‘zgarmagan. Shlyuz ulanayotgan tomondan ikkinchi dalil talab qilishga sozlangan, mijoz esa uni hech qachon yubormaydi. Kim nimani qanday tartibda isbotlashini hal qilish butun vazifadir va u siz turgan endpointdagi siyosatni o‘qishdan boshlanadi. Turli turdagi ikkita dalil, qat’iy tartibda, bu dizayn qarori, bayroqcha emas.

Alomat: muvaffaqiyatli birinchi dalildan keyin muvaffaqiyatsizlik

Birinchi almashinuv yakunlanadi va jurnal sog‘lom ko‘rinadi, toki shlyuz EAP orqali foydalanuvchi shaxsini so‘ramaguncha. Keyin qo‘l berish to‘xtaydi yoki qo‘shimcha raundni nomlaydigan protokol xatosini qaytaradi. To‘liq haqiqiy mashina sertifikati uning haqiqiyligiga aloqasi bo‘lmagan sabab bilan rad etilmoqda. Siyosat ikkinchi dalilni so‘radi va mijozning javobi hech qachon yetib kelmadi.

Bu muvaffaqiyatsizlikning ikkala ta'rifi ham qayerda turganingizga qarab to‘g‘ri. Mijoz tomondan bu haqiqiy sertifikatni rad etayotgan serverga o‘xshaydi, server tomondan esa kirishni tugata olmaydigan mijozga o‘xshaydi. Xuddi shu voqea bir jurnalda ishonch muammosi, boshqasida esa imkoniyat muammosi sifatida o‘qiladi. Faqat sozlangan siyosat qaysi biri ekanini aytadi.

Kengaytma nima qo‘shadi va nima qo‘shmaydi

IKEv2 bitta sessiya ichida bir nechta autentifikatsiya almashinuvini bajarish uchun kengaytmaga ega. RFC 4739 boshqa ketma-ketliklar qatorida sertifikat shaxsini isbotlab, so‘ngra EAP orqali shaxsni autentifikatsiya qiladigan mijozni tasvirlaydi. Hujjat eksperimental, ya'ni hech bir amalga oshirish bu xususiyatni sizga qarz emas. Hamkor buni kelishmaguncha qo‘llab-quvvatlash haqida hech narsa taxmin qilmang.

Ikkala tomon ham kengaytmani qo‘llab-quvvatlashi va almashinuv paytida unga rozi bo‘lishi kerak. Ikkinchi raundga sozlangan shlyuz mijozni bunga majburlay olmaydi, uni qo‘llab-quvvatlaydigan mijoz esa server so‘ramasa undan foydalanmaydi. Aynan shu assimetriya sababli muvaffaqiyatsizlik odatda imkoniyat haqidagi aniq bayonot o‘rniga vaqt tugashi yoki protokol xatosi sifatida namoyon bo‘ladi. Bir tomonning konfiguratsiyasini o‘qish nima bo‘lishining yarmini aytadi.

Har bir endpoint uchun bitta dalil odatiy shakl va bu bu dizayn emas. Shlyuz o‘z sertifikatini taqdim etadi, foydalanuvchi EAPga javob beradi va har bir tomon boshqasini aynan bir marta autentifikatsiya qilgan bo‘ladi. Bu ikki dalil qarama-qarshi endpointlardan keladi, shuning uchun hech biri mashina va undan foydalanayotgan shaxs haqida alohida bir narsa aytmaydi.

EAP-TLS uchinchi shakl va u ham bu emas. U yerda mijoz sertifikati EAP usuli ichida taqdim etiladi, shuning uchun mijoz baribir bitta IKE autentifikatsiyasini yakunlaydi. Hisob ma'lumotlari ko‘p raundli holatga o‘xshab ko‘rinishi mumkin, holbuki protokol ikkita emas, bitta raund olib yuritadi. Shuning uchun EAP-TLS joylashtirishidan ko‘chirilgan dizayn ikkinchi dalil kutilgan joyda muvaffaqiyatsizlikka uchraydi.

Xuddi shu fayl shlyuzda boshqacha o‘qiladi

Xuddi shu swanctl fayli qayerda ishga tushishiga qarab boshqacha o‘qiladi va odamlarni chalg‘itadigan qism aynan shu. Noutbukda shlyuz hamkor tomon, shlyuzda esa noutbuk, shuning uchun local tomonni men kimman, remote tomonni kimni qabul qilaman deb yozing. local bloki bu endpoint o‘zini qanday autentifikatsiya qilishini tasvirlaydi, remote bloki esa narigi uchdan nima talab qilishini bildiradi. Blokni ikki fayl orasida ko‘chirish bitta belgini o‘zgartirmasdan uning ma'nosini teskari qiladi. Ikki faylni solishtirish deyarli hech narsa demaydi, chunki bir xil so‘zlar har birida qarama-qarshi ma'no bildiradi.

Bo‘limning joylashuvi uning tartibini belgilaydi, agar raund raqami uni bekor qilmasa. Shuning uchun qo‘shimcha local yoki remote bo‘limlar alternativa emas, qo‘shimcha raundlarni tasvirlaydi va swanctl.conf ma'lumotnomasidagi aniq raund raqami aynan shu tartibni ataylab qilish uchun mavjud. Usiz blokni ko‘chirish xatti-harakatni o‘zgartiradi. Shuning uchun qog‘ozda teng ko‘ringan ikki konfiguratsiya qarama-qarshi tartibda ishlashi mumkin.

Bu tartib qoidasi eslab qolishga arziydigan nosozlik uslubini keltirib chiqaradi. Ikkinchi remote blok yana bir maqbul variant emas; bu ikkinchi talab, shuning uchun yo/yo kabi o‘qiladigan siyosat va-keyin kabi ishlaydi. Shlyuz siyosati ro‘yxatga olingan mashina sertifikatini qabul qilib, so‘ngra o‘sha foydalanuvchining EAP almashinuvini shu tartibda talab qilishi mumkin.

Raundlarni mustaqil omillardan ajrating

Ikki raund avtomatik ravishda ikki mustaqil omil emas. Dalilni takrorlash yoki ikki hisob ma'lumotini bitta omborda saqlash dizayn qo‘shishi kerak bo‘lgan kuchni bermaydi. Mustaqillik sirlar qanday saqlanishi va ularga nima zarar yetkazishining xossasi, protokol nechta almashinuv bajarishining emas. Raundlarni omil deb sanaydigan dizayn o‘zida bor narsani oshirib yuboradi. Bu farq muvofiqlik savoli kirish aslida nechta omildan foydalanishini so‘raganda eng muhim bo‘ladi.

Mashina sertifikati o‘zining qabul qilingan kalitiga egalikni isbotlaydi, boshqa hech narsani emas. Bu apparat attestatsiyasi ham, qurilma salomatligi hisoboti ham emas, shuning uchun holat ma'lumotiga muhtoj siyosatga boshqa mexanizm kerak. subject maydoni ham ishonishingiz mumkin bo‘lgan inventar yorlig‘i emas, chunki subjectni sertifikatni bergan yoki ro‘yxatga olgan kishi tanlaydi. Agar dizaynga mashina sog‘lomligi isboti kerak bo‘lsa, bu isbot mashinani o‘lchaydigan komponentdan kelishi kerak.

Har bir raund aslida nimani isbotlashini qo‘shishdan oldin yozib qo‘ying. Ikki raund bir xil narsani ikki marta isbotlasa, ikkinchisi ishonch o‘rniga kechikish va qo‘llab-quvvatlash chiptalarini qo‘shadi. Bu eslatma qo‘shimcha raund o‘z xarajatiga arziydimi degan bahsni ham to‘xtatadi.

Juftlash qoidasini yozing va rad etishlarni sinang

Qaysi mashina shaxslari qaysi odamlar bilan juftlashishi mumkinligini hal qiling va qoidani ijro joyida yozing. Yonma-yon turgan ikki haqiqiy hisob ma'lumoti juftlash haqida hech narsa isbotlamaydi, chunki juftlash autentifikatsiya natijasi emas, avtorizatsiya qaroridir. Ro‘yxatga olish yozuvlari yoki autentifikatsiya backend'i tashkilot xohlagan munosabatni ijro etishi kerak.

So‘ngra muvaffaqiyatsiz bo‘lishi kerak bo‘lgan narsalarni sinang: tasdiqlanmagan mashinada qabul qilingan foydalanuvchi, mashina hisob ma'lumotiga ega tasdiqlanmagan foydalanuvchi va qo‘shimcha raundni bajara olmaydigan hamkor. Agar uchtasi ham jimgina bir xil ruxsat olsa, siyosat uni ijro etish o‘rniga niyatni tasvirlaydi. E'lon qilingan konfiguratsiyani demon xabar bergani bilan solishtiring, chunki hech qachon mos kelmagan ulanish o‘tgan qoidaga o‘xshab ko‘rinadi:

swanctl --list-conns
swanctl --list-sas

Faqat muvaffaqiyatli kirishni emas, kelishilgan raundlarni va ulardan kelib chiqadigan avtorizatsiyani tekshiring. Va eski IKEv1 XAuth sozlamalarini yechim sifatida ishlatmang: ulanish ishlamaguncha kerakli raundni o‘chirish o‘rniga protokolni, rollarni, tartibni va mijozning haqiqiy xatti-harakatini moslang. Muvaffaqiyatsiz raundni o‘chirish ikki dalilli dizaynning jimgina hech kim ko‘rib chiqmagan bitta dalilli dizaynga aylanish usulidir. O‘chirishni o‘zgarishlar yozuvida saqlang.