Azure P2S DNS resolver tenglashtirilgan VNet ichida bo‘lsa, ishlamaydi

VM ga ping yuboring — u javob beradi; nomini so‘rang — mijoz host noma’lum deydi. Resolver VPN gateway joylashgan tarmoqda emas, tenglashtirilgan virtual tarmoqda bo‘lsa, bu ikki natija kutilgan holat, va resolverni qanchalik tekshirmang, u o‘zgarmaydi. Yetishmayotgani — peering sukut bo‘yicha ushlab turadigan marshrutlash shartnomasi. Ikki topologiya qog‘ozda deyarli bir xil ko‘rinadi, ishlaydigan va buzilgan orasidagi farq esa to‘g‘ri yo‘nalishda qo‘yilgan bir juft peering kalitidir.

Tasavvur qiling, noutbuk VNet2 dagi gateway ga tunnel ochadi, DNS xizmat ko‘rsatuvchi domen kontrolleri esa VNet1 da o‘tiradi.

Ikki topologiya, bitta farq

Resolverni gateway ning o‘z virtual tarmog‘iga qo‘ying — tunnel ko‘tarilgan zahoti nom hal bo‘ladi. Bu qidiruvda hech qanday peering sozlamasi qatnashmaydi.

Xuddi shu resolverni peering ning narigi tomoniga ko‘chiring — mijoz baribir VM dan javob oladi, nom esa noma’lumligicha qoladi. Sertifikat, tunnel va mijoz o‘zgarmagan. Ko‘chgan yagona narsa — resolver qayerda yashashi. Peering unga o‘sha manzilga marshrut berdi, gateway ga u yerga trafik tashish huquqini emas.

A tomon: gateway egasida gateway tranzitiga ruxsat bering

Peering ikki virtual tarmoqni birlashtiradi, lekin bu birlashuv gateway orqali keladigan trafik uchun o‘tkazuvchi emas, point-to-site so‘rovi esa aynan shunday keladi. Shuning uchun VNet2 dagi gateway dizayn ruxsat bermaguncha qidiruvni VNet1 ga topshirishga haqli emas. Ruxsat — gateway joylashgan tarmoqqa tegishli peering dagi kalit.

VNet2 dan VNet1 tomon peering da Allow gateway transit ni o‘rnating. Bu xususiyat gateway resursiga emas, peering obyektiga tegishli, shuning uchun uni peering pichoqchasida o‘qib, o‘zgartirasiz. Butun A tomon shu.

B tomon: hamkorda uzoq gateway lardan foydalaning

Ikkinchi yarmi — ko‘zgu aksi: VNet1 dan VNet2 ga qaytuvchi peering da Use remote gateways ni yoqing. Xuddi shu bayroqni ikki uchida yoki faqat bittasida yoqish yarim qurilgan yo‘lni va dastlabki belgini tegilmagan holda qoldiradi. Faqat VPN gateway bor tarmoq tranzitga ruxsat beradi, hamkor esa undan foydalanadigan tomon.

Oxirgi ochgan portal pichoqchasiga ishonish o‘rniga ikki tarmoqda ikki xususiyatni o‘qing.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Juftni yonma-yon ko‘rish — teskari sozlamani tutishning eng tez yo‘li. Gateway tomonida AllowGatewayTransit false deb xabar beruvchi peering butun nosozlikni paket tutmasdan tushuntiradi.

Mijoz hali nima olishi kerak

Marshrutlash zarur, lekin yetarli emas, chunki point-to-site profili mijozga tranzit ishlagandan keyin javob beradigan DNS manzilini ham berishi kerak. Platforma resolveri bu manzil emas: u virtual tarmoqqa bog‘langan Azure Private DNS zonalariga javob beradi, lekin o‘z katalog serverlaringizda joylashgan zonaga hech narsa bermaydi, va bu joylashtirish aynan shundan foydalanadi. Mijozni u yerga yo‘naltiring — ommaviy nomlar xursandchilik bilan hal bo‘ladi, ichki host esa noma’lumligicha qoladi.

Boshqa narsani o‘zgartirishdan oldin ulangan noutbukdan resolverga so‘rov yuboring.

nslookup dc01.corp.example 10.1.0.4

Vaqt tugashi yo‘l hali yo‘qligini aytadi. Vakolatli javob muammoni mijozga qaytaradi, odatda hech qachon qo‘shilmaydigan qo‘shimcha, shuning uchun qisqa nomlar ularni xursandchilik bilan muvaffaqiyatsiz qiladigan ommaviy resolverga boradi.

Xuddi shu shartnomani sayt-sayt tomonida taqqoslang

Bularning hech biri ayniqsa noutbuklarga tegishli emas. Mijozni sayt-sayt filiali bilan almashtiring — ikki tomonlama talab qaytadi: filial gateway tarmog‘iga to‘g‘ridan-to‘g‘ri keladi, ikki tarmoq uzoqdagi xizmat esa hali peering orqasida.

Tranzit ikki peering da berilishi kerak, uni beradigan kalit esa mijoz turida emas, peering da turadi.

Gateway ni ayblashdan oldin

Windows har bir adapter uchun resolver ro‘yxatini saqlaydi, shuning uchun gateway ni ayblashdan oldin tunnel interfeysi haqiqatda nima olganini tasdiqlang.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Salbiy javob keshda marshrutlash tuzatishidan uzoq yashaydi, eskirgan qo‘shimcha ro‘yxati esa so‘rovlarni zona hech qachon joylashmagan joyga yuborishda davom etadi. Tozalang, yana so‘rang va qaysi server javob berishini yozib qo‘ying.

Yo‘l bardosh berishini ikki kichik shart hal qiladi: manzil maydonlari bir-biriga ustma-ust tushmasligi kerak, va resolver ning quyi tarmog‘idagi tarmoq xavfsizlik guruhi mijoz hovuzini o‘tkazishi kerak, bu shunchaki yana bir manba diapazoni. Buni VM tomondan samarali marshrut tekshiruvi va mijozdan bitta to‘g‘ridan-to‘g‘ri so‘rov bilan isbotlang, shunda zona muammosi, qo‘shimcha muammosi yoki filtr hech qachon yo‘q tranzit bilan aralashtirilmasin.