Bulut, güvenlik duvarlarının tasarımı dahil, ağ fiziksel veya sanal LAN 'Lar olmadığından, altyapının tasarlanma biçimini değiştiriyor. Sanal ağda (VNet) fiziksel ağın tüm özellikleri kullanılamıyor. Kayan IP adresleri veya yayın trafiği de bu özellikler arasında ve bu durum HA mimarilerinin gerçekleştirilmesini etkiliyor. Sanal ağ içinde yüksek oranda kullanılabilir (HA) bir mimari elde etmek için Ağ Sanal Gereçleri (NVA) yük dengeleyiciler belirli bir yolla uygulanabilir ve uygulanmalıdır. Bu kılavuz üçüncü taraf sanal cihazlar kullanılarak Azure’da HA güvenlik duvarları tasarlamak için yapılandırılmış bir yaklaşımı gösterir.
Yüksek oranda kullanılabilir NVA’lar tasarlama seçenekleri
HA mimarilerinin dağıtımı yapılırken yük devretme sağlamaya yönelik birkaç seçenek vardır:
- Azure API-yönetilen yol tabloları: Bu seçenek, bir VNet/alt ağda çalışan tüm hizmetler için etkin ağ geçidi IP 'sini değiştirmek üzere bir adet etkin olan iki yol tablosu kullanır.
- Azure API-yönetilen kayan IP: Bu seçenek, FWs üzerinde etkin ve bir tek bir ILT arasında taşınabilecek ikincil IP adresi kullanır.
- Load Balancer yönetiliyor: bu seçenek, alt ağ için ağ geçidi ıp 'si görevi gören bir Azure Load Balancer kullanır ve ardından trafiği etkin FW 'e iletir. Hatta doğru yük dengelemesi sağlamak için trafiği etkin-etkin arasında da iletebilir.
İlki iki seçeneğin sorunu yük devretmenin yavaş olmasıdır. ILT, temel olarak yeni bir dağıtım aracılığıyla Azure hizmetleri 'nin "yeniden yapılandırması" olan yük devretmeye yönlendirmelidir. Bu dağıtımın ne kadar hızlı tamamlandığına bağlı olarak trafik akışları birkaç dakika kapalı kalacaktır. Ayrıca, her iki güvenlik duvarının de aynı anda çalıştığı etkin-etkin bir yapılandırmaya izin vermez.
Bu nedenle, üçüncü seçenek en çok tercih edilir. Yük dengeleyici neredeyse anında bekleyen güvenlik duvarına (etkin-edilgen yapılandırmada) yük devrettiğinden veya hatalı güvenlik duvarının yükünü doğrudan kaldırdığından (etkin-etkin yapılandırmada), kapalı kalma süresi en aza indirilir. Ancak, trafik akışını etkilediği ve TCP paketlerinin durum bilgisi olması gerektiği için yük dengeleyiciler "varsayılan ağ geçitleri" olarak kullanılamaz.
İki bacaklı güvenlik duvarları
Aşağıdaki resim & , bir dış yük dengeleyici ve arka uç sunucu S1 ile Iki FWs (fw-1 FW-2) ile başlar.
Bu mimari, gelen trafik için kullanılan basit bir kurulumdır. Yapılandırmasından hedef güvenlik duvarını seçen yük dengeleyiciye bir paket isabet eder. Seçilen güvenlik duvarı trafiği arka uç (web) sunucusuna gönderir. ILT-1, SNAT 'yi etkinleştirmişse, sunucu S1, FW-1 ' in iç IP 'sinden gelen trafiği görür, bu nedenle, yanıtı da ILT-1 ' e gönderir. Bu senaryoda FW-2’ye yük devretme işlemi hızla gerçekleşir. Giden trafik için iç tarafa başka bir yük dengeleyici ekleyebiliriz. Sunucu S1 trafiği başlattığında aynı ilke uygulanır. Trafik, NAT 'yi dış çözüm için çeviren bir güvenlik duvarı seçen iç LB (ILB) ile aynıdır.
Üç bacaklı güvenlik duvarları
Güvenlik duvarına başka bir arabirim eklediğimiz ve iç bölgeler arasında NAT çevirisini devre dışı bırakmanız gereken sorunlar ortaya çıkar. Bu durumda, bkz. alt ağ-B ve alt ağ-C:
İç bölgeler (Subnet-B ve Subnet-C) arasındaki L3 yönlendirmesi NAT olmadan yük dengelemeli olacaktır. Bu kurulum, farklı bir görünümde yük dengeleyicileri dahil trafik akışlarına göz atan daha net hale gelir. Aşağıdaki diyagramda iç Yük Dengeleyicilerin [iLB] ağ geçitlerinde belirli bir NIC’ye bağlandığı görünüm gösterilir:
L3 trafiği (NAT olmadan) ile, S2, kaynak adresi olarak S1 IP adresini görür. S2 daha sonra alt ağ B (S1-IP 'nin ait olduğu) alt ağ-C içindeki ILB 'ye giden trafik için geri dönüş trafiği gönderir. Alt ağ-B ' d a n ve alt ağda ILB olarak, yük dengeleme algoritması trafiğine bağlı olarak, ILT-2 ' ye kadar oturum durumlarını eşitlememe. Varsayılan olarak, FW-2 Başlangıç (yeşil) paketiyle ilgili hiçbir şeyi bilmez, bu nedenle bağlantıyı bırakacak.
Bazı güvenlik duvarı satıcıları güvenlik duvarları arasında bir bağlantı durumu tutmaya çalışır, ancak bağlantı durumlarında neredeyse anında eşitlemeye güncel olmaları gerekir. Güvenlik duvarı satıcınızdan bu kurulumu önerip önermediklerini öğrenin.
Bu sorunla ilgilenmenin en iyi yolu sorunu ortadan kaldırmaktır. Yukarıdaki örnekte bu çözüm, sanallaştırılmış VNET 'lerin avantajlarını gösteren alt ağ-C ' y i ortadan kaldırır.
Ağ Güvenlik Gruplarıyla alt ağdaki konakları yalıtma
Tek bir alt ağda iki sanal makine olduğunda, ikisi arasındaki trafiği yalıtan bir NSG uygulayabilirsiniz. Varsayılan olarak, bir sanal ağ içindeki trafiğe tamamen izin verilir. NSG’ye Tümünü reddet kuralı eklendiğinde tüm sanal makineler birbirinden yalıtılır.
Sanal ağlar aynı arka uç (sanal) yönlendiricilerini kullanır
Sanal ağ/alt ağlar Azure 'dan tek bir arka uç yönlendirici sistemi kullanır ve bu nedenle her alt ağ için bir yönlendirici IP 'si belirtmeniz gerekmez. Yol hedefi aynı sanal ağ içinde veya hatta dışında herhangi bir yer olabilir.
Sanallaştırılmış ağlarda, her alt ağda yolları denetleyebilirsiniz. Bu yollar başka bir alt ağda yer alan tek bir IP’ye de işaret edebilir. Yukarıdaki resimde bu, iki güvenlik duvarının yükünü dengeleyen Subnet-D’deki iLB olabilir. S1, trafik (yeşil) başladığında,, örneğin, FW-1 gibi yük dengelemesi yapılır. Ardından FW-1 S2’ye bağlanır (hala yeşil). S2, yanıt trafiğini S1 (NAT devre dışı) IP 'ye gönderir. Yol tabloları nedeniyle, S2 ağ geçidiyle aynı ILB IP 'sini kullanır. ILB, ilk oturumla trafikle eşleşebilse de bu trafiği her zaman ILT-1 ' e geri göstermelidir. Ardından, FW-1, zaman uyumlu trafik akışı kurarak S1 'e gönderilir.
Bu kurulumun çalışması için, ILT 'ın varsayılan alt ağı GW 'ya alt ağ-B ve alt ağ-C ' y i işaret eden bir rota tablosu (dahili) olması gerekir. Bu alt ağ GW, bu VNET 'teki alt ağ aralığında bulunan ilk mantıksal olarak kullanılabilir IP 'dir.
Ters ara sunucu hizmetleri üzerindeki etkisi
Bir ters proxy hizmeti dağıttığınızda, normalde bu, FW 'in arkasında olacaktır. Bunun yerine FW ile satır içine yerleştirebilir ve trafiği İlt aracılığıyla yönlendirebilirsiniz. Bu kurulumun avantajı, ters proxy hizmetinin bağlantı istemcisinin özgün IP 'sini görecağından emin olur:
Bu yapılandırma için, alt ağ-E ' deki yol tablolarının, iç yük dengeleyici aracılığıyla alt ağ-B ve alt ağ-C ' y i göstermesi gerekir. Bazı ters ara sunucu hizmetlerinde, bu ağ akışında ILT öğesini birlikte kaldırmanıza imkan tanıyan yerleşik güvenlik duvarları vardır. Yerleşik güvenlik duvarları, ters ara sunucudan doğrudan alt ağ-B/C sunucularına işaret ediyor.
Bu senaryoda dönüş trafiğinin aradan akıtılmasını ve güvenlik duvarları tarafından Subnet-A’ya gelmesinin engellenmesini önlemek için ters ara sunucuda da SNAT gerekecektir.
VPN/ER
Azure’da Azure Sanal Ağ Geçitleri aracılığıyla BGP özellikli/yüksek oranda kullanılabilir VPN/ER hizmetleri sağlanır. Mimarların çoğu bunları arka uç ve İnternet’e yönelik olmayan bağlantılar için tutar. Bu kurulum, yönlendirme tablosunun bu bağlantıların arkasındaki alt ağlara da uyum sağlaması gerektiği anlamına gelir. Alt ağ-B/C bağlantısının büyük bir farkı olmasa da, geri dönüş trafiği tasarımında, resmin tamamlanmasını de vardır:
Bu mimaride örneğin Subnet-B’den Subnet-X’e giden ve güvenlik duvarına isabet eden trafik iLB’ye ve oradan da iki güvenlik duvarından birine gönderilebilir. Güvenlik duvarının içindeki yol, trafiği Subnet-GW’ye (Subnet-D’deki kullanılabilir ilk IP) geri gönderir. Ağı ağ geçidi gerecine doğrudan göndermeniz gerekmez, alt ağ-D üzerindeki başka bir yol, sanal ağ geçidineIşaret eden alt ağ-X için bir yola sahip olur. Asıl yönlendirmeyi Azure Ağ üstlenir.
Alt ağ-X ' D e gelen dönüş trafiği alt ağ-D içinde ILB 'ye iletilir. GatewaySubnet Ayrıca ILB 'ye alt ağ-B-C ' y i yönlendiren özel bir yol da olur. Alt ağ-D ILB ile değil. Bu, normal sanal ağlar arası yönlendirme olarak kabul edilir.
Çizimde olmasa da, Subnet-B/C/D/Ağ Geçidi’nin Subnet-A için onu iLB’ye yönlendiren bir yol içermesi mantıklı olabilir. Bu düzenleme, "normal" VNET yönlendirmesini FWs 'yi atlayacak şekilde önler. Çünkü Azure ağ yığınına göre Subnet-A yalnızca sanal ağdaki bir diğer alt ağdır. Bu, alt ağı farklı kabul eder, ancak bunu DMZ/Internet/vb olarak kabul edersiniz.
Özet
Kısacası birçok arabirimle (sanal veya fiziksel) şirket içi (fiziksel/VLAN tabanlı) ağlarınızda güvenlik duvarlarına yaklaşımınız, Azure’daki yaklaşımınızla aynı değildir. Gerekirse yine de (bir dereceye kadar) bunu yapabilirsiniz ama yük devretmeden kaynaklanan kapalı kalma sürelerini en aza indirmenin, etkin-etkin uygulamalara ve temiz yol tablolarına sahip olmanın daha iyi yolları vardır.
Tüm trafik için ağ geçidi olarak yük dengeleyicileri kullanma hakkında daha fazla bilgiyi Yüksek kullanılabilirlik bağlantı noktalarına genel bakış konusunda bulabilirsiniz.
Sonraki adımlar
Bileşen teknolojileri hakkında daha fazla bilgi edinmek için:
İlgili mimarileri keşfedin:
- Güvenli hibrit ağ uygulama
- Karma bağlantı
- VPN kullanarak şirket içi ağı genişletme
- Sanal ağ eşlemesi ve VPN ağ geçitleri arasında seçim yapma
- Karma VPN bağlantısında sorun giderme
- Azure'da merkez-uç ağ topolojisi
- Azure Ağ Bağdaştırıcısı’nı kullanarak tek başına sunucuları bağlama
- Özel veri bağımsızlığı veri yer çekim gereksinimleri
- SQL Server 2008 R2 yük devretme kümesi