Azure VPN'dagi NAT bir-biriga ustma-ust tushgan VNet manzillarini hal qilmaydi
Bir xil xususiy diapazonga ega ikki VNet faqat NAT borligi uchun ulanmaydi. Avval ulanish turini tekshiring, keyin qayta raqamlang yoki tarjima taxallusiga ega bo'ling.
Ikkala VNet ham 10.40.1.0/24 dan foydalanadi, tunnellar ko'tariladi va hech narsa ishlamaydi. Ikkinchi VPN shlyuzini qo'shish buni o'zgartirmaydi, pastroq marshrut ko'rsatkichi ham o'zgartirmaydi, chunki muammo yo'l tanlashda emas. Bir xil xususiy manzilga javob beradigan ikki ish yuki har bir paketni noaniq manzil va tekshirib bo'lmaydigan qaytish yo'li bilan qoldiradi. Har qanday tarjimani rejalashtirishdan oldin aslida qanday ulanish turini yaratganingizni aniqlang, chunki aynan shu tanlov Azure'ning NAT xususiyati umuman mavjudmi-yo'qligini belgilaydi.
Bu alomat aslida sizga nima deydi
VNet A dagi xost 10.40.1.10 manziliga yuborganda, marshrutlash jadvali uni faqat biror joyga yo'naltira oladi. Agar VNet B da ham 10.40.1.10 bo'lsa, bu manzil yo'l ajrata oladigan manzil emas; bu ikki egasi bo'lgan bitta manzil.
Odamlar odatda joylashtiradigan ikkinchi shlyuz yordam bermaydi. U boshqa tunnel beradi, boshqa manzil emas, va takrorlangan diapazon tunnel ichida o'zgarmagan holda harakatlanadi. U shuningdek izchil saqlashingiz kerak bo'lgan konfiguratsiyani ikki barobar oshiradi. Uning qila olmaydigan ishi — bitta manzil ikki xostni anglatishini ta'minlash.
VPN hamkorlarining ommaviy manzillarini o'zgartirish ham hech narsa bermaydi. Bu manzillar tunnelning chekka nuqtalarini belgilaydi, to'qnashuv esa uning ichida tashiladigan xususiy diapazonda.
NAT mavjudmi-yo'qligini ulanish turi hal qiladi
Azure VPN Gateway haqiqatan ham NAT qobiliyatiga ega va u muayyan shlyuz SKU'larida marshrutga asoslangan IPsec saytlararo ulanishlar uchun hujjatlashtirilgan. Xuddi shu hujjat VNet-to-VNet va point-to-site ulanishlarini istisno qiladi, shuning uchun bu xususiyat har bir shlyuz munosabatida ko'rinadigan belgi emas.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Mahalliy VNet-to-VNet ham VNet va lokal tarmoq diapazonlari boshidan bir-biriga ustma-ust tushmasligini talab qiladi, bu esa istisnoga mos keladi. VNet tenglashtirish ham xuddi shu sababga ko'ra ustma-ust tushish yechimi emas.
Odamlar mahalliy tur bilan aralashtiradigan qo'llab-quvvatlanadigan alternativa bor: boshqa VNetni lokal tarmoq sifatida modellashtiring va uni saytdan-saytga ulanish sifatida ulang. Bu boshqa resurs va boshqa dizayn, shuning uchun nomi o'zgartirilgan ulanishni oddiy nom o'zgarishi emas, tekshirilishi kerak bo'lgan o'zgartirish deb qarang.
Qayta raqamlang yoki taxallusga ega bo'lgan narsa bilan tarjima qiling
Agar ikkala VNet ham sizniki bo'lsa, rejalashtirilgan qayta raqamlashni tarjimaning doimiy xarajati bilan solishtiring. Qayta raqamlash dastur konfiguratsiyasiga, DNS yozuvlariga, xavfsizlik qoidalariga va har bir mavjud ulanishga tegadi, lekin keyin odatdagidek o'qiladigan tarmoqni qoldiradi. Buni bir vaqtning o'zida bitta quyi tarmoq bilan bajaring, DNS o'zgarishi eng oxirida bo'lsin. Yarim qayta raqamlangan diapazon ikkala variantdan ham yomonroq, chunki unda ikkala prefiks ham jadvalni keyingi o'qiydigan kishiga ishonchli ko'rinadi.
Qayta raqamlash amaliy bo'lmagan joyda taxallusning haqiqiy egasi bo'lgan tarjima qilingan dizayndan foydalaning. VNet A dagi chaqiruvchilar VNet B ning 10.40.1.10 manziliga 10.140.1.10 sifatida yetib borishi mumkin, lekin bu taxallusga tarjima qiluvchi qurilma, unga tomon marshrut va javob uchun mos xatti-harakat kerak. Faqat DNS ga qo'shilgan manzil tarjima emas.
Ikkala diapazonni ikki yo'nalishda qayd eting: chaqiruvchi nima teradi, manzil manba sifatida nimani ko'radi va qaysi tomon boshlashi mumkin. Azure'ning o'z NAT qoidalari o'z SNAT xaritalashlari uchun teskari tarjimani o'z ichiga oladi, shuning uchun siz mos DNAT qoidasini qo'lda yozmaysiz, lekin bu qulaylik xususiyat qo'llab-quvvatlaydigan ulanish turlarida tugaydi.
Nima ishlamaydi
Foydalanuvchi belgilagan marshrut yoki marshrut ko'rsatkichi yetishmayotgan manzil farqini yarata olmaydi. Ikkalasi ham hali noaniq manzil ustida ishlaydi va paket jadval afzal ko'rgan keyingi sakrashga yetib boradi.
Takrorlangan diapazonni aniqroq prefiks sifatida marshrutlar jadvaliga qo'shish noaniqlikni faqat bir qadam suradi. Shuningdek, javobning endi ikki ehtimoliy manbasi bo'lgan qarama-qarshi yo'nalishni buzishga moyil.
Dizaynni ikki yo'nalishdagi trafik bilan qabul qiling
Dizaynni tunnel holati bilan emas, har bir tomondan yangi ruxsat etilgan operatsiya bilan isbotlang. Ulangan IPsec tunnel hamkorlar shifrlash bo'yicha kelishganini aytadi; manzillar farqlanadigan bo'lganmi-yo'qmi haqida hech narsa aytmaydi.
Keyin taqiqlangan yo'llarni ishga tushiring: yetib bo'lmaydigan bo'lib qolishi kerak bo'lgan manzil va siyosat to'sishi kerak bo'lgan xizmat. Agar ikkalasi hamon muvaffaqiyatli bo'lsa, tarjima dizayn ko'zlaganidan kengroq.
Sozlamani keyin tushuntiradigan faktlar bilan yakunlang: asl diapazon, taqdim etilgan diapazon, tarjima qiluvchi qurilma va har bir tomon boshlashi mumkin bo'lgan yo'nalish. Agar ulardan biri bo'lmasa, keyingi muhandis ikki xost bir xil nomni baham ko'radigan va hech kim ulardan biri nima uchun javob berishini eslamaydigan tarmoqni meros oladi.