strongSwan send_cert: IKE sertifikati qachon yuboriladi

Shlyuzlar sertifikat bilan bog'liq autentifikatsiya xatolarini jurnalga yozadi va birinchi fikr qabul qiluvchiga yana bir CA qo'shish bo'ladi. Bu sertifikat yetib kelgan va rad etilgan deb hisoblaydi. Boshqa ehtimol uning hech qachon yuborilmaganidir va buni yuboruvchining ulanish siyosati hal qiladi. Ishonchni o'zgartirishdan oldin ikki holatdan qaysi biri sodir bo'lganini aniqlang.

send_cert aslida nimani boshqaradi

Sertifikat bilan autentifikatsiya peerning oxirgi obyekt sertifikati IKE almashinuvi yoki oldindan tayyorlash orqali qarshi tomonga yetib borishini talab qiladi. swanctl ichida ulanish parametri send_cert bu oxirgi nuqta o'z sertifikat yukini kiritishini belgilaydi: hech qachon, har doim yoki ifasked. Standart ifasked uni peerdan kelgan sertifikat so'roviga javob sifatida yuboradi. Sertifikat so'rash alohida parametrdir, chunki qarshi tomondan uning sertifikatini so'rash o'z sertifikatini taklif qilish bilan bir xil emas.

Eski ipsec.conf o'rnatishlari leftsendcert va rightsendcert ishlatgan va bu nomlar mahalliy va masofaviy rollarga mos keladi, bevosita swanctlga emas.

Ulanishni o'zgartirishdan oldin bitta urinishni o'qing

Bitta nazorat qilinadigan urinish asosida tashxis qo'ying, sertifikatlar ishtirok etmoqda degan umumiy taassurot asosida emas. Ham siyosat, ham faol assotsiatsiya tekshirilishi mumkin.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Ulanishlar ro'yxati sozlangan send_cert qiymatini, SA ro'yxati esa qaysi ulanishlar haqiqatan ko'tarilganini ko'rsatadi. Jurnal muzokara tafsilotlarini qo'shadi: sertifikat so'rovi olinganmi va sertifikat yuki chiqqanmi. Umumiy autentifikatsiya xatosi yetkazib berish muammosini ko'rsatmaydi, shuning uchun xulosa qilishdan oldin aniq almashinuvni qidiring. Urinishning vaqt belgisini yozib qo'ying, jurnal oynasi butun qo'l siqishni qamrab olsin.

Qabul qiluvchining ishonchi alohida qaror

Yetkazib berish va ishonch turli xossalar va birini tuzatish ikkinchisini tuzatmaydi. Qabul qiluvchida mo'ljallangan ishonch langari bo'lishi, foydalanish mumkin bo'lgan zanjir olishi va kutilgan peer identifikatsiyasiga mos kelishi kerak. Oraliq sertifikatisiz kelgan oxirgi obyekt sertifikati qattiq zanjir tekshiruvidan baribir o'tmaydi. Aksincha, CA o'rnatish peerni o'z sertifikatini umuman yuborishga majbur qilmaydi.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Tekshiruv sertifikatni qaysi chiqaruvchi imzolaganini va qachon tugashini ko'rsatadi va qabul qiluvchining langari shunga mos bo'lishi kerak. O'rnatishga tegishli chiqaruvchi CAga ishoning, zanjirdagi har bir oraliq sertifikatga emas, chunki har bir oraliq sertifikatni ildizga ko'tarish ishonchni bitta peerdan ancha kengaytiradi. Identifikatsiya tekshiruvini yoqilgan holda saqlang, chunki faqat tekshiruv o'chirilganda muvaffaqiyat qozonadigan ulanish tuzatish emas. Zanjir to'liq bo'lmagan joyda tayyorlashni tuzating, yuboruvchining siyosatini emas.

Yuboruvchini faqat dalillar bilan o'zgartiring

Jurnal sertifikat hech qachon yuborilmaganini va qabul qiluvchi uni haqiqatan so'raganini ko'rsatsa, send_cert parametrini always qilish o'sha ulanish uchun asosli o'zgarishdir. Uni swanctl konfiguratsiyasida qo'llang, ulanishlarni qayta yuklang va mavjud SAni qayta ishlatish o'rniga yangi sessiya o'rnating. Sertifikat yuki endi ko'rinishini va qabul qiluvchi uni mo'ljallangan langarga nisbatan qabul qilishini tasdiqlang. Hech narsa o'zgarmasa, xato baribir ishonch tomonda edi va yuboruvchi parametri sabab emas edi.

Kuzatilgan almashinuvni, langarni va undan kelib chiqadigan tekshiruvni o'zgarishlar yozuviga yozing. Bu atamalar bilan tasvirlab bo'lmaydigan sertifikat tuzatishi tasodifdir.