Azure S2S VPN ulangan, ammo trafik yo‘q: IKE jurnalini o‘qing

Portal Connected deb yozadi, tunnelda ish vaqti hisoblagichi bor, va virtual mashinangizdan olingan trace ikkinchi hopda o‘ladi. Ulanish holati IKE va IPsec muzokaralarini tasvirlaydi, har ikki tomonda bitta paket siyosat qatlamidan o‘tishini emas. Bu biletlarning ko‘pchiligini ikkita nosozlik izohlaydi va ularning hech biri Azure marshrutini o‘zgartirish bilan tuzatilmaydi. Ikkalasi ham shlyuz yaratgan jurnalda yozilgan, shuning uchun men marshrutlar jadvalidan emas, o‘shandan boshlayman.

Connected aslida nimani tasdiqlaydi

Ulangan site-to-site aloqa 1- va 2-fazalar tugaganini va xavfsizlik assotsiatsiyalari ishlab turganini bildiradi. Bu muzokaralar haqidagi bayonot: ikki tomon taklif bo‘yicha kelishdi, kalitlarni almashtirdi va SA juftini o‘rnatdi. U trafik selektorlari siz himoyalangan deb hisoblagan quyi tarmoqlarga mos keladimi, yoki shifr ochilgandan keyin uzoq tomon paketni biror joyga yo‘naltiradimi — bu haqda hech narsa demaydi. Tunnel haftalab ishlab turib, har bir qiziqarli oqimni tashlab yuborishi mumkin, va aynan shu holat odamlarni sog‘lom shlyuzni qaytadan qurishga majbur qiladi.

Birinchi tekshirilishi kerak bo‘lgan ikkita nosozlik — ESP o‘rniga AH taklif qiluvchi peer va shlyuz ichki deb hisoblamaydigan makonda raqamlangan virtual tarmoq.

Marshrutlarga tegishdan oldin eksport qilingan jurnalni oching

Portalda virtual tarmoq shlyuzini oching va ulanishda VPN troubleshoot amalini ishga tushiring, so‘ng u yaratgan paketni yuklab olib oching. Ichida 1- va 2-fazalar almashinuvi bor IKE jurnali, vaqt belgilari bilan va oddiy matn sifatida o‘qish mumkin. Yuqoridan pastga o‘qish o‘rniga unda transform satrini qidiring, chunki qiziqarli yozuv odatda bir necha yuz satrdan keyin bo‘ladi. Portalga ruxsat bo‘lmasa, diagnostika sozlamalari yoqilgan bo‘lsa, xuddi shu diagnostika shlyuzning jurnal manzilida paydo bo‘ladi.

Ikkita yozuv qiymatning katta qismini olib yuradi. Birinchisi taxminan expected ESP with combined authentication and cipher, received AH deb o‘qiladi. Ikkinchisi IKE almashinuvi paytidagi invalid payload xatosi, bu odatda noto‘g‘ri shakllangan yoki qo‘llab-quvvatlanmaydigan taklif maydonini bildiradi.

Ikkalasi ham joyidagi qurilma nima taklif qilganini tasvirlaydi, demak ikkalasi ham peer tomonidagi sozlamalar. Ulanishning Azure tomonini qayta yaratish firewall’ingiz yuboradigan taklifni o‘zgartirmaydi, va shunday qilish bu ishda eng ko‘p behuda ketadigan soat. Peerda 2-fazani birlashtirilgan autentifikatsiya va shifr bilan ESP ga qo‘ying va algoritmni muzokara qilishiga qo‘yib bering, so‘ng combined mode kabi nomdagi vendor belgilash katakchasi ostidan jimgina AH taklifini tanlayotganini tekshiring.

Virtual tarmoqning manzil maydonini tasdiqlang

Shlyuz virtual tarmoq xususiy diapazonlarda bo‘lishini kutadi. Ommaviy blokda raqamlangan tarmoq, masalan 111.x bilan boshlanadigan, tunnelni ko‘tarishi mumkin, lekin Azure bu maydonni ichki deb hisoblashdan bosh tortadi, shuning uchun ulanish sog‘lom ko‘rinadi va birorta oqim qabul qilinmaydi. Selektorlarga yarim kun sarflashdan oldin manzil maydonini tasdiqlang. Agar raqamlash eski taqsimotdan qolgan qat’iy talab bo‘lsa, yechim boshqa shlyuz emas, manzil rejasini o‘zgartirish.

Manzil maydoni tasmasida turganda joyidagi diapazonlar bilan qoplanishni yozib qo‘ying, chunki qoplangan prefikslar mijozi tomondan o‘xshash ko‘rinadigan boshqa nosozlik keltiradi.

Prefikslarni ikkala yo‘nalishda tekshiring

Mahalliy tarmoq shlyuzi resursi joyidagi prefikslarni saqlaydi va ular uzoq qurilma haqiqatan himoya qiladigan quyi tarmoqlarga mos kelishi kerak. Qurilma tashlab yuboradigan manzillarni o‘z ichiga olgan xulosa ba’zi oqimlarni o‘tkazadi, boshqalarida esa muvaffaqiyatsiz bo‘ladi, bu esa konfiguratsiya nomuvofiqligi emas, vaqti-vaqti bilan takrorlanadigan marshrutlash nosozligi kabi o‘qiladi. Uzoq tomonni ham tekshiring: bir uchi /16 sanab o‘tsa, ikkinchisi uning ichida uchta /24 sanab o‘tadi — bu klassik qismli muvaffaqiyatsizlik. Hech bir ro‘yxat o‘z-o‘zidan obro‘li emas, shuning uchun ko‘rganingizga ishonish o‘rniga ikkalasini yonma-yon solishtiring.

Prefiks o‘zgarishi har doim o‘z-o‘zidan olinmaydi, shuning uchun ulanish obyektini qayta saqlash yoki qayta yaratishni rejalashtiring va keyin yangi prefikslar ikki tomonda paydo bo‘lganini tasdiqlang.

Ping emas, yo‘lni sinang

Ishlayotgan tunnelni ishlayotgan marshrutdan ajratadigan trace shunday ko‘rinadi: birinchi hop — joyidagi shlyuz, keyin javob bermaydigan bir necha hop, keyin uzoq host javob beradi. Agar trace hech qachon hostga yetib bormasa, ilova haqiqatan ishlatadigan TCP portni sinang, chunki ICMP yetarlicha tez-tez filtrlanadi va muvaffaqiyatsiz ping juda kam narsani isbotlaydi. Xuddi shu trace’ni uzoq hostdan Azure’dagi virtual mashinaga qarab ishga tushiring. Ikki natija orasidagi nosimmetriklik yo‘qolgan qaytish marshrutini yoki faqat bitta yo‘nalishga ruxsat beradigan qoidani topishning eng tez yo‘lidir.

Peer taklifini, ikkala manzil maydonini va ulanish yaratilgan vaqtni biletga yozing, keyingi injener qaysi qiymatlar qayta qurilganini va qaysilariga hech qachon tegilmaganini bilsin.

Agar jurnal bo‘sh qaytsa, shlyuz ulanishni umuman tugatmayotgan bo‘lishi mumkin. Mahalliy tarmoq shlyuzidagi peer manzili jurnalni o‘qiyotgan qurilmaga mos kelishini tasdiqlang, chunki bitta obunadagi ikkita shlyuzni qayta qurish paytida chalkashtirish oson. Bu xato bir kunga tushadi va hech bir jurnalda iz qoldirmaydi.