Merkez-uç ağ topolojisi

Bu makalede, Azure'da merkez-uç ağı tasarlama açıklanmaktadır. Merkezi merkez sanal ağı paylaşılan hizmetleri barındırırken yalıtılmış uç sanal ağları tek tek iş yüklerini barındırıyor.

Bu makalenin kapsamı

Bu makale, hub sanal ağındaki paylaşılan hizmetleri, spoke yalıtımını ve yönlendirme desenlerini (standart, doğrudan eşleme ve stamp tabanlı) ele alır. Ayrıca karma bağlantı için ağ geçidi aktarımını ve Azure Sanal Ağ Yöneticisi ile merkez-uç topolojilerini ölçeklendirmeyi kapsar.

Bu makaleye kimin ihtiyacı var?

Bu koşullardan biri veya daha fazlası geçerliyse bu makaleyi okuyun:

• Birden çok iş yükü için güvenlik duvarı, DNS, Bastion, VPN Gateway veya ExpressRoute gibi paylaşılan ağ hizmetlerine ihtiyacınız vardır.
• Bu hizmetleri her sanal ağda yinelemek yerine trafik denetimini, yönlendirme denetimini veya yönetimi merkezi hale getirmek istiyorsunuz.
• Paylaşılan platform hizmetlerini iş yükü sanal ağlarından ayırmak için yinelenebilir bir topolojiye ihtiyacınız vardır.
• Topolojinizi standartlaştırmadan önce merkez-uç ile diğer geçiş modellerini karşılaştırmak istiyorsunuz.

Paylaşılan hizmet gereksinimleri olmayan tek bir iş yükünüz varsa, bunun yerine düz bir ağ topolojisiyle başlayın.

İpucu

Senaryo yolunu mu takip ediyorsunuz? Uyarlanmış rehberlik için sayfanın üst kısmından senaryonuzu seçin. Aşağıdaki temel kılavuz tüm okuyucular için geçerlidir.

Lift-and-shift odağı: Şirket içi iş yüklerini Azure’a taşıyorsanız ve birden çok uç VNet genelinde merkezi paylaşılan hizmetlere (DNS, güvenlik duvarı, VPN Gateway) ihtiyacınız varsa bu makaleyi okuyun. Hub-and-spoke, tek bir hub'da paylaşılan altyapı gerektiren çoklu iş yükü lift-and-shift migrasyonları için varsayılan topolojidir.

Modernleştirme odağı: PaaS hizmetlerini birden çok bölgeye dağıtıyorsanız ve BT'ye ait hub'lar ve uygulama ekibine ait uçlarla çift merkez topolojisine ihtiyacınız varsa bu makaleyi okuyun. Merkez-uç modeli, platform hizmetleri ve uygulama iş yükleri için ayrı abonelik sınırlarını destekleyecek şekilde ölçeklendirilir.

Bulutlar arası odak: Bulutlar arası transit için hub-and-spoke ile Sanal WAN’ı değerlendiriyorsanız bu makaleyi okuyun. Bulutlar arası altyapınız Sanal WAN kullanımını haklı çıkarmayacak kadar küçükse, diğer bulutlara VPN Gateway bağlantılarıyla kurulan geleneksel bir hub-and-spoke mimarisi daha basit bir başlangıç noktası sunar.

Azure hizmetleri ve özellikleri

Aşağıdaki tabloda merkez-uç topolojisini destekleyen Azure hizmetleri ve özellikleri listelenmektedir:

Hizmet veya özellik	Merkez-çevre yapısındaki rol	Daha fazla bilgi edinin
Azure Sanal Ağ	Hub ve bağlı sanal ağları sağlar	Sanal ağa genel bakış
VNet eşlemesi	Her bir uç ile merkez arasında bağlantı kurar	Sanal ağ eşleme
Azure Güvenlik Duvarı	Merkezdeki merkezi trafik denetimi ve filtreleme	Azure Güvenlik Duvarı'ne genel bakış
VPN Ağ Geçidi veya ExpressRoute Ağ Geçidi	Tüm spoke’larda paylaşılan hibrit bağlantı	VPN Gateway genel bakış
Azure Bastion	Eşlenmiş bağlı ağlardaki VM'lere güvenli uzaktan erişim	Azure Bastion'a genel bakış
Azure Özel DNS Çözümleyicisi	Azure ile şirket içi arasında DNS iletme	Özel DNS Çözümleyiciye genel bakış
Azure DDoS Koruması	Spoke genel IP'lerini kapsayan paylaşılan DDoS planı	DDoS Korumasına genel bakış
Azure Sanal Ağ Yöneticisi (AVNM)	Büyük ölçekte otomatik uç eşlemesi, UDR yönetimi ve ağ grupları	AVNM'ye genel bakış

Nasıl çalışır?

Merkez-uç topolojisinde:

1. Merkez sanal ağı, bağlantının merkezi noktası olarak görev yapar. Güvenlik duvarı, ağ geçidi ve Bastion konağı gibi paylaşılan ağ hizmetlerini içerir.
2. Uç sanal ağlar hub ile eşlenir. Her bir uç, bir iş yükü barındırır: bir uygulama, bir ekip ortamı veya yalıtılmış bir hizmet.
3. VNet eşlemesi geçişli değildir. Uçlar hub'a ulaşabilir, ancak siz aralarında yönlendirme veya doğrudan eşleme yapılandırmadığınız sürece uçlar birbirine doğrudan merkez üzerinden ulaşamaz.

Merkez sanal ağında ne olur?

Hub'ınıza hangi hizmetlerin yerleştirileceğini belirlemek için aşağıdaki tabloyu kullanın:

Service	Dahil edilsin mi?	Notlar
Azure Güvenlik Duvarı	Recommended	Tüm doğu-batı ve kuzey-güney trafiği için merkezi trafik denetimi sağlar. Tam olarak AzureFirewallSubnetadlı bir alt ağ gerektirir.
VPN veya ExpressRoute Ağ Geçidi	Karma bağlantı gerekiyorsa	Tüm uçlar, ağ geçidi geçişi aracılığıyla tek bir ağ geçidini paylaşır. Tam olarak GatewaySubnet adlı bir alt ağ gerekir (en az /27).
Azure Bastion	Recommended	Hub’daki bir Bastion ana bilgisayarı, tüm eşlenik spoke sanal ağlardaki VM’lere erişir. Basic SKU veya üzeri gerekir: Developer SKU, VNet'ler arası eşleme erişimini desteklemez.
Özel DNS Çözümleyici	Özel DNS gerekiyorsa	Azure barındırılan özel DNS bölgeleri ve şirket içi DNS sunucuları arasında DNS sorgularını iletir.
Azure DDoS Koruması planı	DDoS koruması etkinleştirildiyse	Tek bir plan, merkez aboneliğine bağlı tüm uç sanal ağlarında genel IP adreslerini koruyabilir.

Important

Uygulama iş yüklerini hub'ın dışında tutun. Merkez yalnızca paylaşılan altyapı hizmetlerini barındırıyor: güvenlik duvarı, ağ geçitleri, Bastion ve DNS. Uygulama VM'leri, kapsayıcılar ve PaaS kaynakları uç sanal ağlarına aittir. Bu ayrım merkezi temiz tutar, eşlemeyi basitleştirir ve platform ekibinin paylaşılan hizmetleri uygulama ekiplerinden bağımsız olarak yönetmesine olanak tanır.

Merkez alt ağ düzeni

İyi tasarlanmış bir merkez sanal ağı genellikle şu alt ağları içerir:

Alt ağ adı	Purpose	En küçük boyut
AzureFirewallSubnet	Azure Güvenlik Duvarı dağıtımı	/26
AzureFirewallManagementSubnet	Zorlamalı tünel için yönetim NIC'i (yalnızca Standart/Premium)	/26
GatewaySubnet	VPN ve ExpressRoute ağ geçitleri	/27
AzureBastionSubnet	Azure Bastion	/26
DNS çözümleyici gelen alt ağı	Özel DNS Çözümleyici gelen uç nokta	/28
DNS çözümleyici giden alt ağı	Özel DNS Çözümleyici giden uç noktası	/28

Ayrıntılı alt ağ boyutlandırma kılavuzu için bkz. Sanal ağlar ve alt ağlar.

Varyant nasıl seçilir

Hub-and-spoke modelinin üç yaygın varyantı vardır. Yalıtım ve iletişim gereksinimlerinize göre seçim yapın:

Variant	Trafik yolu	Ne zaman kullanılır?
Standart merkez-uç	Spoke'tan spoke'a tüm trafik, merkez güvenlik duvarı üzerinden yönlendirilir.	Merkezi trafik denetimine ihtiyacınız var. İkincil düğümler doğrudan noktadan noktaya iletişim gerektirmez.
Doğrudan eşlemeli merkez ve bağlı ağlar	Belirli spoke çiftleri de doğrudan birbirleriyle eşler arası bağlantı kurar.	Sıkı bir şekilde bağlanmış iş yükleri, güvenlik duvarından geçmeden düşük gecikme süreli uç-uç iletişimine ihtiyaç duyar.
Posta pulları (tamamen izole)	Merkez yok. Her sanal ağ tamamen bağımsızdır.	Katı patlama yarıçapı yalıtımı, uyumluluk temelli ayırma veya bağımsız yığınlara sahip çok kiracılı SaaS.

Standart merkez ve uç

Bu değişken en yaygın olanıdır. Tüm uç-uç trafiği, kontrol için merkez güvenlik duvarından geçer. Uç noktalar yalnızca merkez üzerinden iletişim kurar; asla doğrudan iletişim kurmaz.

Yönlendirme düzeni: Merkez güvenlik duvarının özel IP adresine işaret eden varsayılan yol () ile her uç alt asına kullanıcı tanımlı bir yol (0.0.0.0/0UDR) uygulayın. Bu, spoke’tan spoke’a trafik dahil tüm giden trafiğin günlükleme ve filtreleme amacıyla güvenlik duvarı üzerinden geçmesini zorunlu kılar.

Eşleme sınırı: Tek bir hub sanal ağı en fazla 500 eşleme bağlantısını (standart platform sınırı) destekler. Merkez-uç bağlantı yapılandırmasıyla Azure Sanal Ağ Yöneticisi (AVNM) kullanıyorsanız, sınır 1.000 uca kadar artar.

Doğrudan eşlenmeli merkez-uç topolojisi

Bazı mimarilerde belirli uç çiftlerinin merkez güvenlik duvarından geçmeden düşük gecikme süreli iletişime ihtiyacı vardır. Bu durumlar için uç çifti arasına doğrudan sanal ağ eşlemesi ekleyin veya AVNM bağlantılı grupları kullanın.

Aşağıdaki durumlarda doğrudan uç eşlemesini kullanın:

• İki iş yükü, yüksek aktarım hızına sahip verileri (örneğin, uçlar arasında veritabanı çoğaltması) değiştirir.
• Belirli bir veri yolu için güvenlik duvarı atlamasından kaynaklanan gecikme kabul edilemez.
• Doğrudan eşlenen trafiğin merkezi güvenlik duvarı incelemesini atladığını kabul edebilirsiniz.

Note

Uçlar arasında eşleme, hub gereksinimini ortadan kaldırmaz. Hub'a bağlı trafik (çıkış, karma bağlantı, paylaşılan hizmetler) hala merkez güvenlik duvarı üzerinden yönlendirilir.

Damga pulları deseni (tamamen yalıtılmış)

Stamps düzeni, sıkı etki alanı izolasyonu gerektiren senaryolar için bir alternatiftir. Her iş yükü, hub'ı olmayan ve diğer iş yükleriyle eşlemesi olmayan tam bağımsız bir sanal ağa dağıtılır.

Stamps ne zaman kullanılır:

• Mevzuat uyumluluğu, iş yükleri arasında ağ yolu gerektirmez.
• Her kiracının bağımsız bir yığına sahip olduğu Çok Kiracılı SaaS.
• Maksimum hata yalıtımı: Bir damga pulundaki bir hata başkalarına yayılamaz.

Örnek: Çok Kiracılı SaaS yalıtımı

SaaS sağlayıcısı her kurumsal müşteriyi özel bir damga pulunda barındırıyor. Her damga kendi sanal ağı (10.x.0.0/16), uygulama ağ geçidini, işlem katmanını ve veritabanını içerir. Stamp'ler arasında VNet eşleştirmesi bulunmadığından, A kiracısının stamp'inde yanlış yapılandırılmış bir NSG veya tehlikeye atılmış bir iş yükü, ağ üzerinden B kiracısının kaynaklarına erişemez. Sağlayıcı, Azure Resource Manager şablonları aracılığıyla damgaları yönetir ve bunları büyük kiracılar için ayrı kaynak gruplarına veya ayrı aboneliklere dağıtır. Gerektiğinde, kiracılar arasında veri değişimi, paylaşılan bir Azure Service Bus ad alanı üzerinden gerçekleştirilir. Her damga özel uç noktalar aracılığıyla bu ad alanına erişir.

Tavizler:

• Paylaşılan hizmet yok. Her damga damgasının kendi güvenlik duvarı, ağ geçidi ve Bastion konağına (gerekirse) ihtiyacı vardır ve bu da maliyeti artırır.
• Özel ağ üzerinden iş yükleri arası iletişim yoktur.
• Merkezi altyapı yerine bağımsız ağları yönettiğiniz için operasyonel ek yük artar.
• Paylaşılan hizmet tasarrufları geçerli olmadığından, damga sayısıyla maliyet doğrusal olarak artar.

İş yükleriniz paylaşılan hizmetlere veya iş yükleri arası iletişime ihtiyaç duyuyorsa bunun yerine standart merkez-uç değişkenini kullanın.

Uç-uç iletişim desenleri

Sanal ağ eşlemesi geçişli olmadığından, uç-uç iletişimi açık yönlendirme gerektirir. Bu bölümde merkez güvenlik duvarını kullanarak uçlar arasında trafiğin nasıl aktığı gösterilir.

Trafik akışı: hub güvenlik duvarı üzerinden Spoke A'dan Spoke B'ye

Aşağıdaki sıra, bir paketin Spoke A'daki bir VM'den (10.1.0.4) Spoke B'deki bir VM'ye (10.2.0.4) nasıl ilerlediğini açıklar:

1. Spoke A VM, 10.2.0.4 hedefli bir paket gönderir. Sanal makinenin etkin yönlendirme tablosu, 0.0.0.0/0 → 10.0.1.4 içeren bir UDR içerir (Azure Güvenlik Duvarı’ın özel IP adresi).
2. Paket, Spoke A'dan hub VNet'e VNet eşleme bağlantısı üzerinden geçer. Peering, trafiğin güvenlik duvarının alt ağına ulaşmasını sağlar.
3. Azure Güvenlik Duvarı paketi iç arabiriminde alır. Paketi ağ kurallarına ve uygulama kurallarına göre öncelik sırasına göre değerlendirir.
4. Bir kural akışa izin verirse, güvenlik duvarı paketi adresine 10.2.0.4iletir. Paket, hub-Spoke-B eşleme bağlantısını geçer.
5. Spoke B VM paketi alır. Dönüş trafiği aynı yolu tersten izler. B kolunun UDR'si yanıtı güvenlik duvarı üzerinden geri iletir.

Yol tablolarını yapılandırma

Yukarıdaki deseni etkinleştirmek için şu yol tablolarını uygulayın:

1. Bir yönlendirme tablosu oluşturun spoke alt ağları için. Şirket içi yolların UDR'lerinizi geçersiz kılmasını önlemek istiyorsanız BGP yol yayma özelliğini kapatın.
2. Sonraki atlama türü 0.0.0.0/0 ve sonraki atlama adresi Azure Güvenlik Duvarı özel IP’si olarak ayarlanmış bir varsayılan rota ekleyin (VirtualAppliance).
3. Rota tablosunu , diğer uçlara veya İnternet'e ulaşması gereken her uç alt ağıyla ilişkilendirin.
4. Belirli bir uç-uç trafiğine izin veren güvenlik duvarı ağ kuralları oluşturun. Örneğin, 443 ve 1433 numaralı bağlantı noktalarında 10.1.0.0/16 → 10.2.0.0/16 öğesine izin verin.

İpucu

uç adres aralıklarını düzenlemek için Azure Güvenlik Duvarı IP Gruplarını kullanın. Bu, yeni uçlar ekledikçe kural yönetimini basitleştirir.

Alternatif: doğrudan spoke'dan spoke'a iletişim için AVNM bağlantılı gruplar

Belirli uç ağlar arasında güvenlik duvarı denetimi gerekmiyorsa, AVNM bağlantılı grupları bir örgü bağlantı modeli sunar. Aynı bağlı gruptaki uçlar hub'dan geçmeden doğrudan iletişim kurar. Bu, gecikme süresi ve güvenlik duvarı aktarım hızı gereksinimlerini azaltır, ancak merkezi incelemeyi atlar.

Important

Azure Güvenlik Duvarı üzerinde zorlamalı tünel oluşturmayı etkinleştirirseniz (İnternet'e bağlı trafiği şirket içi bir alete yönlendirmek için), Standart veya Premium katmanına ihtiyacınız vardır. Zorunlu tünelleme ayrıca bir yönetim alt ağı (AzureFirewallManagementSubnet) gerektirir ve DNAT kurallarını devre dışı bırakır.

Ağ geçidi geçişi

Ağ geçidi geçişi, tüm uçların hub'da dağıtılan tek bir VPN veya ExpressRoute ağ geçidini paylaşmasına olanak tanır. Ağ geçidi aktarımı olmadan, her spoke’un şirket içi ağlara erişmek için kendi ağ geçidine ihtiyacı vardır.

Yapılandırma adımları

1. Hub'ın içinde bir VPN veya ExpressRoute ağ geçidi dağıtınGatewaySubnet.
2. Hub tarafındaki eşleme bağlantısında (hub → uç): Ağ geçidi aktarımına izin ver seçeneğini etkinleştirin.
3. Uç tarafındaki eşleme bağlantısında (uç → hub): Uzak ağ geçitlerini kullan seçeneğini etkinleştirin.
4. Rota yayılımını doğrulayın. Yapılandırmadan sonra, bir spoke VM’nin ağ arabirimindeki etkin rotaları denetleyin. Yol tablosu, sonraki atlama türü VNetGlobalPeering veya VNetPeeringolan merkez ağ geçidi üzerinden öğrenilen şirket içi ön ekleri gösterir.

Yapılandırıldığında, hub ağ geçidi tarafından öğrenilen yollar (örneğin, ExpressRoute'tan gelen şirket içi ön ekler) otomatik olarak uç yönlendirme tablolarına dağıtılır.

Ağ geçidi aktarım sınırlamaları

• Ağ geçidi geçişi, Temel katman dışındaki tüm VPN Gateway katmanlarıyla çalışır. Temel VPN Gateway kullanıyorsanız, eşlenmiş sanal ağlarla paylaşamazsınız.
• Uç sanal ağı yalnızca bir uzak ağ geçidi kullanabilir. Birden çok hub ile eşlenen bir spoke üzerinde Use remote gateways etkinleştiremezsiniz.
• Trafiği güvenlik duvarı üzerinden zorla yönlendirmek için UDR’ler kullanıyorsanız, UDR’lerin ağ geçidi tarafından yayılan şirket içi rotaları istemeden ezmediğinden emin olun. Gerekirse yerel ön ekler için daha özel rotalar ayarlayın.

Note

ExpressRoute'u ağ geçidi aktarımıyla kullandığınızda, uç eşlemelerini kurmadan önce Ağ geçidi aktarımına izin ver'i etkinleştirin. Ağ geçidi önce var olmalı ve yapılandırılmalıdır.

Uygun ölçekte Azure Sanal Ağ Yöneticisi

Ortamınız birkaç uç ötesinde büyüdüğünde, eşleme bağlantılarını ve yönlendirme tablolarını el ile yönetmek karmaşık hale gelir. AVNM, merkez-uç topolojileri için otomasyon sağlar:

AVNM özelliği	Ne yapar?
Merkez-uç bağlantı yapılandırması	Merkez ile ağ grubundaki tüm uçlar arasında eşlemeyi otomatik olarak oluşturur ve korur. Her merkez en fazla 1.000 uç birimi destekler.
Bağlı gruplar	El ile eşleme olmadan doğrudan uç-uç bağlantısını etkinleştirir. Varsayılan sınır: Grup başına 250 sanal ağ (isteğe göre 1.000'e genişletilebilir).
Dinamik üyelikli ağ grupları	Etiketlere, adlandırmaya veya aboneliklere göre gruplara otomatik olarak sanal ağlar eklemek için Azure İlkesi koşulları kullanır.
UDR yönetimi	Birden çok merkez-uç topolojisi arasında yönlendirme tablosu dağıtımlarını otomatikleştirir.

AVNM, özellikle birden çok bölgede hub-and-spoke topolojilerini yönettiğinizde veya yeni uç sanal ağlar devreye girdikçe dinamik üyelik gereksiniminiz olduğunda özellikle değerlidir.

Ölçeklendirmeyle ilgili dikkat edilmesi gerekenler

Merkez-uç topolojiniz büyüdükçe aşağıdaki platform sınırları ve kuruluş desenleri için plan yapın:

Eşleme ve bağlantı sınırları

Dimension	Standart sınır	AVNM ile	Notlar
Sanal ağ başına VNet eşlemeleri	500	1.000 (merkez-uç yapılandırması)	Her uç-merkez eşlemesi her iki tarafta bir yuva kullanır
AVNM bağlı grup başına sanal ağlar	250 (varsayılan)	En fazla 1.000 (istek üzerine)	Azure desteği aracılığıyla artış isteme
AVNM kapsamı başına abonelik sayısı	N/A	1,000	Kapsam, bir yönetim grubundaki birden çok aboneliğe yayılabilir

Abonelik kuruluşu

• 10'dan fazla spoke içeren ortamlar için spoke'ları iş yüküne özgü aboneliklere ayırın. Bu, her iş yükü ekibi için faturalama, RBAC ve kota sınırlarını izole eder.
• Merkez sanal ağı, ağ geçitleri ve güvenlik duvarı için ayrılmış bir bağlantı aboneliği kullanın. Bu, Azure giriş bölgeleri (platform aboneliği) tarafından önerilen desendir.
• AVNM'nin Azure İlkesi koşullarını kullanarak abonelikler genelindeki uç sanal ağları dinamik olarak bulup yönetebilmesi için abonelikleri bir yönetim grubu altında gruplayın.

Azure İlkesi ile topolojiyi uygulama

Yapılandırma kaymasını önlemek için Azure İlkesi kullanın:

• Hub olmayan VNet’lere eşlemeyi reddedin. Hedef, belirlenmiş hub VNet değilse VNet eşlemesi oluşturulmasını engelleyecek bir ilkeyi yönetim grubu düzeyinde atayın.
• UDR ilişkilendirmesi gerektirir. 0.0.0.0/0 → Firewall yolunu içeren bir yönlendirme tablosu olmayan spoke alt ağlarını denetleyen (veya reddeden) bir ilke atayın.
• AVNM grup üyeliğini zorunlu kılma. Yeni VNets'lerin üyeliğe otomatik olarak dahil edilmesi için AVNM'de etiketlere (örneğin, NetworkRole:Spoke) göre dinamik üyelik kuralları kullanın.

Düz ağ topolojisinden merkez-uç topolojisine geçiş

Düz bir ağ topolojisiyle başladıysanız ve ortamınız paylaşılan hizmetler veya iş yükleri arası segmentlere ayırma gerektirecek şekilde büyüdüyse şu geçiş yolunu izleyin:

1. Adım: Merkez VNet'i planlayın

1. Merkez için mevcut düz sanal ağınızla çakışmayan yeni bir adres alanı (örneğin, 10.0.0.0/16) ayırın.
2. Hangi paylaşılan hizmetlerin dağıtılacağına karar verme: güvenlik duvarı, ağ geçidi, Bastion, DNS çözümleyicisi.
3. Hub alt ağlarını hub alt ağ düzeni tablosuna göre boyutlandırın .

2. Adım: Hub'da paylaşılan hizmetleri dağıtma

1. Merkez sanal ağı oluşturun ve Azure Güvenlik Duvarı (veya seçtiğiniz NVA) dağıtın.
2. Karma bağlantıya ihtiyacınız varsa VPN/ExpressRoute ağ geçidini dağıtın.
3. Güvenli VM erişimi için Azure Bastion dağıtın.
4. Özel DNS kullanıyorsanız Özel DNS Çözümleyici'yi yapılandırın.

3. Adım: İş yüklerini uç ağlara taşıma

1. Her iş yükü için yeni adres alanlarına sahip uç VNet'ler oluşturun. Yeniden IP adreslemesi yapamazsanız, merkezle çakışmadıkları sürece mevcut aralıkları koruyabilirsiniz.
2. Her bir spoke’u hub ile eşleyin. Hub tarafında ağ geçidi geçişini etkinleştirin ve spoke tarafında uzak ağ geçitlerini kullanın.
3. Varsayılan yolu hub'daki güvenlik duvarını gösterecek şekilde spoke alt ağlarına UDR'ler uygulayın.
4. VM'leri ve hizmetleri düz sanal ağdan uygun uca taşıyın veya yeniden dağıtın. İş yükü karmaşıklığına bağlı olarak Azure Kaynak Taşıyıcı veya yeniden dağıtmayı kullanın.
5. Daha önce düz sanal ağ içinde izin verilen uçlar arası ve uçlar arası İnternet trafiği desenlerine izin vermek için güvenlik duvarı kuralları oluşturun.

4. Adım: Düz VNet'i kullanımdan kaldırma

1. Tüm iş yüklerinin yeni merkez-uç topolojisi aracılığıyla erişilebilir olduğunu doğrulayın.
2. Özel IP adresleri değiştiyse DNS kayıtlarını güncelleştirin.
3. Tüm trafiği taşıyıp doğruladıktan sonra eski düz VNet’i kaldırın.

İpucu

İş yüklerini aşamalı olarak taşıyın. Yönlendirme ve güvenlik duvarı kurallarını doğrulamak için kritik olmayan bir iş yüküyle başlayın, ardından üretim iş yükleriyle devam edin.

Bunun yerine ne zaman Sanal WAN dikkate alınacaktır?

Merkez-uç topolojinizin karmaşıklığı artıyorsa Azure Sanal WAN daha uygun olup olmadığını değerlendirin:

Faktör	Merkez-uç (geleneksel)	Azure Sanal WAN
Management	Müşteri tarafından yönetilen merkez altyapısı	Microsoft tarafından yönetilen hub yönlendirme ve bağlantısı
En iyi kullanım alanları	30'dan az VPN dalı bağlantısı, tam denetim gerekiyor	30'den fazla VPN dalı, birçok Azure bölgesi
Routing	Müşteri UDR'leri el ile yapılandırır	Hub'da otomatik yönlendirme
SD-WAN entegrasyonu	Elle NVA dağıtımı	Yerleşik SD-WAN iş ortağı entegrasyonu
Genel geçiş	Müşteri tarafından yönetilen merkezler arası yönlendirme gerektirir	Yerleşik: Tüm hub'lar otomatik olarak birbirine bağlanır

Ayrıntılı karşılaştırma için bkz. Azure Sanal WAN topolojisi.

Tasarımla ilgili dikkat edilecek noktalar

Lift-and-shift geçişi için, tüm geçiş iş yüklerinin tükettiği paylaşılan hizmetlerle tek bir hub dağıtın:

• VPN Gateway ile tek hub. Hub'ın GatewaySubnet'inde VPN Gateway (veya ExpressRoute ağ geçidi) dağıtın. Tüm spoke iş yükleri, geçiş sırasında ve sonrasında şirket içi bağlantı için bu ağ geçidini ağ geçidi aktarımı üzerinden paylaşır.
• Hub'da Azure Bastion. Hub’daki tek bir Bastion kurulumu, taşınan sunucularda genel IP’leri açığa çıkarmadan eşlenmiş tüm spoke ağlarındaki VM’lere güvenli RDP/SSH erişimi sağlar.
• Giden trafik için merkezi güvenlik duvarı. Hub'da Azure Güvenlik Duvarı dağıtın. Her spoke alt ağındaki UDR'leri, güvenlik duvarını işaret eden varsayılan rotayı kullanacak şekilde yapılandırın. Tüm giden ve uçlar arası trafik bu tek denetim noktası üzerinden akar.
• Tek bir merkezle başlayın, kademeli olarak bağlantı noktaları ekleyin. Geçirirken her iş yükünün uç VNet'ini hub'a eşleyin. Tek bir hub en fazla 500 eşleme bağlantısını (AVNM ile 1.000) destekler.

Geçiş ve modernleştirme senaryosu için platform altyapısını uygulama iş yüklerinden ayıran çift merkez topolojisini planlayın:

• Çift merkezli dağıtım. Birincil bölgenizde bir hub ve yedekleme bölgenizde ikinci bir hub dağıtın. Her hub kendi güvenlik duvarını, ağ geçidini ve Bastion'ı içerir. Bu, PaaS iş yükleri için etkin-etkin mimarileri destekler.
• BT’nin sahip olduğu merkezler, uygulama ekibinin sahip olduğu uç birimler. Platform ekibi, hub aboneliklerini yönetir (bağlantı aboneliği düzeni, paylaşılan hub ağ kaynakları için ayrılmış bir Azure aboneliği, iş yükü aboneliklerinden ayrı). Uygulama ekipleri, Özel Bağlantı alt ağları ve iş yükü kaynakları üzerinde devredilmiş denetime sahip olarak kendi spoke aboneliklerini yönetir.
• Uç başına Özel Bağlantı alt ağlar. Her uç VNet, Özel Uç Noktaları için ayrılmış özel bir alt ağ içerir. Uygulama ekipleri, kendi spoke’ları içinde PaaS hizmetlerine (Azure SQL, Storage, Key Vault) Özel Bağlantı bağlantıları oluşturur.
• SNAT/DNAT olarak hub güvenlik duvarı. Her hub'daki merkezi güvenlik duvarı giden trafik için kaynak NAT ve gelen trafik desenleri için hedef NAT sağlar. Uygulama ekipleri merkezi incelemeyi atlayamaz.

Bulutlar arası bağlantı için geleneksel merkez-uç veya Sanal WAN doğru geçiş modelini sağlayıp sağlamadığını değerlendirin:

• Hub-and-spoke ile Sanal WAN karşılaştırması. 30'dan az şube bağlantınız, az sayıda farklı bulutlar arası VPN tüneliniz varsa ve bir veya iki Azure bölgesinde çalışıyorsanız, VPN Gateway ile geleneksel hub-spoke daha basittir. Çok sayıda VPC'niz, dallarınız, bölgeniz veya bulut kenarlarınız varsa Sanal WAN daha iyi ölçeklendirilen otomatik yönlendirme sağlar.
• Bulutlar arası tüneller için VPN Gateway. Merkez-uç modelinde merkezdeki VPN Gateway dağıtın ve AWS Sanal Özel Ağ Geçitleri ve Google Cloud VPN uç noktalarına siteden siteye bağlantılar oluşturun. Her bağlantı IPSec/IKE şifrelemesi kullanır.
• Karmaşıklık artışlarını değerlendirin. Çoklu bulut ortamınız büyürse (daha fazla AWS hesabı, Google Cloud projesi veya Azure bölgesi), hub-spoke modeli ile Sanal WAN arasındaki kararı yeniden gözden geçirin. Sanal WAN, birçok tüneli büyük ölçekte yönetirken daha uygun maliyetli hale gelir.

Tam karşılaştırma için bkz. Azure Sanal WAN topolojisi.

Prerequisites

Merkez-uç ağı tasarlamadan önce:

• Sanal ağ ve alt ağ planınızı tamamlayın. Kaç uça ihtiyacınız olduğunu ve her bir uç için hangi alt ağların gerekli olduğunu öğrenin.
• IP adresi düzeninizi tanımlayın. Merkez ve uç adres alanları çakışmamalıdır.
• VNet eşlemesinin geçişli olmadığını unutmayın: uç ağlar, merkez ağ üzerinden diğer uç ağlara bağlantı devralmaz.

Güvenlik konuları

Merkez-uç topolojisi, merkezdeki güvenlik uygulamasını merkezi hale getirmektedir. Şu ilkeleri uygulayın:

• Tüm spoke trafiğini hub güvenlik duvarı üzerinden yönlendirin. Varsayılan yolu güvenlik duvarına yönelen UDR'leri kullanın. Bu yapılandırma, güvenlik duvarının spoke’tan spoke’a ve spoke’tan internete olan her akışı incelemesini ve günlüğe kaydetmesini sağlar.
• Spoke alt ağlarında NSG'leri katmanlı savunma amacıyla kullanın. Merkezi güvenlik duvarı olsa bile uç alt ağlarında bulunan ağ güvenlik grupları ek bir segmentasyon katmanı sağlar. Alt ağ düzeyinde beklenmeyen yanal trafiği reddeder. NSG tasarım kılavuzu için bkz. Ağ güvenlik grupları ve uygulama güvenlik grupları.
• Ağ geçidi geçişini dikkatle etkinleştirin. Ağ geçidi geçişi, şirket içi rotaları tüm bağlı ağlara sunar. Güvenlik duvarı kurallarının genişletilmiş bağlantıyı dikkate aldığından emin olun.
• Spoke VM’lerdeki genel IP adreslerini kaldırın. Hub'daki Azure Bastion, VM'leri İnternet'e sunmadan güvenli yönetim erişimi sağlar.
• Her bir spoke'u bir güvenlik sınırı olarak değerlendirin. Farklı uçlardaki iş yükleri varsayılan olarak yalıtılmış durumda kalır. Uçlar arasındaki bağlantı, açık yönlendirme ve güvenlik duvarı kuralları gerektirir.

İlgili makaleler

• Düz ağ topolojisi: Paylaşılan hizmetlere ihtiyaç duymadan tek iş yükleri için
• Azure Sanal WAN topolojisi: uygun ölçekte yönetilen yönlendirme ve bağlantı için
• Çok bölgeli ağ: birden çok Azure bölgesine yayılan iş yükleri için
• Sanal ağlar ve alt ağlar: Hub bileşenleri için alt ağ boyutlandırma
• IP adresi planlaması: Merkez ve uçlar için CIDR planlaması
• Ağ güvenlik grupları ve uygulama güvenlik grupları: uç (spoke) alt ağlarında katmanlı savunma

Daha fazla bilgi edinin

• Azure'da Hub-spoke ağ topolojisi
• Sanal ağ eşleme
• Azure Güvenlik Duvarı'ne genel bakış
• Azure Sanal Ağ Yöneticisi'a genel bakış
• Eşleme için VPN Gateway geçişi
• Azure Bastion ve VNet eşlemesi

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:

Şirket içi ağınıza bağlanma: Kritik geçiş bağımlılığını oluşturmak için hub sanal ağınızda VPN Gateway veya ExpressRoute'u ayarlayın.

Modernleştirme yolculuğunuzda bir sonraki adım:

Çok bölgeli dağıtımınızı planlayın: Müşteriye dönük uygulamalarınızı birincil ve yedek bölgelerin geneline aktif-aktif olarak dağıtın.

Bulutlar arası yolculuğunuzda sonraki adım:

Azure Sanal WAN’ı geçiş modeliniz olarak değerlendirin: Birden çok VPC, şube ve bölge içeren çok bulutlu ortamınız için Sanal WAN’ın mı yoksa hub-spoke mimarisinin mi daha uygun olduğunu değerlendirin.