Portaldaki sanal ağı açın ve alt ağ dikey penceresine dokunmadan önce adres alanına bakın. O /24 zaten iş yükü alt ağlarına bölünmüşse ve boş yer kalmadıysa /27 ayırmaya yer yoktur; sonunda ya yeniden bölersiniz ya da VNet’i genişletirsiniz, bu da başka bir inceleme gerektiren başka bir değişikliktir. Önce alanı belirleyin, sonra alt ağı oluşturun.

Bu sıra önemlidir çünkü ağ geçidi alt ağı özel adlı bir iş yükü alt ağı değildir. Yönetilen ağ geçidi örnekleri için adres ayırmadır ve ayırma yanlışsa Azure ağ geçidini reddeder.

Adres alanıyla başlayın

Bir şey yazmadan önce VNet önekini, iş yükü alt ağlarını ve ağ geçidi ayırmasını tek satıra yazın. 10.60.0.0/16 üzerindeki bir VNet’te yer vardır; iş yükü büyümesi bitişik kalsın diye sonunda bir aralık seçin.

Örneğin, 10.60.255.192/26 ağ geçidi için 64 adres bırakırken iş yükleri 10.60.0.0/20 içinde kalır. Bu bir adres planlama örneğidir, boyut vaadi değildir. Microsoft şu anda Basic olmayan VPN ağ geçitleri için /27 veya daha büyüğünü şart koşar; burada daha büyük daha fazla adres demektir: /26 64 verirken /28 16 verir. Adres planı hâlâ hareket ederken yukarı yuvarlayın, asla aşağı değil.

Alt ağı tam adla oluşturun

Portalda bir alt ağ ekleyin ve GatewaySubnet adını tam olarak yazın: büyük G ve büyük S, boşluk veya son ek olmadan. Azure bu dizeyi eşler, bu nedenle Gateway-Subnet veya gateway ağ geçidi hizmetinin kullanmayacağı bir alt ağ üretir.

Aynı adım CLI’dan, incelemeye yazması daha kolay:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

Alt ağı boş bırakın. VM yok, özel uç nokta yok, hizmet delegasyonu yok. Orada zaten bir şey yaşıyorsa dağıtım başarısız olur ve hata yolu tıkayan kaynağı nadiren adlandırır, bu nedenle başlamadan önce alt ağın kaynak listesini kontrol edin.

Yönetilen alt ağı iş yükü kurallarından uzak tutun

Bu alt ağa ağ güvenlik grubu eklemeyin; Microsoft bunu desteklenmiyor olarak işaretler. Varsayılan rotası 0.0.0.0/0’ı bir yere gönderen bir rota tablosunu ilişkilendirmeyin, çünkü bu ağ geçidinin çalışmasını bozabilir; ağ geçidi rota yayılımını açık tutun.

Gerçekten istediğiniz erişim kısıtlamalarını iş yükü alt ağına veya bir denetim sınırına koyun. GatewaySubnet’i sıradan bir alt ağ gibi ele almak, temiz dağıtılan ve ardından hiç trafik geçirmeyen bir ağ geçidi üreten hatadır.

Zorunlu tünellemenin kendi belgelenmiş tasarımı vardır. Ağ geçidi alt ağında doğaçlama yapılmış varsayılan rota o değildir.

Portalın göstermediği bağımlılıkları kontrol edin

Oluştur’a basmadan önce listeyi gezin: tam ad, VNet alanı içinde önek, şirket içi aralıklarla çakışma yok, içinde iş yükü kaynağı yok, NSG yok ve varsayılan rotası olan rota tablosu yok. Bunların her biri gerçek bir dağıtımı bozmuştur. Ardından daha geniş tasarımı doğrulayın: şirket içi taraf için yerel ağ geçidi, yönlendirmeyi beklediğiniz adres alanları ve etkin-etkin mi yoksa birlikte var olma mı planlandığı. Bu seçimler boyut konuşmasını değiştirir ve bunları şimdi netleştirmek çok daha ucuzdur.

Birisi alt ağın neden VM barındıramadığını sorduğunda alıntılanacak sayfa Azure ağ geçidi ayarları başvurusu.

Ağ geçidi zaten varsa

Bir ağ geçidi alt ağını yeniden boyutlandırmak veya değiştirmek maske düzenlemesi değildir. Önce ağ geçidinin SKU’su ve nesli için desteklenen değişiklik prosedürünü kontrol edin ve bağımlı nesneleri listeleyin: bağlantılar, genel IP’ler, yönlendirme ve herhangi bir kurtarma gereksinimi.

Prosedür ağ geçidinin yeniden oluşturulmasını gerektiriyorsa, bunu bir pencere ve geri alma ile hizmet geçişi olarak planlayın. Seçtiğiniz ayırmayı, boyutun gerekçesini ve bilerek eklemediğiniz kuralları kaydedin; böylece sonraki gözden geçiren boş alt ağı NSG ekleyerek düzeltmez.

İlgili makaleler