Çok merkezli ve uçlu topolojiyi yönlendirmek için Azure Güvenlik Duvarı'nı kullanma

Merkez-uç topolojisi, Azure'da ağ kaynaklarını birleştiren ve ağ hizmetlerini merkezileştiren yaygın bir ağ mimarisi düzenidir. Bu topoloji, farklı abonelikler veya kiracılar arasında dağıtılan sanal ağlara ağ bağlantısı ve güvenlik sağlar.

Merkez-uç mimarilerini iki şekilde uygulayabilirsiniz:

• Kendi kendine yönetilen merkez-uç (geleneksel): Merkez sanal ağları ve yönlendirme yapılandırması üzerinde tam denetime sahipsiniz.
• Sanal WAN: Microsoft, merkez sanal ağlarını yönetir ve yönlendirme amacı ve yönlendirme ilkeleri gibi özellikler aracılığıyla yönetimi basitleştirir.

Bu makale, merkez sanal ağı ve Azure Güvenlik Duvarı dağıtımı üzerinde tam görünürlüğe ve denetime sahip olduğunuz kendi kendine yönetilen merkez-uç topolojilerine odaklanır.

Azure Sanal Ağ Yöneticisi'ni (AVNM) kullanarak kendi kendine yönetilen merkez-uç uygulamasının yönetim yükünü azaltabilirsiniz. AVNM, Azure Route Tablolarının yapılandırmasını otomatikleştirebilir, ancak genel tasarım ve teknikler el ile yaklaşıma kıyasla değişmez. Bu makalenin içeriği, AVNM kullanmanız veya kendi kendine yönetilen merkez-uç topolojinizi el ile yapılandırmanız için geçerlidir.

Uç sanal ağlarındaki Azure Route Tablolarının alternatifi, uç sanal ağlarında Varsayılan yol ekleme bölümünde belirtildiği gibi Azure Route Server ile alt ağlara yollar eklemektir. Ancak bu düzen, Azure Route Server ile VPN veya ExpressRoute sanal ağ geçitleri arasındaki etkileşimden kaynaklanabilir karmaşıklık nedeniyle yaygın olarak kullanılmaz.

Kendi kendine yönetilen merkez-uç kurulumunda:

• Merkez: VPN, ExpressRoute veya Software-Defined Geniş Alan Ağı (SD-WAN) aracılığıyla şirket içi ağınıza merkezi bağlantı noktası olarak hizmet veren bir sanal ağ. Güvenlik duvarları gibi ağ güvenlik cihazları hub sanal ağına dağıtılır.
• Dallar: Merkeze eşlenen ve iş yüklerinizi barındıran sanal ağlar.

Birden çok bölgeye yayılan iş yükleri için genellikle bölge başına bir merkez dağıtarak bu bölgedeki uçlardan gelen trafiği toplarsınız. Aşağıdaki diyagramda, her bölgede iki uç sanal ağı olan iki bölgeli, kendi kendine yönetilen merkez-uç mimarisi gösterilmektedir:

Tek bölgeli merkez-uç mimarisi

Çok bölgeli tasarımı anlamak için öncelikle tek bölgeli kavramları anlamanız gerekir. Aşağıdaki diyagramda ilk bölge için yönlendirme tablosu yapılandırması gösterilmektedir:

Kullanıcı tanımlı yol yapılandırmasını anlamak için tek bölgeli tasarımdaki her olası trafik akışının yönlendirme gereksinimlerini göz önünde bulundurun:

• Uçlar arası trafik: Uçlar birbiriyle eşlenmez ve sanal ağ eşlemesi geçişli değildir. Her uç, merkez sanal ağına varsayılan olarak nasıl yönlendirilmeyi bilir, ancak diğer uçlara yönlendirmez. Tüm düğüm alt ağlarına uygulanan bir yol 0.0.0.0/0, düğümden-düğüme trafiği kapsar.
• Spoke ve internet trafiği: Spoke rota tablosundaki 0.0.0.0/0 rota, kamuya açık internete gönderilen trafiği de kapsar. Bu yol, varsayılan olarak genel alt ağlara dahil edilen sistem yolunun üzerine yazar. Daha fazla bilgi için bkz . Azure'da varsayılan giden erişim.
• İnternet'ten uçlara trafik: İnternet'ten uça trafik genellikle önce Azure Güvenlik Duvarı'ndan geçer. Azure Güvenlik Duvarı'nın, kaynak IP adresini de (Kaynak Ağ Adresi Çevirisi veya SNAT) çeviren Hedef Ağ Adresi Çevirisi (DNAT) kuralları yapılandırılmıştır. Çapraz iş yükleri, trafiği Azure Güvenlik Duvarı alt ağı üzerinden geliyor olarak algılar. Sanal ağ eşlemesi merkez ()10.1.0.0/24 için sistem yolları oluşturur, böylece uçlar dönüş trafiğini nasıl yönlendireceklerini bilir.
• Şirket içi-uç ve uç-şirket içi trafik: Her yönü ayrı ayrı göz önünde bulundurun:
  • Şirket içi uç trafiği: Trafik şirket içi ağdan VPN veya ExpressRoute ağ geçitlerine ulaşır. Azure'da varsayılan yönlendirme ile, her uç için GatewaySubnet'te (ve merkez sanal ağındaki diğer alt ağlarda) bir sistem yolu oluşturulur. Bu sistem yollarını geçersiz kılmanız ve sonraki atlamayı Azure Güvenlik Duvarı'nın özel IP adresine ayarlamanız gerekir. Bu örnekte, ağ geçidi alt ağıyla ilişkilendirilmiş bir yol tablosunda her uç (10.1.1.0/24 ve 10.1.2.0/24) için bir tane olmak üzere iki yol gerekir. Sistem yolları, ağ geçidi alt ağına yapılan sanal ağ eşlemeleri tarafından daha belirgin şekilde eklenmiş olduğundan, bütün bağlı sanal ağları kapsayan bir özet (10.1.0.0/16, /24 ile karşılaştırıldığında /16 özeti) kullanmak işe yaramaz. Bu yol tablosunda Ağ geçidi yollarını yay iki durumlu düğmesi etkinleştirilmelidir ( Evet olarak ayarlanmıştır), aksi takdirde ağ geçidi yönlendirmesi öngörülemez hale gelebilir.
  • Uçtan şirket içi trafiğe: Merkez ile uçlar arasındaki sanal ağ eşlemelerinin merkez tarafında Ağ Geçidi Aktarımına İzin Ver ve uç tarafında Uzak Ağ Geçitlerini Kullan etkin olmalıdır. VPN ve ExpressRoute ağ geçitlerinin Sınır Geçit Protokolü (BGP) üzerinden konuşma öneklerini şirket içi ağlara iletmesi için bu ayarlar gereklidir. Bu ayarlar, varsayılan olarak bağlantı noktalarının tesisten Azure'a duyurulan ön ekleri öğrenmesine de neden olur. Şirket içi ön ekleri uç yönlendirme tablosundaki kullanıcı tanımlı rotadan 0.0.0.0/0 daha özel olduğundan, uçlardan şirket içi trafiğe giden trafik varsayılan olarak güvenlik duvarını atlar. Bu durumu önlemek için, şirket içi ön eklerinin öğrenilmesini engellemek ve şirket içi trafik için doğru rotanın kullanılmasını sağlamak amacıyla uç yönlendirme tablosunda Gateway Rotalarını Yay anahtarını Hayır olarak ayarlayın.

Not

Ağ özeti yerine ağ geçidi alt ağıyla ilişkilendirilmiş yol tablosundaki tam uç sanal ağ IP ön eklerini kullanın. Uçlarla sanal ağ eşlemeleri tarafından sunulan sistem yolları, kullanıcı tanımlı yolunuzu geçersiz kılar çünkü bunlar daha belirgindir.

Yönetim yükünü azaltmak için hem uç alt ağlarıyla ilişkilendirilmiş yol tablosunu hem de ağ geçidi alt ağıyla ilişkilendirilmiş yönlendirme tablosunu Azure Virtual Network Manager kullanarak yönetebilirsiniz. Daha fazla bilgi için bkz. Sonraki atlama olarak Azure Güvenlik Duvarı'nı kullanma.

Hub sanal ağ iş yükleri

İş yüklerini merkez sanal ağına (Active Directory etki alanı denetleyicileri, DNS sunucuları veya diğer paylaşılan altyapı gibi) dağıtırsanız, bu durum merkez-uç tasarımının karmaşıklığını artırır. İş yüklerini hub'a yerleştirmekten kaçınmanızı ve bunun yerine bunları paylaşılan hizmetler için ayrılmış bir uçta dağıtmanızı öneririz.

Bu bölümde, bu karmaşıklığın gereksinimleriniz için kabul edilebilir olup olmadığını değerlendirebilmeniz için hub iş yükleri için gereken yapılandırma açıklanmaktadır. Ayrıca asimetrik trafiğe ve paket düşmelerine neden olabilecek yaygın bir hatayı da açıklıyoruz.

Aşağıdaki diyagramda merkez sanal ağında bir iş yükü alt ağına sahip tek bölgeli bir tasarım gösterilmektedir:

Kritik ayrıntı, hem ağ geçidi alt ağında hem de uç alt ağlarında yapılandırılan kullanıcı tanımlı yolların , hub sanal ağ ön ekinin tamamı için değil, belirli iş yükü alt ağı için tanımlanmasıdır:

• Ağ geçidi alt ağı yapılandırması: Ağ geçidi alt ağında merkez sanal ağının10.1.0.0/24 tamamı için (bu örnekte) bir yol yapılandırmak, merkez sanal ağının sistem yolunu geçersiz kılar. Bu, VPN veya ExpressRoute ağ geçitleri arasındaki alt ağ içi denetim trafiğinin güvenlik duvarına gönderilmesine neden olur ve ağ geçidi işlemini kesintiye uğratabilir.
• Uç alt ağ yapılandırması: Merkez sanal ağının tamamı için uç alt ağlarında bir yol yapılandırmak (10.1.0.0/24 bu örnekte), eşleme tarafından merkez sanal ağıyla oluşturulan sistem yolunu geçersiz kılar. Hub'a gönderilen tüm trafik, Kaynak Ağ Adresi Çevirisi (SNAT) üzerinden giden internet-uç trafiği gibi Azure Güvenlik Duvarı'ndan alınan trafik de dahil olmak üzere Azure Güvenlik Duvarı'na gönderilir. Bu yapılandırma asimetrik trafik oluşturur ve paket kayıplarına neden olur.

Not

İş yüklerini merkez sanal ağına dağıtırsanız, kullanıcı tanımlı yollarınızda sanal ağ IP ön ekinin tamamını kullanmayın.

Alt ağlar arası trafik denetimi

Geçerli kurulumda, uçlar arasındaki trafik güvenlik duvarına gönderilir, ancak uç içi trafik uç sanal ağı içinde kalır ve Ağ Güvenlik Grupları kullanılarak denetlenmektedir. Bu tasarım sanal ağları bir güvenlik sınırı olarak kabul eder: güvenlik duvarı yalnızca bir sanal ağdan çıkan veya sanal ağa giren trafiği inceler.

Aynı uç sanal ağındaki alt ağlar arasındaki trafiği incelemek için, aşağıdaki diyagramda gösterildiği gibi uç alt ağlarıyla ilişkili yol tablosunu değiştirin:

Önceki diyagramda, her uç sanal ağında iki uç alt ağı tanıtılır ve A2 sanal ağındaki uçlar için rota tabloları açıklanmıştır. Her alt ağa yüklenecek yollar farklı olduğundan, alt ağlar arası trafiğin güvenlik duvarına gönderilmesi için her alt ağın ayrı bir yol tablosu olması gerekir.

A21 alt ağı için şu iki ek yola ihtiyacınız vardır:

• 10.1.2.0/24 Rotası: Sanal ağ içi trafiği için sistem rotasını geçersiz hale getirir. Diğer yollar olmadan tüm sanal ağ içi trafik Azure Güvenlik Duvarı'na, hatta aynı alt ağdaki sanal makineler arasındaki trafiğe gönderilir.
• Sonraki 10.1.2.0/26 ile adresine yönlendirme: Önceki yola yönelik bir özel durumdur, bu nedenle bu alt ağ içindeki trafik güvenlik duvarına gönderilmez ancak sanal ağ içinde yerel olarak yönlendirilir. Bu yol her alt ağa özgüdür ve bu nedenle her alt ağ için ayrı bir yol tablosuna ihtiyacınız vardır.

SD-WAN ağ sanal cihazları

VPN veya ExpressRoute ağ geçitleri yerine SD-WAN Ağ Sanal Gereçleri (NVA) kullanıyorsanız, tasarım aşağıdaki diyagramda gösterildiği gibi benzerdir:

Azure'da SD-WAN NVA'ları tümleştirmenin farklı yolları vardır. Daha fazla bilgi için bkz. Azure merkez-uç ağ topolojileriyleSD-WAN tümleştirmesi. Bu makalede, trafiği SD-WAN ağlara yönlendirmeye yönelik en yaygın yöntemlerden biri olan Azure Route Server'ı kullanarak tümleştirme gösterilmektedir. SD-WAN NVA'lar, şirket içi ön ekleri BGP aracılığıyla Azure Route Server'a tanıtmaktadır. Azure Route Server, Azure Güvenlik Duvarı'nın şirket içi ağlar için yönlendirme bilgilerine sahip olması için bu ön ekleri Azure Güvenlik Duvarı alt ağına ekler. Uç yönlendirme tablosunda "Ağ geçidi yollarını yay" seçeneği devre dışı bırakıldığından uçlar şirket içi ön ekleri öğrenmez.

Her bir konuşlandırılmış sanal ağın ön ekini, NVA alt ağıyla ilişkili yönlendirme tablosunda yapılandırmak istemiyorsanız, SD-WAN NVA'larını kendilerine ayrılmış bir sanal ağa yerleştirebilirsiniz. NVA sanal ağı, doğrudan eşlenmedikleri için uç ön eklerini öğrenmez ve aşağıdaki diyagramda gösterildiği gibi bir özet yolu mümkündür:

Çok bölgeli merkez-uç mimarisi

Trafiğin tek bir merkez-uç bölgesinde nasıl çalıştığını anladıktan sonra tasarımı çok bölgeli bir mimariye genişletmek oldukça kolaydır. Aşağıdaki diyagramda iki bölgede (A ve B) hub'larla güncelleştirilmiş bir ağ tasarımı gösterilmektedir:

Yapılandırmaya eklenen tek şey, her bölgedeki Azure Güvenlik Duvarı alt ağlarıyla ilişkilendirilmiş yol tablolarıdır. Her merkez sanal ağı yalnızca doğrudan eşlenen sanal ağların ön eklerini bilir, bu nedenle uzak uçların ön ekleri için yönlendirme yoktur. Her bir bölge için trafiğin ilgili Azure Güvenlik Duvarı'na yönlendirilmiş olması için her Azure Güvenlik Duvarı alt ağı için kullanıcı tanımlı yollar ekleyin.

Bu örnekte her bölge kolayca özetlenebilir:

• Bölge A ön ekleri içerir 10.1.0.0/16
• Bölge B içinde 10.2.0.0/16 ön ekleri bulunur.

Her bölgede kolayca özetlenen IP adreslerini tanımlamak, yönlendirme yapılandırmanızı kolaylaştırır. Aksi takdirde, her uzak bağlantı için bir yol oluşturmanız gerekir.

Güvenlik duvarının VPN ve ExpressRoute ağ geçitlerinden şirket içi yolları öğrenebilmesi için Azure Güvenlik Duvarı alt ağ yolu tablosunda ağ geçidi yollarını etkinleştirin.

Not

Azure Güvenlik Duvarı bir yönetim ağ arabirimi kartı olmadan kurulursa, daha önce açıklandığı gibi daha belirli yollar eklemek için Azure Güvenlik Duvarı alt ağı "İnternet"i sonraki durak olarak belirleyen varsayılan bir yol gerektirir.

Çok bölgeli bir ortamda kullanıcı tanımlı yolların yönetimini basitleştirmek için Azure Sanal Ağ Yöneticisi'ni kullanabilirsiniz. Daha fazla bilgi için bkz. AVNM ile birden çok merkez-uç topolojisinde kullanıcı tanımlı yolları yönetme.

Sonraki adımlar

• Azure Güvenlik Duvarı dağıtmayı ve yapılandırmayı öğrenin.