Paket ushlashda birinchi IKEv2 almashinuvini qanday o'qish kerak

Sessiya o'rtasida olingan ushlashlar IKEv2 izi shovqinga o'xshab ko'rinishining odatiy sababidir, chunki yozuv boshlanganda tomonlar allaqachon kalitlarni yangilamoqda yoki shifrlangan yuklarni almashmoqda. Buning o'rniga yangi ulanish urinishidan boshlang, shunday qilib fayldagi birinchi xabar muzokaralarni ochuvchi xabar bo'lsin. Quyidagi o'qish tartibi shuni nazarda tutadi va paket uzoq tomon haqida biror narsani isbotlashdan to'xtaydigan nuqtani belgilaydi. Aynan shu qadamni o'tkazib yuborish ishlayotgan tunnelni bloklangan port sifatida tashxis qilishga olib keladi.

Boshlang'ich almashinuvni ko'rayotganingizni tasdiqlang

IKEv2 muzokaralari IKE_SA_INIT bilan boshlanadi, almashinuv turi 34, xabar identifikatori 0. Tashabbuskor noldan farqli SPI tanlaydi, javob beruvchining SPI esa o'sha birinchi so'rovda nolga teng, javobda esa noldan farq qiladi. Bu uch fakt yangi urinishni kalit yangilashdan yoki ushlashning eng yuqorisida tasodifan turgan IKE_AUTH xabaridan ajratadi.

Sarlavha maydonlari o'qiladi, taklif, kalit almashinuvi va nonce yuklari ham o'qiladi. O'qilishi autentifikatsiya qilingan degani emas: bu bosqichda hech bir tomon shaxsini isbotlamagan va Diffie-Hellman ning maxfiy qiymati hech qachon simda ko'rinmaydi.

Dekodlash panelida aylantirish o'rniga maydonlarni jadval sifatida chop eting, chunki qayta yuborishlar va mos kelmaydigan SPI lar ustunlarda yaqqol ko'rinadi.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Natijani juftlik bilan o'qing. Xabar identifikatori 0 bo'lgan so'rovdan keyin o'sha identifikator va noldan farqli javob beruvchi SPI ni olib yurgan javob bitta almashinuv, so'rov qayta yuborilgani uchun u uch marta ko'rinsa ham. Uchta bir xil so'rov uchta kirish emas va ularni shunday qabul qilish odamlarning mijozi sikl ichida aylanmoqda degan xulosaga kelishining yo'lidir, holbuki u shunchaki sabrli. Xabar identifikatori bo'yicha, so'ngra vaqt belgisi bo'yicha tartiblang va butun suhbat urinishlarning qisqa ro'yxatiga aylanadi.

Muvaffaqiyatni o'qishdan oldin rad javobini o'qing

Javob avtomatik ravishda ilgarilash emas. Javob beruvchi cookie bildirishnomasi bilan javob berib, tashabbuskor yana urinishini kutishi mumkin, yoki uning o'rniga qabul qiladigan guruhni ko'rsatuvchi INVALID_KE_PAYLOAD bilan. Ikkalasi ham to'g'ri shakllangan IKE xabarlari sifatida keladi va faqat paketlarni sanovchi filtrga ikkalasi ham tugagan almashinuv bo'lib ko'rinadi.

Bildirishnoma yukini oching va hamma narsadan oldin turini o'qing. cookie sinovi javob beruvchi soxta manba manzillaridan o'zini himoya qilayotganini bildiradi va mijoz cookie ni ilova qilib qayta yuborishi kerak. Noto'g'ri guruh ikki taklif kelishmayotganini bildiradi, buni bir tomon konfiguratsiyasi o'zgarmaguncha hech qanday qayta urinish o'zgartirmaydi.

Shifrlangan shaxs va autentifikatsiya yuklarini faqat IKE_AUTH, ya'ni ikkinchi almashinuv olib yuradi. Shuning uchun tugallangan IKE_SA_INIT tomonlar algoritmlar va hosil qilingan kalitlar bo'yicha kelishganini aytadi va hisob ma'lumotlari qabul qilinishi haqida hech narsa aytmaydi. U yerda ham ikkita xabarni kuting va sessiya kalitlarisiz ikkalasi ham tushunarsiz bo'lishini kuting.

4500 porti bitta protokol emas

Boshlang'ich almashinuvni odatda UDP 500 olib yuradi. NAT aniqlash ishga tushgach, IKE 4500 ga o'tadi va har bir xabar oldiga to'rt baytlik nol, ESP bo'lmagan belgi qo'yadi. O'sha portdagi inkapsulyatsiyalangan ESP esa noldan farqli ESP SPI bilan boshlanadi, bir baytlik NAT keepalive esa boshqa hech narsa bo'lmaganda paydo bo'ladigan uchinchi shakldir.

Faqat portga mos keluvchi filtr uchtasini ham aralashtiradi, shuning uchun "4500 da trafik bor" juda oz narsani hal qiladi. Uzoq tomon haqida xulosa qilishdan oldin ko'rinishni protokol bo'yicha ajrating.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Sukunat kuzatuv nuqtasini tasvirlaydi

Javobsiz so'rovlar aynan bir narsani aniqlaydi: o'sha ushlash nuqtasida hech qanday javob paydo bo'lmadi. Filtrlash, javobni boshqa joyga yuboradigan marshrut, yetib bo'lmaydigan javob beruvchi yoki taklifni yoqtirmaydigan javob beruvchi barchasi bir xil bo'sh natija beradi va umumiy UDP tekshiruvi ularni ajrata olmaydi.

ICMP yetib bo'lmasligi boshqa turdagi dalildir. Uning ichidagi iqtibos qilingan paketni o'qing va uni qaysi qurilma chiqarganini aniqlang, chunki marshrutizatorning ma'muriy rad etishi uzoq tomondan kelgan autentifikatsiya qilingan xato emas.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Xuddi shu urinishni o'qishga ruxsat berilgan joylarda server tomonidagi jurnallar bilan bog'lang. So'rov yetib keldimi, xizmat javob berdimi va javob qayerda to'xtadi? Bu uch javob sizni yo'l muammosiga yoki siyosat muammosiga yo'naltiradi va ular hisob ma'lumotlarini to'rtinchi marta almashtirishdan arzonroq.