Azure saytlararo VPN va NAT orqasidagi peer: tekshiruv ro‘yxati

Bu tekshiruvlarni tartib bilan bajaring va birinchi muvaffaqiyatsiz bo‘lganida to‘xtang. Azure NAT orqasidagi qurilmani qo‘llab-quvvatlamaydi degan xabarlarning ko‘pchiligi aslida Azure yetib bora olmaydigan peer manzili yoki hech qachon to‘g‘ri tomondan boshlanmaydigan tunnel bo‘lib chiqadi. Tashqi transport va ichki marshrutlash ikki xil muammo, ularni aralashtirish yarim kunni yo‘qotadi. Quyidagi har bir qadam boshqasiga berish mumkin bo‘lgan kuzatuv beradi.

1-qadam: peer haqiqatan NAT orqasida ekanini tasdiqlang

Qurilmaning WAN interfeysidagi manzilni Azure u uchun ko‘radigan manzil bilan solishtiring. Agar ular farq qilsa, biror narsa tarjima qilmoqda va o‘sha tarjimon endi VPN dizayningizning bir qismi. Provayderdan xaritalash statik yoki umumiy ekanini so‘rang, chunki umumiy xaritalash ishonishingiz mumkin bo‘lgan narsani o‘zgartiradi. Xususiy WAN manzili bo‘lgan va yo‘naltirishsiz qurilma barqaror ommaviy xaritalashga ega operator darajasidagi NAT orqasidagi qurilmadan boshqa holat.

Agar ikkala manzil mos kelsa, shu yerda to‘xtang: NAT sizning muammongiz emas va bu ro‘yxatning qolgani yordam bermaydi.

Ikkala manzilni va tarjimon modelini tikketga yozing. O‘sha bitta satr sozlangan peer nima uchun javob bermayotgani haqidagi keyingi savollar turini oldini oladi.

2-qadam: kim boshlashini kelishib oling

Azure VPN Gateway bo‘yicha ko‘p so‘raladigan savollar NAT-T qo‘llab-quvvatlanishini ko‘rsatadi va joyidagi qurilma NAT orqasida bo‘lsa IPsec tunnelni o‘sha boshlashi kerakligini qo‘shadi. Bu holat saqlovchi tarjimaning ishlashiga mos keladi, chunki tarjimon xaritalashni ichki qurilma birinchi paketni yuborgani uchun saqlaydi. Agar Azure boshlashi kutilsa va o‘sha xaritalashni yaratadigan hech narsa kelmasa, tunnel hech qachon boshlanmaydi.

Peerni faqat-javob beruvchi xatosi yaqqol ko‘rinadigan qilib sozlang va qurilma o‘zi qayta urinadimi yoki trigger kerakmi, tekshiring. Ba’zi qurilmalar tunnelni faqat qiziqarli trafik paydo bo‘lganda ko‘taradi, bu qiziqarli trafik hech qachon kelmaydigan salomatlik tekshiruvi bo‘lib qolguncha yaxshi.

Qo‘lda boshlash paytida qurilmadagi IKE almashinuvini kuzating; u yerdagi sukunat marshrutlash yoki xavfsizlik devori javobi, Azure javobi emas.

3-qadam: peer manzilini to‘g‘ri qo‘ying

Azure o‘zining mahalliy tarmoq shlyuzi obyektida peer uchun yetib boriladigan ommaviy manzil talab qiladi, odatda qurilmaning ichki manzili emas, tarjimonning ommaviy manzili. Qurilma autentifikatsiya qiladigan shaxs alohida maydon va Azure qo‘ng‘iroq qiladigan manzildan qonuniy ravishda farq qilishi mumkin. Ikkalasini alohida saqlang, chunki ularni almashtirish NAT muammosiga aynan o‘xshaydigan autentifikatsiya xatosini keltiradi.

Agar ommaviy manzil o‘zgarsa, o‘sha obyekt ham u bilan o‘zgarishi kerak. Eskirgan manzilga hal bo‘ladigan nom qo‘lda yangilash kerak bo‘ladigan statik manzildan yomonroq.

Uchta qiymatni ham yozing: qurilmaning mahalliy manzili, tarjima qilingan ommaviy manzil, sozlangan peer shaxsi.

4-qadam: faqat NAT-T kerak bo‘lgan portlarni oching

NAT-T ESPni UDP ichida tashiydi va RFC 3948 bu inkapsulyatsiyani 500 portidagi dastlabki muzokaralardan keyin ishlatiladigan 4500 porti bilan tavsiflaydi. Sizning xavfsizlik devoringiz va tarjimon ikkalasi ham almashinuvga va uning qaytish trafigiga ruxsat berishi kerak. Aloqasiz TCP portiga ruxsat berish bu yo‘l haqida hech narsani isbotlamaydi, chiqishga ruxsat berib javobga bermaydigan qoida ham baribir muvaffaqiyatsiz bo‘ladi.

Peer boshlaganda va tarjimon holatni saqlaganda kiruvchi portni statik yo‘naltirish avtomatik talab qilinmaydi. Xaritalash beqaror bo‘lganda yoki yo‘ldagi biror narsa holatni tajovuzkor tarzda tugatganda zarur bo‘ladi.

Tarjimonning ikkala tomonida bir marta yozib oling; inkapsulyatsiya farqi darhol ko‘rinadi.

5-qadam: tashqi transportni ichki marshrutlashdan ajrating

O‘rnatilgan va hech narsa tashimaydigan tunnel marshrutlash muammosi, NAT-T muammosi emas. Saytlarga hali ham mos trafik selektorlari, mos keladigan manzil maydonlari, kirish qoidalari va ilova tarmoqlari uchun qaytish yo‘li kerak. Bularning hech birini muvaffaqiyatli IKE almashinuvi bermaydi.

Agar ikki sayt ustma-ust tushadigan xususiy diapazonlardan foydalansa, tunnel ichidagi tarjima o‘z qoidalariga ega alohida dizayn. Tashqi shlyuz uy routeri orqasida bo‘lgani uchungina quyi tarmoqni qayta raqamlamang.

Biror narsani o‘zgartirishdan oldin nosozlikni bosqich bo‘yicha tasniflang va bu tasnifni tikketda qoldiring, shunda keyingi odam siz to‘xtagan joydan boshlaydi.