Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Azure sanal ağlar (sanal ağlar) ve alt ağlar, her Azure ağının temel yapı taşlarıdır. Bu makalede sanal ağların yalıtım sağlama şekli, alt ağların kaynakları nasıl düzenlediği ve üretim iş yükleri için ağınızı nasıl boyutlandırıp yapılandıracakları açıklanmaktadır.
Bu makalenin kapsamı
Bu makalede sanal ağ yalıtım sınırları, alt ağ boyutlandırma ve ayrılmış adresler, Azure Güvenlik Duvarı ve Application Gateway, VNet eşlemesi ve ortak ağ düzeni desenleri gibi hizmetler için ayrılmış platform alt ağları ele alınır.
Bu makaleye kimin ihtiyacı var?
Aşağıdakiler varsa bu makaleyi okuyun:
- İlk iş yükünüzü Azure dağıtıyor ve kaynakları oluşturmadan önce ağların nasıl çalıştığını anlamanız gerekiyor.
- Çok iş yüküne sahip bir ortam planlıyor ve kaç sanal ağ ve alt ağ oluşturulacağını belirlemesi gerekiyor.
- Şirket içi iş yüklerini Azure’a geçiriyor ve Azure ağ yapısının fiziksel ağ altyapısından nasıl farklı olduğunu anlamanız mı gerekiyor?
- Azure Güvenlik Duvarı, VPN Gateway veya Azure Kubernetes Service (AKS) gibi Azure platform hizmetleri için alt ağların doğru boyutlandırılması gerekir.
- İş yüklerini ne zaman farklı VNet’lere ayırmak, ne zaman aynı VNet’te tutmak gerektiğini anlamak mı istiyorsunuz?
Lift-and-shift odağı: Şirket içi alt ağ segmentasyonunuzu Azure’da yansıtın. Mevcut VLAN'ları ve güvenlik bölgelerini alt ağlarla eşleyin, adres alanlarını ekibinizin zaten çalıştığı aralıklarla uyumlu tutun ve geçiş sırasında yeniden adreslemeniz gerekmeyecek şekilde alt ağları cömert bir şekilde boyutlandırabilirsiniz.
Odağı modernleştirin: Platform hizmetleri ve otomasyon etrafında alt ağlar tasarlama. AKS, özel uç noktalar ve adanmış platform hizmetleri için alt ağları doğru boyutlandırın ve Azure Sanal Ağ Yöneticisi’ın çok sayıda VNet genelinde tutarlı yapılandırma uygulaması için planlama yapın.
Çoklu bulut odağı: Herhangi bir VNet oluşturmadan önce Azure, AWS ve Google Cloud'da örtüşmeyen adres alanlarını planlayın. MEVCUT VPC'lerle çakışmadan CIDR aralıklarını ayırarak NAT olmadan bulutları eşleyebilir veya VPN ile bağlayabilirsiniz.
Azure hizmetleri ve özellikleri
Aşağıdaki hizmetler ve özellikler, Azure'da sanal ağ temelini oluşturur:
| Hizmet veya Özellik | Ne sağlar? | Ne zaman kullanılır? |
|---|---|---|
| Azure Sanal Ağ (VNet) | Azure'da yalıtılmış, özel bir ağ. Tüm Azure ağ iletişimi burada başlar. Aynı sanal ağ içindeki kaynaklar varsayılan olarak iletişim kurabilir; farklı sanal ağlardaki kaynaklar açıkça bağlanmadığınız sürece iletişim kuramaz. | Her zaman: Ağ bağlantısı gerektiren her iş yükü için bir sanal ağ gerekir. |
| Subnet | VNet adres alanının bir bölümü. Alt ağlar, ağ güvenlik grubu (NSG) ve yönlendirme tablosu ilişkilendirmesinin kapsamıdır. | Her zaman: İş yükü bileşenlerini işlev veya güvenlik sınırına göre alt ağlar halinde düzenleyin. |
| VNet eşlemesi | Aynı bölgedeki veya farklı bölgelerdeki iki VNet arasında düşük gecikmeli, özel bağlantı. Trafik Microsoft omurgasında kalır. Eşleme geçişli değildir; her eşleme doğrudan bağlantıdır. | Ayrı sanal ağlardaki kaynakların iletişim kurması gerektiğinde. Bölgeler arası eşleme için bkz. Bölgeler arası bağlantı. |
| Alt ağ eşleştirmesi (önizleme) | Sanal ağların tamamı yerine belirli alt ağlar arasında eşleme. Eşleme ilişkilerine hangi alt ağların katılacağı üzerinde ayrıntılı denetim sağlar. | Farklı sanal ağlardaki belirli alt ağlar arasında ayrıntılı eşleme denetimine ihtiyacınız olduğunda. Kısıtlamalar bölümüne bakın. |
| Yol tablosu / Kullanıcı Tanımlı Yollar (UDR) | Trafiğin nereye gönderileceğini denetlemek için Azure'daki varsayılan sistem yollarını geçersiz kılın. Alt ağ düzeyinde uygulanır. | Trafiği bir güvenlik duvarı veya sanal ağ gereci (NVA) üzerinden yönlendirmeniz gerektiğinde. Merkez-uç çıkış denetimi için gereklidir. Bkz. Azure Güvenlik Duvarı tasarım ve Merkez-uç topolojisi. |
| Azure Sanal Ağ Yöneticisi (AVNM) | Abonelikler genelindeki VNets'ler için ağ yapılandırmalarını merkezi olarak oluşturun, yönetin ve uygulayın. | Birden çok abonelikte birçok VNet’i yönetirken. Bkz. Merkezi ağ yönetimi. |
Nasıl seçilir?
Sanal ağ nedir?
Sanal ağ (VNet), Azure yazılım tanımlı, yalıtılmış bir ağdır. Bunu Azure'daki özel ağınız olarak düşünün. Kablo, anahtar ve yönlendirici kullanan fiziksel ağlardan farklı olarak, sanal ağ tamamen yazılım tanımlıdır. Bunu oluşturur, bir adres alanı atar ve kaynakları buna dağıtırsınız.
Temel özellikler:
- Bölge kapsamındaki: Bir sanal ağ tek bir Azure bölgesinde bulunur. Bu sanal ağ içindeki tüm kaynaklar aynı bölgede olmalıdır. Bir VNet, o bölge içindeki kullanılabilirlik bölgelerini kapsar.
- Varsayılan olarak yalıtım: Açıkça bağlantı (eşleme veya VPN) oluşturmadığınız sürece, bir sanal ağdaki kaynaklar başka bir sanal ağdaki kaynaklarla iletişim kuramaz.
- Varsayılan iç bağlantı: Aynı sanal ağ içindeki kaynaklar, Azure tarafından sağlanan sistem yolları aracılığıyla varsayılan olarak birbirleriyle iletişim kurabilir.
Alt ağ nedir?
Alt ağ, sanal ağınızdaki bir IP adresi aralığıdır. Alt ağlar aşağıdakilere izin verir:
- Ağınızı iş yükü bileşenlerine göre segmentlere ayırın (örneğin, web katmanı, uygulama katmanı, veri katmanı).
- Güvenlik kurallarını uygulama: NSG'ler, trafiği filtrelemek için alt ağ düzeyinde eklenir.
- Denetim yönlendirme: yönlendirme tabloları, trafiği yönlendirmek için alt ağ düzeyinde eklenir.
Azure her alt ağda beş IP adresi ayırır: ilk dört adres ve son adres. Örneğin, bir /24 alt asında (256 adres) yalnızca 251 kullanılabilir. Bu rezervasyonu boyutlandırma hesaplamalarınıza dahil edin.
Örnek: Üç katmanlı uygulama
Tipik bir üç katmanlı web uygulaması, endişeleri ayırmak ve ayrı güvenlik kuralları uygulamak için üç alt ağ kullanır:
| Subnet | CIDR aralığı | Purpose | Örnek kaynaklar |
|---|---|---|---|
web-subnet |
10.0.1.0/24 | İnternet'ten veya Application Gateway'den gelen HTTP/HTTPS trafiğini kabul eden ön uç web sunucuları | Azure App Service Ortamı, NGINX çalıştıran Sanal Makine Ölçek Kümeleri |
app-subnet |
10.0.2.0/24 | Orta katman uygulama mantığı. Yalnızca web alt ağından gelen trafiği kabul eder. | Azure İşlevleri (sanal ağ ile tümleşik), iş mantığı çalıştıran VM'ler |
data-subnet |
10.0.3.0/24 | Veri depoları. Yalnızca uygulama alt ağından gelen trafiği kabul eder. Doğrudan İnternet erişimi yok. | Azure SQL Yönetilen Örneği, Azure SQL Veritabanı veya Cosmos DB için özel uç noktalar |
Bu düzen, trafiği yalnızca bu katmanın ihtiyaç duyduğu durumla kısıtlayan her alt ağa bir NSG uygulamanızı sağlar. Web alt ağı gelen HTTPS'ye (bağlantı noktası 443) izin verir. Uygulama alt ağı yalnızca web alt ağdaki IP aralığından gelen trafiğe izin verir. Veri alt ağı yalnızca uygulama alt ağdaki IP aralığından gelen trafiğe izin verir.
AKS tabanlı bir modernizasyon modeli için, Azure CNI Overlay'i dağıttığınızda küme düğümü havuzları için 10.0.4.0/24 gibi bir aks-nodes alt ağı kullanabilirsiniz. Bu modelde yalnızca düğümler alt ağdaki VNet IP adreslerini tüketir. Podlar, düğüm alt ağını düz ağ AKS tasarımından daha küçük tutmanızı sağlayan ayrı bir katman CIDR kullanır.
Ortak desenler
Aşağıdaki alt ağ düzenleri en yaygın Azure dağıtım senaryolarını kapsar:
| Desen | Alt ağ | Ne zaman kullanılır? |
|---|---|---|
| Basit web uygulaması | web + data |
Ön ucu ve veritabanı olan iki katmanlı uygulamalar. En düşük karmaşıklık. |
| Üç katmanlı kuruluş | web + app + data + management |
Yönetim için atlama sunucusu veya Bastion alt ağı kullanan, farklı katmanlardan oluşan geleneksel kurumsal iş yükleri. |
| Paylaşılan hizmetlerle AKS | aks-nodes + aks-ingress + appgw + shared |
Ayrılmış giriş denetleyicisi alt aağı ve WAF için Application Gateway ile Kubernetes iş yükleri. |
| Merkez-uç çıkış | AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management |
Hub-and-spoke topolojisindeki hub VNet’i. Uç VNet'lerin kullandığı paylaşılan hizmetler üzerinden trafik yönlendirilir. Bkz. Merkez-uç topolojisi. |
| Veri iş yükü | compute + data + private-endpoints + management |
Depolama ve veritabanları için özel uç noktaların IP planlama netliği için kendi alt ağlarına ihtiyaç duyduğu analiz ve veri platformu iş yükleri. |
Kaç sanal ağ ve alt ağ var?
Kılavuz ilkesi basittir: Uygulama başına bir sanal ağ ve bileşen başına bir alt ağ (katman) kullanın. Bu varsayılan ayar her iş yükünü yalıtılmış tutar, katmanlar arasındaki trafiğin ağ güvenlik gruplarıyla denetlenmesini kolaylaştırır ve büyümek için yer bırakır. Paylaşılan hizmetlere, yalıtım gereksinimlerine ve ölçeklendirmeye göre buradan ayarlayın.
Sanal ağ ve alt ağ stratejinizi belirlemek için bu karar tablosunu kullanın:
| Sizin durumunuz | Önerilen yaklaşım |
|---|---|
| Tek iş yükü, tek ekip, paylaşılan hizmetler gerekmez | Uygulama bileşeni başına alt ağlara (web, uygulama mantığı, veriler) sahip bir sanal ağ. Bkz. Tek iş yükü topolojisi. |
| Bir ağ geçidini veya güvenlik duvarını paylaşan birden çok bağımsız iş yükü | Paylaşılan hizmetler için merkez sanal ağı + iş yükü başına tek uçlu sanal ağ. Bkz. Merkez-uç topolojisi. |
| İş yükleri arasında sıkı yalıtım (patlama yarıçapı, uyumluluk gereksinimleri) | İş yükü başına, aralarında eşleme bulunmayan bir VNet. |
| Birçok aboneliği ve bölgeyi içeren çok büyük bir ortam | Otomatik merkez yönetimiyle Azure Sanal WAN. Bkz. Sanal WAN topolojisi. |
Ayrılmış alt ağ boyutlandırma kılavuzu
Birçok Azure platform hizmeti, belirli bir ada ve minimum boyuta sahip kendi ayrılmış alt ağlarına ihtiyaç duyar. Aşağıdaki diyagramda, ayrılmış platform alt ağları için adlandırma gereksinimleri ve minimum boyutlar gösterilmektedir:
Adres alanınızı planlarken şu tabloyu kullanın:
| Azure hizmeti | En düşük alt ağ boyutu | Gerekli alt ağ adı | Notlar |
|---|---|---|---|
| Azure Güvenlik Duvarı | /26 (59 kullanılabilir IP) | AzureFirewallSubnet |
Tüm güvenlik duvarı SKU'ları için gereklidir. Bkz. Azure Güvenlik Duvarı tasarım. |
| VPN Ağ Geçidi | /27 (27 kullanılabilir IP) | GatewaySubnet |
Microsoft, ölçeklendirme payı için /27 veya daha geniş bir ağ öneki kullanılmasını önerir. |
| Azure Bastion | /26 (59 kullanılabilir IP) | AzureBastionSubnet |
Kasım 2021'den sonra oluşturulan tüm dağıtımlar için en az /26. |
| Application Gateway v2 | /24 önerilir (251 kullanılabilir IP) | Gerekli ad yok | Otomatik ölçeklendirme için /24 şiddetle önerilir. Minimum değer bir formüle dayanır (örnek sayısı + 5 ayrılmış adres + 1 özel ön uç IP adresi). |
| Uygulama Hizmet Ortamı | /24 (üretim), /23 (maksimum ölçek) | Gerekli ad yok | Ölçeklendirme, alt ağdaki IP adreslerini tüketir. 200 örnek üst sınırına yakın bir ölçekle ölçeklendirmeyi planlıyorsanız /23 kullanın. |
| Azure Yönlendirme Sunucusu | /26 (59 kullanılabilir IP) | RouteServerSubnet |
NVA'larla BGP rota değişimi için gereklidir. |
| Azure DNS Özel Çözümleyicisi | Uç nokta alt ağı başına en az /28 gerekir | Özel gelen ve giden alt ağlar | Gelen ve giden uç noktalar için ayrı alt ağlar gerektirir. Diğer kaynaklarla paylaşılamıyor. |
| AKS (Azure Kubernetes Service) | Formül tabanlı (CNI'ye bağımlı) | Gerekli ad yok | AKS boyutlandırma kılavuzuna bakın. |
Note
Özel uç noktalar, mevcut alt ağlardan IP adreslerini tüketir. Ayrılmış bir alt ağ gerektirmezler. Bu IP tüketimini alt ağ boyutlandırmanıza dahil edin. Ayrıntılı IP planlaması için bkz. IP adresi planlaması.
AKS alt ağ boyutlandırması
AKS alt ağ boyutlandırması, Kapsayıcı Ağ Arabirimi (CNI) eklenti seçiminize bağlıdır. Tek bir minimum boyut yoktur:
- Azure CNI Overlay: Pod’lar ayrı bir özel CIDR (Sınıfsız Etki Alanları Arası Yönlendirme) bloğu kullandığından, alt ağın yalnızca düğümleri barındıracak kadar olması gerekir. Düz ağ ile karşılaştırıldığında önemli ölçüde daha küçük bir alt ağ kabul edilebilir.
-
CNI (düz ağ) Azure: Alt ağ hem düğümleri hem de POD'ları barındırmalıdır. Formül:
(nodes + surge) × (max_pods + 1). /21 veya üzeri, 50 veya daha fazla düğüme sahip kümeler için yaygındır. - Kubenet: Yalnızca düğümler VNet alt ağının IP adreslerini tüketir. Podlar küme iç IP adreslerini alır.
CNI başına formülleri boyutlandırma seçeneği için bkz. AKS kümeniz için IP adresi planlama.
Alt ağ eşleme kısıtlamaları
Alt ağ eşlemesi, belirli alt ağları tüm adres alanları yerine sanal ağlar arasında bağlar. Bu yaklaşım, eşleme ilişkilerine hangi alt ağların katılacağı üzerinde ayrıntılı denetim sağlar.
Important
Alt ağ eşlemesi şu anda önizleme aşamasındadır ve aşağıdaki kısıtlamalara sahiptir:
- Aboneliğin onaylı bir listeye eklenmesini gerektirir (self servis kayıt yoluyla değil)
- YALNıZCA CLI, ARM şablonu, Terraform veya PowerShell (portal desteği yok)
- Intel tabanlı V5 SKU'ları (veya AMD Genoa/Cobalt 100 tabanlı SKU'lar), eski nesil SKU'larda bilinen bir hatayı önlemek için üretim kullanımı için gereklidir: Bkz. Geçerli donanım gereksinimleri için alt ağ eşlemesini yapılandırma
- Her bir eşleme bağlantısı tarafı için en fazla 200 alt ağ
- VNet başına tüm peering bağlantılarında en fazla toplam 1.000 alt ağ
- Alt ağlar benzersiz, çakışmayan adres alanlarına ait olmalıdır
Geçerli sınırlamalar ve kayıt için bkz. Alt ağ eşlemesini yapılandırma.
Note
Azure Sanal Ağ Yöneticisi (AVNM), alt ağ eşlemesini sanal ağ eşlemesinden ayıramaz. Eşleme yapılandırmalarını yönetmek için AVNM kullanıyorsanız alt ağ düzeyinde eşleme ilişkilerinin AVNM'de standart sanal ağ eşlemesi olarak göründüğünü unutmayın.
Tasarımla ilgili dikkat edilecek noktalar
Lift-and-shift VNet ve alt ağ tasarım odağı
- Şirket içi segmentasyonunuzu yeniden oluşturun: Mevcut güvenlik duvarı sınırlarının ve operasyonel sahipliğin minimum yeniden tasarımla devredilmesi için her VLAN veya güvenlik bölgesini bir alt ağ ile eşleyin.
- Alt ağları pay bırakacak şekilde boyutlandır. Geçişten sonra yeniden adresleme aksatıcıdır; bu nedenle, gelecekteki büyümeyi ve Azure’un her alt ağ için ayırdığı beş adresi karşılayabilmek amacıyla, mevcut ana bilgisayar sayınızın gerektirdiğinden daha büyük CIDR aralıkları ayırın.
- yönlendirmeyi basitleştirmek ve VPN Gateway veya ExpressRoute üzerinden bağlanırken çakışmayı önlemek için Azure adres alanlarını şirket içi aralıklarla uyumlu tutun.
- Varsayılan olarak, her katman için bir alt ağ olacak şekilde taşınan uygulama başına bir VNet kullanın. Bu tasarım tipik üç katmanlı şirket içi düzenleri yansıtır ve taşımayı tahmin edilebilir tutar.
Sanal ağ ve alt ağ tasarım odağını modernleştirme
- Önce platform hizmetleri çevresinde alt ağlar tasarlayın: Azure Güvenlik Duvarı, Application Gateway ve Bastion için ayrılmış alt ağların yanı sıra CNI seçiminize göre AKS için doğru boyutlandırılmış alt ağlar.
- AKS için Azure CNI Overlay'i kullanarak düğüm alt ağlarını küçük tutun; çünkü pod'lar adreslerini VNet adres alanı yerine ayrı bir örtüşüm CIDR bloğundan alır.
- PaaS hizmetlerini daha fazla Azure benimsedikçe IP tüketiminin öngörülebilir kalması için özel uç noktalar için ayrılmış bir alt ağ ayırın.
- Abonelikler arasında sanal ağ sayınız arttıkça ağ gruplarını, bağlantıyı ve güvenlik yapılandırmalarını tutarlı bir şekilde uygulamak için Azure Sanal Ağ Yöneticisi erken benimseyin.
Bulutlar arası VNet ve alt ağ tasarım odağı
- Herhangi bir sanal ağ oluşturmadan önce bir genel adres planı oluşturun. Mevcut AWS VPC'leri veya Google Cloud VPC ağlarıyla çakışmayan Azure için örtüşmeyen CIDR bloklarını ayırın. Bu rezervasyon yönlendirilmiş VPN veya ara bağlantı için zorunludur.
- Bulutların ağ temel öğelerini Azure eşleyin: AWS VPC veya Google Cloud VPC ağı bir Azure sanal ağına, güvenlik grupları ise NSG'lere karşılık gelir.
- Geçiş altyapısının ölçeklenmesi için yeterli alan olması amacıyla, VPN Gateway için bir
GatewaySubnetveya Azure Sanal WAN tarafından kullanılan hub gibi bulutlar arası bağlantı bileşenleri için alt ağ alanı ayırın. - İşletim ekiplerinin çoklu bulut trafiğinde sorun giderme sırasında eşdeğer katmanlar arasında bağıntı oluşturabilmesi için alt ağ adlandırma ve etiketlemeyi bulutlar arasında standartlaştırın.
Prerequisites
Sanal ağınızı ve alt ağ düzeninizi tasarlamadan önce aşağıdakilere sahip olduğunuzdan emin olun:
- Azure aboneliği: Ağ kaynakları oluşturma izinlerine sahip etkin bir Azure aboneliği (Ağ Katkıda Bulunanı rolü veya üzeri).
- Kaynak grubu: Hedef bölgenizde sanal ağ kaynaklarını içerecek bir kaynak grubu.
- Bölge kararı: Kullanıcılara yakınlık, uyumluluk gereksinimleri ve hizmet kullanılabilirliğine göre birincil Azure bölgenizi seçin.
- Adres alanı planı: Şirket içi ağlarınızla veya eşlemek istediğiniz diğer sanal ağlarla çakışmayan bir IP adresi aralığına (CIDR bloğu) karar verin. Yönergeler için bkz. IP adresi planlaması .
Güvenlik konuları
Sanal ağlar ve alt ağlar, ilk ağ kesimleme katmanınızdır. Aşağıdaki güvenlik uygulamalarını uygulayın:
- Ağ güvenlik grupları (NSG): Gelen ve giden trafiği filtrelemek için NSG'leri her alt ağ ile ilişkilendirin. Her alt ağın rolüne özgü izin verme kurallarını tanımlayın ve varsayılan olarak diğer her şeyi reddedin. Ayrıntılı yönergeler için bkz. Ağ güvenlik grupları ve uygulama güvenlik grupları.
- UDR'lerle zorlamalı tünel oluşturma: Uyumluluk gereksinimleriniz tüm İnternet'e bağlı trafiğin şirket içi denetim cihazından veya bulut güvenlik duvarından geçmesini zorunlu kılıyorsa, varsayılan internet yönlendirmesini geçersiz kılmak için kullanıcı tanımlı yollar içeren yol tablolarını kullanın. Bkz. Giden ve çıkış yönlü bağlantı.
- Alt ağ yalıtımı: Farklı güven düzeylerine sahip kaynakları ayrı alt ağlara yerleştirin. Örneğin, veritabanlarını yalnızca uygulama katmanı alt ağından gelen trafiğe izin veren bir alt ağda tutun. Bu ayrım, bir saldırgan bir bileşeni ele geçirirse yanal hareketi sınırlar.
- Platform hizmetleri için ayrılmış alt ağlar: Birçok Azure platform hizmeti (Azure Güvenlik Duvarı, Application Gateway, Bastion) ayrılmış alt ağlara dağıtılır. Bu yalıtım, platform hizmeti yönlendirme ve güvenlik kurallarının iş yükü alt ağlarınızı engellememesini sağlar.
NSG ve alt ağ etkileşimi
Bir NSG'yi bir alt ağ ile ilişkilendirdiğinizde, NSG kuralları bu alt ağdaki tüm kaynaklara uygulanır. Şu etkileşim davranışlarını anlayın:
- Kümülatif değerlendirme: Vm'nin NIC'sinde de NSG varsa, Azure hem alt ağ düzeyinde NSG'yi hem de NIC düzeyinde NSG'yi değerlendirir. Gelen trafik için Azure önce alt ağ NSG'sini, ardından NIC NSG'yi değerlendirir. Giden trafik için Azure önce NIC NSG'sini, ardından alt ağ NSG'sini değerlendirir.
- Varsayılan reddetme: Azure, sanal ağ içi trafiğe ve giden İnternet erişimine izin veren varsayılan kuralları içerir. Özel reddetme kuralları ekledikten sonra, geçerli trafiğin (örneğin, 168.63.129.16 IP adresinden gelen Azure Load Balancer sistem durumu yoklamaları) yanlışlıkla engellenmediğini doğrulayın.
-
Hizmet etiketleri ve ASG'ler: Ham IP adresleri yerine NSG kurallarında hizmet etiketlerini (,
AzureLoadBalancerInternet,VirtualNetwork) ve uygulama güvenlik gruplarını (ASG' ler) kullanın. Bu yaklaşım kural yönetimini basitleştirir ve Azure IP aralıkları değiştikçe otomatik olarak uyarlar. - Görünürlük için akış günlükleri: Kabul edilen ve reddedilen trafiği yakalamak için her alt ağ düzeyindeki NSG akış günlüklerini etkinleştirin. Akış günlükleri, güvenlik kurallarının istenen şekilde çalıştığını doğrulamanıza ve uyumluluk denetimleri için kanıt sağlamanıza yardımcı olur. Kurulum yönergeleri için bkz. NSG akış günlükleri .
İlgili makaleler
Azure ağ tasarım kılavuzundaki bu makaleler ilgili konuları kapsar:
- IP adresi planlaması: Adres alanınızı tasarlayın, çakışmalardan kaçının ve büyümeyi planlayın.
- Ağ güvenlik grupları ve uygulama güvenlik grupları: Alt ağ ve NIC düzeyinde trafik filtreleme kuralları tanımlayın.
- Tek iş yükü topolojisi: Paylaşılan hizmetler olmadan tek bir iş yükü için basit bir ağ tasarlar.
- Merkez-uç topolojisi: Paylaşılan hizmetler hub'ı aracılığıyla birden çok iş yükü sanal ağı bağlayın.
- Sanal WAN topolojisi: Otomatik merkez yönlendirmesi ile bağlantıyı uygun ölçekte yönetin.
- Bölgeler arası bağlantı: Genel eşleme veya Sanal WAN kullanarak sanal ağları Azure bölgeler arasında bağlayın.
- Merkezi ağ yönetimi: Azure Sanal Ağ Yöneticisi kullanarak abonelikler arasında sanal ağ yapılandırmalarını yönetin.
Daha fazla bilgi edinin
sanal ağ Azure hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:
- Azure Sanal Ağ nedir?
- Azure Sanal Ağ Hakkında Sıkça Sorulan Sorular
- Sanal ağ alt ağ planlaması
- Sanal ağ eşleme
- Alt ağ eşlemesini yapılandırma (önizleme)
- AKS kümeleri için IP adresi planlama
Sonraki Adımlar
İpucu
Kendi başınıza mı keşfedersiniz? Özelliğe göre bir sonraki makalenizi bulmak için genel bakış gezginine dönün.
Lift-and-shift yolculuğunuzdaki bir sonraki adım:
IP adres alanınızı planlama: Şirket içi adres aralıklarınızla çakışmayı önleyen bir /16 CIDR havuzu ayırın.
Modernleştirme yolculuğunuzda bir sonraki adım:
IP adres alanınızı planlama: Etkin-etkin eşleme için çakışmayan aralıklara sahip çift bölgeli IP havuzları ayırın.
Bulutlar arası yolculuğunuzda sonraki adım:
IP adres alanınızı planlama: Azure, Amazon Web Services (AWS) ve Google Cloud'da çakışmayan adresleme tasarlayın.