Tunnel ko‘tarildi, trafik oqdi, keyin jurnal shunday deydi: peer SA proposal not match local policy. Ko‘pchilik bu satrni ikki konfiguratsiya hech qachon mos kelmaganining isboti deb o‘qiydi. Odatda bu torroq ma’noni bildiradi: ular birinchi CHILD SA uchun mos keldi va birinchi yangilanishda mos kelishni to‘xtatdi, chunki birinchi assotsiatsiya keyingilar amalga oshiradigan almashinuvga hech qachon muhtoj bo‘lmagan. Aynan shu farq qayerga qarashni belgilaydi.

Birinchi CHILD SA meros oladi, keyingilari kelishadi

IKEv2 da boshlang‘ich CHILD SA IKE_AUTH vaqtida yaratiladi va uning kalitlari IKE SA kalit materialidan olinadi. O‘sha paytda alohida Diffie-Hellman almashinuvi yo‘q, shuning uchun bir peer qabul qila olmaydigan PFS guruhi hali sinovdan o‘tkazilmaydi. Tunnel sog‘lom ko‘rinadi, chunki keyin siz muvaffaqiyatsiz bo‘ladigan talab hech qachon sinalmagan.

CHILD_SA kalitini yangilash boshqa xabarlar ketma-ketligidir. PFS sozlangan bo‘lsa, peerlar yangi kalit almashinuvini amalga oshiradi va ikki tomon qabul qiladigan guruh, shuningdek yangi assotsiatsiya uchun ESP taklifi bo‘yicha kelishishlari kerak. Nosozlik ko‘rinadigan payt aynan shu, shuning uchun xato marshrutni emas, taklifni nomlaydi.

Demak «kecha ishlagan» taklif haqida sizga hech narsa aytmaydi. Bu boshlang‘ich almashinuv muvaffaqiyatli bo‘lganini aytadi, buni siz allaqachon bilardingiz.

Muvaffaqiyatsiz almashinuvni o‘qing, birinchi pingni emas

Biror narsani o‘zgartirishdan oldin ikki tomondan ham muvaffaqiyatli IKE autentifikatsiyasini, boshlang‘ich CHILD SA ni va muvaffaqiyatsiz almashtirishni to‘plang. Keyin operatsiyani aniq nomlang: IKE SA kalitini yangilash, IKE qayta autentifikatsiyasi va CHILD SA kalitini yangilash — uch xil hodisa, «2-bosqich» esa kundalik suhbatda ularning barchasini qamrab oladi.

Quyidagi maydonlarni muvaffaqiyatsiz bo‘lgan ulanish uchun solishtiring, tunnel uchun umuman emas.

QatlamSolishtiriladigan qiymatlar
IKEVersiya, shifrlash va yaxlitlik yoki PRF tartibi, DH guruhi
IPsec / CHILDESP shifrlash va yaxlitligi, mo‘ljallangan PFS yoki kalit almashinuvi guruhi
Himoyalangan trafikMahalliy va uzoq tanlagichlar, shuningdek siyosatga asoslangan har qanday tanlagich sozlamasi

FortiGate da o‘sha tunnel uchun 2-bosqich taklifini, PFS sozlamasini va qabul qilingan DH guruhlarini oching. Ilgari o‘rnatilgan ulanishdan taxmin qilish o‘rniga yuklangan qiymatlarni o‘qing. GUI sahifasining skrinshoti ishlab turgan konfiguratsiyadan kuchsizroq dalil, chunki yangilanishdan keyin ikkalasi farq qilishi mumkin. O‘zgartirgan bo‘limingizni eksport qiling va uni chipta bilan saqlang.

Azure ning standart siyosati ham siyosat

Ulanishga maxsus siyosat biriktirilmaganligi Azure hech qanday siyosat qo‘llamaydi degani emas. Ulanish shlyuzning standart takliflar to‘plamiga qaytadi, u sizning FortiGate taklif qilganidan kengroq yoki torroq bo‘lishi mumkin. Agar ikki to‘plam IKE uchun ustma-ust tushsa, lekin PFS bilan ESP uchun tushmasa, aynan shu muvaffaqiyatsizlik namunasini olasiz.

Bu faqat-o‘qish ko‘rinishi haqiqatda biriktirilgan siyosatni sirlarni oshkor qilmasdan ko‘rsatadi:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Haqiqiy resurs nomlaridan foydalaning. Aniq siyosat kerak bo‘lsa, uni ulanish resursiga o‘rnating. Bu butun shlyuzning kaliti emas va u o‘sha shlyuzdagi boshqa tunnellarga jimgina qo‘llanmaydi.

Portalda Configuration sahifasi o‘sha ulanishning maxsus IPsec/IKE siyosati joylashadigan joy. Microsoft ning maxsus siyosatlar bo‘yicha qo‘llanmasi qo‘llab-quvvatlanadigan parametrlar va SKU talablarini sanab o‘tadi. Azure har bir ulanish uchun bitta to‘liq kombinatsiyani oladi, shuning uchun IKE maydonlarini va IPsec maydonlarini birga ko‘rsatasiz, birma-bir emas.

PFS — talab, aylantirib qo‘yiladigan kalit emas

Agar xavfsizlik asosiy chizig‘ingiz PFS ni talab qilsa, yechim — ikki tomondagi ikki peer qabul qiladigan guruh, mos keladigan siyosat orqali ifodalangan. Xatoni yo‘qotish uchun PFS ni o‘chirish siz saqlab qolmoqchi bo‘lgan xavfsizlik xususiyatini o‘zgartiradi va u odatda keyinroq boshqa nomuvofiqlik sifatida qaytadi.

Azure ga xos bir tuzoq: ESP uchun GCM tanlaganingizda, shifrlash va yaxlitlik tanlovlari bir xil GCM algoritmi va bir xil kalit uzunligini nomlashi kerak. GCM shifrini alohida yaxlitlik algoritmi bilan aralashtirish xizmat rad etadigan kombinatsiyani hosil qiladi va siyosatni diqqat bilan o‘qimaguningizcha bu peer nomuvofiqligidek ko‘rinadi.

Ikki uchi qo‘llab-quvvatlaydigan va talabingiz ruxsat beradigan eng kuchli kombinatsiyani tanlang, so‘ng uni o‘zgarishlar daftariga yozing. Keyingi odam o‘sha daftar bilan solishtiradi, ishlagan tunnel xotirasi bilan emas. Unga PFS guruhini va ESP taklifini kiriting, faqat siyosat nomini emas. Keyinroq kimdir audit nima uchun muvaffaqiyatsiz bo‘ldi yoki kalit yangilash nima uchun sekin deb so‘rasa, o‘sha satr ikkala savolga ham javob beradi.

Muvaffaqiyatsiz bo‘lgan almashinuvni tekshiring

O‘zgartirishni tiklash yo‘li bilan rejalashtiring, chunki siyosatni tahrirlash siz tuzatmoqchi bo‘lgan tunnelni uzishi mumkin. Trafik qaytgach, CHILD_SA yangilanishini kuting yoki uni ishga tushiring va yangi assotsiatsiya mo‘ljallangan PFS guruhi bilan o‘rnatilganini tasdiqlang. Keyin ilova trafigi u orqali davom etayotganini tasdiqlang.

Ikki yolg‘on izni nomlash o‘rinli. SA umrlari mahalliy spetsifikatsiyalar, shuning uchun teng bo‘lmagan qiymatlar normal va ularni o‘zgartirish muammo qachon paydo bo‘lishini ko‘chiradi xolos. DPD peer tirikligini aniqlaydi; uning vaqt chegarasini oshirish ESP yoki PFS tanlovlarini tenglashtirmaydi.

O‘zgarishdan keyin kelishilgan natija va keyingi hodisani yozib qo‘ying. Agar ulanish endi IKE autentifikatsiyasi tugamasdan muvaffaqiyatsiz bo‘lsa, siz hozir tahrirlagan IKE sozlamalarini ko‘rib turibsiz, dastlabki CHILD yangilash nosozligini emas.

O'xshash maqolalar