Afsona shuki, ExpressRoute xususiy peering orqali trafikni shifrlash uchun virtual tarmoq qurilmasi kerak. Kerak emas. Azure tunnel oxiri sxema bo‘ylab olib o‘tiladigan xususiy RFC1918 manzil bo‘lgan Site-to-Site VPN Gatewayni qo‘llab-quvvatlaydi va qurilma tizimli emas, ixtiyoriydir. Qurilma afsonasi yashirgan narsa — haqiqatan og‘riq beradigan qism: xususiy oxirni ikkita obyekt o‘rniga bittasida yoqish va to‘g‘ridan-to‘g‘ri peering yo‘li shifrlangan yo‘ldan jimgina ustun kelishiga yo‘l qo‘yish.

Afsona qayerdan kelgan

Daʼvoning hurmatli asosi bor. Yillar davomida xususiy peering ustidagi IPsec uchun amaliy retsept NVA edi, chunki boshqariladigan shlyuz faqat ommaviy oxirlarni ko‘rsatardi. Bu o‘zgardi va o‘zgarishdan oldin yozilgan javoblar hali ham sanani hech kim tekshirmaydigan mavzularda keltiriladi. Tuzatish tor: xususiy manzilli VPN shlyuzi mavjud va u oxirni o‘zgartiradi, atrofidagi marshrutlash mantiqini emas.

Bularning hech biri NVAni nafaqaga chiqarmaydi. U qurilma talabga erishishning yagona yo‘li degan farazni nafaqaga chiqaradi.

Xususiy oxirni ikkala darajada yoqing

VPN shlyuzi joylashgan VNet bilan bog‘langan ishlaydigan ExpressRoute xususiy peering ulanishidan boshlang. Mahalliy tomon allaqachon o‘sha sxema orqali tegishli xususiy manzillarga yetib borishi kerak, chunki tunnel bu manzillarni tashish sifatida ishlatadi. So‘ngra shlyuz sharti: xususiy IP VPN uchun Microsoft tartibi Standard ommaviy IP resursi ustiga qurilgan shlyuzni talab qiladi. Xususiy tunnel manzillash bu shartni olib tashlamaydi, bu «xususiy» degani «hech qayerda ommaviy IP yo‘q» deb o‘ylaydiganlarni hayratda qoldiradi.

Endi bayroqni ikkala joyda yoqing. Shlyuz konfiguratsiyasining xususiy IPlar uchun o‘z kaliti bor, alohida Site-to-Site ulanishining esa o‘sha ulanishni xususiy manzildan foydalanishga majbur qiladigan ikkinchi kaliti bor. Birini sozlash va ikkinchisini sozlamaslik eng keng tarqalgan to‘liq bo‘lmagan konfiguratsiyadir; tunnel yo qurilmaydi, yo noto‘g‘ri oxirga quriladi.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

O‘rnatilgan CLI versiyasiga qarshi xususiyat nomlarini tekshiring, chunki portal yorliqlari va CLI xususiyatlari har doim bir xil iborani ishlatmaydi. Faol-faol shlyuz ikkita xususiy tunnel manzilini taqdim etadi va bu ortiqchalik mazmunli bo‘lishi uchun mahalliy qurilmada ikkala hamkor ham sozlangan bo‘lishi kerak. Faqat shu xususiy manzilli tunnelni ko‘tarish uchun BGP shart emas, garchi u odatda prefikslarni tarqatish usulining bir qismidir.

Ikkinchi afsona: o‘rnatilgan tunnel trafigingizni shifrlaydi

Endi ilova tarmog‘iga ikki yo‘l yetib boradi: to‘g‘ridan-to‘g‘ri xususiy peering yo‘li va VPN orqali yo‘l. Ikkalasi ham ishlaydi. Faqat bittasi bu IPsec qatlamini qo‘llaydi. Microsoft hujjatlashtiradiki, bir xil prefikslar ExpressRoute va VPN orqali eʼlon qilinganda Azure to‘g‘ridan-to‘g‘ri ExpressRoute yo‘lini afzal ko‘radi, shuning uchun sog‘lom tunnel va sog‘lom hisoblagichlar ilova paketlari qayerga ketganini hech narsa isbotlamaydi.

Hujjatlashtirilgan yo‘naltirish usullari ExpressRoute ustida qamrovchi diapazon va VPN ustida aniqroq himoyalangan diapazon yoki ikki yo‘lda ajralgan prefikslardir. Masalan, xususiy peering 10.40.0.0/16 olib yurishi mumkin, VPN esa 10.40.12.0/24 eʼlon qiladi. Aniqroq prefiks yutadi va diapazonning qolgani to‘g‘ridan-to‘g‘ri qoladi.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Xuddi shu tekshiruvni mahalliy yo‘nalishda ham qiling, chunki chiquvchi trafik qaysi tomondan chiqishini routeringizning afzalligi hal qiladi. Va tunnelning o‘z tashishini ExpressRoute yo‘lida saqlang; shlyuzning xususiy oxirini tunnel ichiga tortadigan marshrut tunnelni o‘ziga qaram qiladi.

Tunnel yiqilganda nima bo‘lishini hal qiling

Tunnel yiqilganda aniqroq VPN marshruti yo‘qoladi, kengroq to‘g‘ridan-to‘g‘ri marshrut qoladi. Shunda trafik shifrlashsiz oqadi va hamma narsa sog‘lom ko‘rinadi, bu shifrlashni kafolatlash uchun mavjud talab uchun eng yomon nosozlik rejimi. Agar talab bu qaytishni taqiqlasa, marshrutlash va kirish siyosati tunnel mavjudligiga tayanish o‘rniga buni aniq aytishi kerak.

Qaysi prefikslar to‘g‘ridan-to‘g‘ri yetib boriladigan bo‘lib qolishi va qaysilari shifrlangan yo‘l yo‘q bo‘lganda to‘xtashi kerakligini yozib qo‘ying. So‘ngra ruxsat etilgan holatni haqiqiy trafik bilan sinab ko‘ring va ulanish hisoblagichlarini solishtiring, chunki faqat marshrut jadvali shifrlash talabi hali amalda ekanini aytmaydi.

Bu ramka NVAni oxir xususiy bo‘lgani uchun sotib olish o‘rniga, uning haqiqiy funksiyalari bo‘yicha baholashga ham imkon beradi, masalan, bir nechta tunnel, o‘tkazuvchanlik yoki yetkazib beruvchi tekshiruvi.

O'xshash maqolalar