Azure peering yoki VNet–VNet VPN? Marshrutlashdan oldin qaror qiling

Azure ikki virtual tarmoqni ulashning kamida ikki usulini beradi va ular bir obyektdagi almashtiriladigan sozlamalar emas. Peering VNetlarni Microsoft magistrali bo‘ylab shlyuzsiz birlashtiradi; VNet–VNet VPN esa siz joylashtiradigan, o‘lchamini belgilaydigan va kuzatadigan ikki shlyuz orasiga IPsec munosabatini qo‘yadi. Qaror uchta shartga kelib taqaladi va agar marshrut qo‘shishdan oldin uchtasiga ham javob bera olmasangiz, siz hech qachon tanlamagan model uchun aylanma yo‘l qurmoqchisiz.

Modelni belgilovchi uchta shart

Birinchisi — talabdagi biror narsa sizga tegishli va ko‘rsata oladigan IPsec chegarasini talab qiladimi. Ikkinchisi — manzil fazolari toza va ikki VNet faqat bir-biri bilan gaplashishi kerakmi. Uchinchisi — har qanday tranzit yo‘l va shlyuz hisobi kimga tegishli. Shu tartibda javob bering, chunki ikkinchisi qanchalik jozibali ko‘rinmasin, birinchisi peeringni istisno qilishi mumkin.

Ikki modelga umumiy narsa qat’iy manzillash qoidasi: VNet manzil fazolari ustma-ust tushmasligi kerak. Na peering, na VNet–VNet VPN ikki bir xil diapazonni bir ma’noli qilishning qo‘llab-quvvatlanadigan usuli emas, ustma-ust tushish esa boshqa ulanish turini emas, xaritalash loyihasini yoki qayta loyihalashni talab qiladi.

1-shart: sizga o‘zingizga tegishli IPsec chegarasi kerakmi?

Peering trafikni Azurening xususiy magistrali bo‘ylab tashiydi va peered ulanishning o‘zi uchun VPN shlyuzini talab qilmaydi. Bu transport haqidagi bayonot, auditorga «biz IPsec ishlatamiz» deb beriladigan shifrlash bayonoti emas. Agar talab mijoz sozlagan tunnelni, muayyan IKE siyosatini yoki siz nazorat qiladigan uskunada tugaydigan chegarani nomlasa, magistral qanchalik xususiy bo‘lmasin, peering buni qondirmaydi.

VNet–VNet VPN o‘sha chegarani beradi: ikki shlyuz, IPsec/IKE munosabati, umumiy kalitlar va u bilan keladigan butun operatsion yuza. Siz tunnel holatini, shlyuz sig‘imini, SKU cheklovlarini va tunnel ishlayotganini isbotlovchi kuzatuvni meros olasiz. Talab aynan shu chegaraga oid bo‘lganda bu to‘g‘ri javob, u peering sharhida peeringdan alohida ulanish turi sifatida tasvirlangan.

Qarama-qarshi yo‘nalishda ham shunchalik ehtiyot bo‘ling. «Bizga VNetlar orasida shifrlash kerak» ko‘pincha ish yukining o‘z TLS bilan qoplanadi va u holda shlyuz orqasida talab yo‘q xarajat bo‘ladi. Mexanizmni tanlashdan oldin auditor o‘qiydigan gapni yozing.

2-shart: topologiya to‘g‘ridan-to‘g‘rimi yoki nimadir tranzit o‘tishi kerakmi?

Peering tranzitiv emas. Hubga peered qilingan ikki VNet shu bilan bir-biriga ulanmaydi va bir yo‘nalishda ishlayotgandek ko‘ringan marshrut odatda faqat bir tomonda Connected ga yetgan peeringdir. Ikkala tomon ham bo‘lishi va ikkalasi ham Connected ko‘rsatishi kerak, trafik jimgina yo‘qolganda birinchi tekshiriladigan narsa shu.

Talab hub orqali lokal tarmoqqa yetish bo‘lsa, shlyuz tranziti aniq rollarga ega alohida loyiha: hub shlyuzga egalik qiladi, spoke peeringi shlyuz tranzitiga ruxsat beradi va spoke yo‘naltirilgan trafikka ruxsat berishi kerak. Bular peeringdagi xossalar, VNetlarni ulashning avtomatik oqibati emas:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Samarali marshrutlar jadvali «yo‘l bormi?» savoliga halol javob. U platforma haqiqatda ishlatadigan keyingi sakrash turini ko‘rsatadi, shuning uchun sozlangan ko‘ringan, ammo ulanmagan peering sir emas, yo‘q yoki noto‘g‘ri marshrut sifatida ko‘rinadi.

3-shart: tranzit yo‘l va hisob kimga tegishli?

Har bir qo‘shimcha sakrashning egasi bor. Peeringda yangi VNet ikki tomonda yangi peering juftini, tranzit uchun esa trafikni yo‘naltirishda davom etadigan hub va unga ishora qilishda davom etadigan marshrutlar jadvalini anglatadi. VPNda yangi VNet yana bir shlyuz yoki mavjud shlyuzda yana bir ulanish demak, uning o‘z sig‘im chegarasini kuzatish kerak.

Xarajat bir xil shaklga ergashadi, ammo bir xil moddalarga emas: peering to‘lovlari ulanish va ma’lumot uzatish, VPN esa shlyuz soatlarini va o‘z uzatish to‘lovlarini qo‘shadi. Bir yil davomida haqiqatda ishlatadigan topologiya uchun jamini solishtiring, ikkinchi tunnel va kuzatuvni qo‘shgan holda, bugungi bitta ulanish narxini emas. Hech kim hisob-faktura qilmaydigan mehnatni ham qo‘shing: kimdir kalitlarni almashtirishi, tunnel holatini kuzatishi va shlyuz qayta ishga tushganda tungi uchda ogohlantirishga javob berishi kerak. Odatda aynan shu modda bahsni hal qiladi, chunki taklif nomada hech qachon ko‘rinmaydigan yagona modda shu.

Nimani tanlamang, uchta oqimni sinab ko‘ring: mo‘ljallangani, rad etilgan holda qolishi kerak bo‘lgani va hub shlyuzi yoki peering ishlamay qolgan tiklanish holati. Faqat baxtli yo‘lni tushuntiruvchi model tasdiqlanmagan, namoyish etilgan.

Tanlovni uning o‘z da’vosiga qarshi tekshiring

Model, chegara va egasini nomlovchi bitta gap yozing, so‘ng joylashtirilgan holat unga mos kelishini tekshiring. Peering uchun bu ikkala peering holati Connected, samarali marshrut manzil prefiksi uchun peeringning keyingi sakrashini ko‘rsatishi va yo‘lda shlyuz yo‘qligi demak. VNet–VNet VPN uchun bu ikkala ulanish Connected, ikki shlyuzda mos kalitlar va siyosatlar hamda keyingi sakrashi virtual tarmoq shlyuzi bo‘lgan marshrut demak.

Agar tekshiruvlar gapga zid bo‘lsa, avval gapni tuzating. Bu loyihalardagi chalkashlikning ko‘p qismi hech kim tasvirlamagan gibriddan keladi: ish yuki quyi tarmog‘i uchun peering, bitta eski xizmat uchun VPN va jimgina birini afzal ko‘radigan marshrutlar jadvali.