Peering bilan ulangan Azure VNet-ga o'zining VPN darvozasi kerakmi?
Peering bilan ulangan VNet hub-ning VPN darvozasidan qo'llab-quvvatlanadigan SKU va har bir peering yo'nalishida bitta sozlama bilan foydalanishi mumkin. Peering holatini emas, samarali marshrutlarni tekshiring.
Yangi spoke VNet paydo bo'ladi, hub allaqachon ishlaydigan site-to-site darvozasiga ega va aniq savol ikkinchi darvoza uchun to'lash kerakmi yoki yo'q. Odatda yo'q: darvoza tranziti spoke-ga peering orqali hub darvozasidan foydalanish imkonini beradi. Bu ishlashini uchta shart hal qiladi va ularning hech biri peering holati nishonida ko'rinmaydi. Peering ulanishi va boshqaning darvozasidan foydalanish ruxsati alohida sozlamalardir, shuning uchun bir-birini allaqachon ping qila oladigan ikki VM VPN yo'li haqida hech narsani isbotlamaydi.
Birinchi shart: darvoza va spoke-da uning yo'qligi
Azure Basic-dan boshqa VPN Gateway SKU-lari uchun darvoza tranzitini qo'llab-quvvatlaydi va uni mintaqaviy hamda global peering olib yura oladi. Spoke o'ziga tegishli bo'lmagan darvozadan foydalanadi, shuning uchun o'z darvozasiga ega bo'la olmaydi: agar spoke-da allaqachon darvoza bo'lsa yoki uzoq darvoza varianti allaqachon tanlangan bo'lsa, siz xohlagan tranzit sozlamasi mavjud bo'lmaydi yoki samarasiz bo'ladi. Biron narsani debug qilishdan oldin buni tekshiring, chunki o'chirilgan belgilash katakchasi alomat, nosozlik emas. Avval SKU va mavjud darvozani o'qing, keyin peering sozlamalariga qarang.
Variant ko'rinishi uchun mavjud spoke darvozasini unga nima bog'liqligini bilmaguningizcha o'chirmang. Migratsiya tartibi belgilash katakchasidan muhimroq.
Ikkinchi shart: har bir peering yo'nalishida bitta sozlama
Peering ikki obyekt, har bir VNet-da bittadan, tranzit sozlamalari esa bu juftlikning turli tomonlarida. Hub-ning spoke tomon peering-i hub darvozasiga spoke-ga xizmat qilishga ruxsat berishi kerak; spoke-ning hub tomon peering-i hub darvozasini qabul qilishi kerak. Microsoft-ning darvoza tranziti qo'llanmasi ularni yo'nalish bo'yicha nomlaydi va ularni to'g'ri saqlashning yagona yo'li shu:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote yorlig'i bilan belgilangan boshqaruv elementi qaysi VNet peering-ini tahrirlayotganingizga qarab ma'nosini o'zgartiradi, shuning uchun so'zni emas, yo'nalishni o'qing. Ikki tomonni ham sozlang, saqlang va peering ikkala joyda ham ulanganini bildirishiga ishonch hosil qiling.
Uchinchi shart: manzil maydoni va ruxsat chegaralari
Tranzit bir xil manzil prefiksi ikki tarmoqni bildirishiga erisha olmaydi, shuning uchun hub, spoke va mahalliy tarmoq diapazonlari bulardan birontasi ishlashidan oldin ajratilgan bo'lishi kerak. VNet-lar turli obunalar yoki turli ijarachilarda ham bo'lishi mumkin; bu taqiq emas, lekin har bir peering-ni yaratuvchi yoki yangilovchi identifikatsiya o'sha tarmoqda zarur ruxsatlarga ega bo'lishi kerak. Obunalar orasidagi o'zgarishlar ko'pincha ruxsat sababli muvaffaqiyatsiz bo'ladi va xatoni topologiya muammosi deb noto'g'ri o'qish oson.
O'zgarishdan oldin diapazonlar va egalarni yozib qo'ying. Ulardan birini taxmin qilish ulanadigan, ammo hech narsani marshrutlamaydigan peering hosil qiladi.
Peering holati bilan emas, samarali marshrutlar bilan tekshiring
Spoke ish yuklamasining tarmoq interfeysidagi samarali marshrutlarni ko'ring va haqiqiy mahalliy prefiksni toping. Subnetning marshrut jadvali va darvoza marshrutlari tarqalishi o'chirilganini tekshiring, chunki foydalanuvchi belgilagan marshrut yoki tekshiruv qurilmasi peering bayroqlari taklif qiladigan yo'lni bosib ketishi mumkin. Keyin qarama-qarshi yo'nalishni tasdiqlang: mahalliy tarmoq site-to-site ulanishi orqali spoke prefiksiga qanday yetishni bilishi kerak, bu o'rganilgan e'lonlar yoki aniq marshrut va mijoz qurilmasidagi mos keladigan himoyalangan tarmoq yozuvi orqali bo'lishi mumkin. Agar prefiks biron bir tomonda yo'q bo'lsa, o'zgartirilishi kerak bo'lgan narsa peering bayroqlari emas.
Spoke ish yuklamasidan bitta xizmatni sinab ko'ring va javobni kuzatib boring. VPN darvozasidan yoki hub VM-dan sinov boshqa manba prefiksi va boshqa yo'lni qo'llaydi.
Agar topologiya point-to-site mijozlariga ham xizmat qilsa, ularning o'rnatilgan marshrutlarini alohida tekshiring. Topologiya o'zgarishidan keyin Windows mijoz paketlarini qayta yaratish talab qilinishi mumkin, va bu darvoza almashinuvining muvaffaqiyatsizligi isboti emas, mijoz marshrutlash vazifasidir.
Darvoza almashish nima bermaydi
Darvoza tranziti marshrutlash qulayligi, ruxsat emas. Tarmoq xavfsizlik guruhlari, mahalliy filtrlar va xizmat darajasidagi qoidalar hali ham spoke ish yuklamasi nimaga yetishi mumkinligini hal qiladi, shuning uchun ulashilgan tunnel orqasidagi hamma narsaga ruxsat beradi deb o'ylash o'rniga aniq manbadan manzilga xizmatni yoqing.
Peering ham odamlar umid qilgandek tranzitiv emas. Yana bir spoke yoki shaxsiy oxirgi nuqta qo'shish mavjud tranzit sozlamasi qamrab olmaydigan o'z marshrutlash va kirish talablarini olib keladi.