Azure saytdan saytga VPN trafigida NSG qayerda qo‘llaniladi

Saytdan saytga tunnel ishlayapti, mahalliy mijoz Azurening ayrim hostlariga yetib bormoqda, boshqalariga esa yo‘q, va kimdir buni tuzatish uchun GatewaySubnetga tarmoq xavfsizlik guruhini ulagan. Shu yerda to‘xtang. Azure GatewaySubnetda NSGni qo‘llab-quvvatlamaydi, guruh esa ish yuklamasi qoidasi kabi ichki paketni ko‘ra olmaydi. Siyosatni maqsadli subnetka yoki NICga joylashtiring, shifrlashdan keyin mavjud bo‘lgan manba manzilini moslang, so‘ngra eski emas, yangi ulanish bilan tekshiring.

NSGni Azure uni baholaydigan joyga qo‘ying

Ish yuklamasini filtrlashning qo‘llab-quvvatlanadigan chegarasi maqsadli subnet yoki maqsadli tarmoq interfeysidir. Shlyuz subneti infratuzilmadir va Azure u yerda NSG qo‘llab-quvvatlanmasligini hamda shlyuz ishiga zarar yetkazishi mumkinligini hujjatlashtiradi.

Joylashtirishda mantiqiy muammo ham bor. GatewaySubnetdagi NSG tashqi IPsec almashinuvini baholaydi, uning manzillari ikki shlyuzga tegishli. Ilovangiz qoidasiga tunnel ichidagi xususiy manba kerak, bu paket esa shlyuz uni shifrdan chiqargandan keyingina mavjud bo‘ladi. Guruhni ish yuklamasi subnetiga ulang, qoida yozilgan manzilni ko‘radi.

Biror narsani o‘zgartirishdan oldin joriy bog‘lanishlarni tekshiring, nimalarni ko‘chirayotganingizni bilish uchun:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Shifrlashdan keyin manba manzilini toping

Ichki manba mahalliy mijozning xususiy manzili yoki qurilma yoxud VPN NAT tarjimadan keyin taqdim etadigan manzildir. Bu mahalliy VPN shlyuzining ommaviy manzili emas, u tashqi almashinuvga tegishli.

NAT loyihaning qismi bo‘lsa, taxmin qilish o‘rniga taqdim etilgan manbani tasdiqlang. Azure VMda paket tutish yoki xizmatning ulanish jurnalida manba maydoni savolni mahalliy konfiguratsiyani o‘qishdan tezroq hal qiladi. So‘ngra qoidani shu manzil va haqiqiy maqsadli portga qarshi yozing.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Ochmoqchi bo‘lgan har bir xizmat uchun bitta qoida ishlating va portlar ro‘yxatini qisqa tuting. Mahalliy diapazondan barcha portlarga ruxsat beradigan qoida NSGni rasmiyatchilikka aylantiradi.

Standart VirtualNetwork qamrovini tekshiring

VirtualNetwork xizmat tegi mahalliy virtual tarmoqdan kengroq. Uning tavsifi ulangan mahalliy manzil maydonlarini, peering tarmoqlarini va shlyuz orqali ulangan boshqa prefikslarni o‘z ichiga oladi. Shuning uchun VirtualNetwork bilan cheklangan standart ruxsat qoidasi operator tashqi deb hisoblagan tunnel trafigiga allaqachon ruxsat berishi mumkin.

Tor qoidalar qo‘shishdan oldin standart qoidalarni o‘qing va birinchi mos kelishi mumkin bo‘lgan har bir yuqori ustuvor qoidani o‘qing. Aniq ruxsat qo‘shish oqimga allaqachon ruxsat beradigan kengroq qoidani olib tashlamaydi. Siyosat taqiq talab qiladigan joyda uni ruxsatdan oldin haqiqatan baholanadigan ustuvorlikka qo‘ying.

Microsoftning xizmat teglari hujjati VirtualNetwork tegi nimani qamrab olishini sanab o‘tadi va teg faqat VNet diapazonini bildiradi deb bahslashganda murojaat qilinadigan manba shudir.

Ikkala chegarada amaldagi qoidalarni o‘qing

Subnet NSG va NIC NSG ikkalasi ham amal qilganda, oqim ikkalasini ham qondirishi kerak. Biridagi ruxsat ikkinchisidagi taqiqni bekor qilmaydi va paket haqiqatda birlashtirilgan ko‘rinishga duch keladi.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Agar Azure Virtual Network Manager xavfsizlik administratori qoidalari ishtirok etsa, o‘sha qatlamni ham ko‘rib chiqing. Administratorning Always allow qoidasi trafikni NSG baholashisiz yetkazishi mumkin, administratorning Deny esa NSGlar ko‘rishidan oldin uni to‘xtatadi. Bunday tuzilma uchun faqat NSG tekshiruvi to‘liq emas.

NSGlar holatni saqlashini unutmang. Qoidani tahrirlash mavjud ruxsat etilgan ulanishni albatta tugatmaydi, shuning uchun qabul sinovi yangi oqimni talab qiladi. Bu xususiyat ishlab chiqarishda foydali, o‘zgarish oynasida esa chalg‘ituvchi.

Yangi ulanish bilan tekshiring

Mahalliy mijozdan xizmat portiga yangi sessiya oching, so‘ngra rad etilishi kerak bo‘lgan hostdan takrorlang. Oqim sinovini VM tomonidan ham ishga tushiring, qaytish yo‘li butun ekanini bilish uchun.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG ruxsati bitta kirish qaroridir, yo‘l ham emas, tinglovchi ham emas. Agar qoida oqimga ruxsat bersa-yu, ulanish baribir muvaffaqiyatsiz bo‘lsa, guruhni qayta tahrirlashdan oldin mijozning VPNga yo‘lini, Azurening qaytish yo‘lini va hostning xavfsizlik devorini tekshiring. Haqiqiy manba manzilini, NSG bog‘lanishlarini va mos keladigan qoidani tasdiqlangan xizmat bilan birga yozib qo‘ying, chunki keyingi peering yoki yo‘l o‘zgarishi VirtualNetwork tegi qamrab oladigan narsani o‘zgartirishi mumkin.