Azure siteden siteye VPN trafiğinde NSG'ler nereye uygulanır

Siteden siteye tünel çalışıyor, şirket içi istemci bazı Azure ana makinelerine ulaşıyor bazılarına ulaşmıyor ve biri bunu düzeltmek için GatewaySubnet'e bir ağ güvenlik grubu eklemiş. Orada durun. Azure, GatewaySubnet üzerinde NSG'yi desteklemez ve grup, iç paketi bir iş yükü kuralının gördüğü gibi göremez. İlkeyi hedef alt ağa veya NIC'e koyun, şifre çözüldükten sonra var olan kaynak adresini eşleştirin ve ardından eski değil yeni bir bağlantıyla doğrulayın.

NSG'yi Azure'un değerlendirdiği yere koyun

İş yükü filtrelemesi için desteklenen sınır hedef alt ağ veya hedef ağ arabirimidir. Ağ geçidi alt ağı altyapıdır ve Azure, NSG'lerin orada desteklenmediğini ve ağ geçidinin çalışmasını bozabileceğini belgeler.

Yerleşimde bir mantık sorunu da var. GatewaySubnet'teki NSG, adresleri iki ağ geçidine ait olan dış IPsec alışverişini değerlendirirdi. Uygulama kuralınız tünelin içindeki özel kaynağa ihtiyaç duyar ve bu paket ancak ağ geçidi onu şifresini çözdükten sonra var olur. Grubu iş yükü alt ağına bağlayın, kural yazıldığı adresi görür.

Herhangi bir şeyi değiştirmeden önce mevcut ilişkilendirmeleri kontrol edin, neyi taşıdığınızı bilmek için:

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

Şifre çözüldükten sonra kaynak adresini bulun

İç kaynak, şirket içi istemcinin özel adresi veya bir cihazın ya da VPN NAT'ının çeviriden sonra sunduğu adrestir. Şirket içi VPN ağ geçidinin genel adresi değildir; o dış alışverişe aittir.

NAT tasarımın parçasıysa, varsaymak yerine sunulan kaynağı doğrulayın. Azure VM'inde paket yakalama veya hizmetin bağlantı günlüğündeki kaynak alanı soruyu yerel yapılandırmayı okumaktan daha hızlı çözer. Ardından kuralı o adrese ve gerçek hedef bağlantı noktasına göre yazın.

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

Açığa çıkarmak istediğiniz her hizmet için bir kural kullanın ve bağlantı noktası listesini kısa tutun. Yerel aralıktan tüm bağlantı noktalarına izin veren bir kural NSG'yi formaliteye çevirir.

Varsayılan VirtualNetwork kapsamını kontrol edin

VirtualNetwork hizmet etiketi yerel sanal ağdan daha geniştir. Tanımı bağlı şirket içi adres alanlarını, eşlenmiş ağları ve ağ geçidinden bağlanan diğer önekleri içerir. Bu nedenle VirtualNetwork ile sınırlanmış varsayılan izin kuralı, operatörün dışsal saydığı tünel trafiğine zaten izin verebilir.

Dar kurallar eklemeden önce varsayılan kuralları okuyun ve önce eşleşebilecek her yüksek öncelikli kuralı okuyun. Açık bir izin eklemek, akışa zaten izin veren daha geniş bir kuralı kaldırmaz. İlkenin ret gerektirdiği yerde, izinden önce gerçekten değerlendirilen bir önceliğe koyun.

Microsoft'un hizmet etiketleri belgeleri VirtualNetwork etiketinin neyi kapsadığını listeler ve biri etiketin yalnızca VNet aralığı anlamına geldiğini savunduğunda başvurulacak kaynak budur.

Etkin kuralları iki sınırda da okuyun

Hem alt ağ NSG'si hem de NIC NSG'si geçerli olduğunda akış ikisini de karşılamalıdır. Birindeki izin diğerindeki reddi geçersiz kılmaz ve paketin gerçekten karşılaştığı şey birleşik görünümdür.

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

Azure Virtual Network Manager güvenlik yöneticisi kuralları devredeyse o katmanı da gözden geçirin. Yönetici Always allow kuralı trafiği NSG değerlendirmesi olmadan iletebilir, yönetici Deny ise NSG'ler görmeden önce durdurur. Böyle bir düzen için yalnızca NSG incelemesi eksiktir.

NSG'lerin durum tuttuğunu unutmayın. Bir kuralı düzenlemek mevcut izinli bağlantıyı mutlaka sonlandırmaz, bu yüzden kabul testi yeni bir akış gerektirir. Bu özellik üretimde yararlı, değişiklik penceresinde yanıltıcıdır.

Yeni bir bağlantıyla doğrulayın

Şirket içi istemciden hizmet bağlantı noktasına yeni bir oturum açın, sonra reddedilmesi gereken bir ana makineden yineleyin. Akış testini VM tarafından da çalıştırın, dönüş yolunun sağlam olduğunu bilmek için.

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 izni tek bir erişim kararıdır, rota değil ve dinleyici değil. Kural akışa izin veriyor ama bağlantı yine başarısız oluyorsa, grubu yeniden düzenlemeden önce istemcinin VPN'e giden rotasını, Azure'un dönüş rotasını ve ana makinenin güvenlik duvarını kontrol edin. Gerçek kaynak adresini, NSG ilişkilendirmelerini ve eşleşen kuralı onaylanmış hizmetle birlikte kaydedin, çünkü sonraki eşleme veya rota değişikliği VirtualNetwork etiketinin kapsamını değiştirebilir.