Ağ artık fiziksel veya sanal LAN'larda olmadığından bulut, güvenlik duvarlarının tasarımı da dahil olmak üzere altyapının tasarım şeklini 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 tarafından yönetilen yol tabloları: Bu seçenek, bir VNet/alt ağ üzerinde çalışan tüm hizmetler için etkin ağ geçidi IP'sini değiştirmek için biri etkin, biri pasif olmak üzere iki yol tablosu kullanır.
- Azure API tarafından yönetilen kayan IP: Bu seçenek, FW'lerde etkin ve stand-by FW arasında taşınabilen ikincil bir IP adresi kullanır.
- Load Balancer tarafından yönetilen: Bu seçenek, alt ağın ağ geçidi IP'si olarak hareket etmek için bir Azure Load Balancer kullanır ve ardından trafiği etkin FW'ye 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. FW'nin yük devretmeyi yönlendirmesi gerekir. Bu, temelde yeni bir dağıtım aracılığıyla Azure hizmetlerinin "yeniden yapılandırılması" şeklindedir. 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 da 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 yük dengeleyicileri trafik akışını etkilediğinden ve TCP paketlerinin durum bilgisi olması gerektiğinden yalnızca "varsayılan ağ geçitleri" olarak kullanamazsınız.
İki bacaklı güvenlik duvarları
Aşağıdaki resim iki güvenlik duvarı (FW-1 ve FW-2), bir dış yük dengeleyici ve arka uç sunucusu (S1) ile başlar.
Bu mimari, gelen trafik için kullanılan basit bir kurulumdur. 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. FW-1'de SNAT etkinse, sunucu S1 FW-1'in iç IP'sinden gelen trafiği görür, bu nedenle paketin yanıtını da FW-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. S1 sunucusu trafiği başlattığında aynı ilke geçerli olur. Trafik iç LB'ye (iLB) isabet eder ve bu da NAT'yi dış çözünürlük için çeviren bir güvenlik duvarı seçer:
Üç bacaklı güvenlik duvarları
Güvenlik duvarına başka bir arabirim eklediğimizde ve iç bölgeler arasında NAT çevirisini devre dışı bırakmanız gerektiğinde sorunlar ortaya çıkar. Bu durumda bkz. Subnet-B ve Subnet-C:
İç bölgeler (Subnet-B ve Subnet-C) arasındaki L3 yönlendirmesi NAT olmadan yük dengelemeli olacaktır. Bu kurulum, yük dengeleyiciler de dahil olmak üzere trafik akışlarına farklı bir görünümde bakarak 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ğinde (NAT olmadan), S2 kaynak adres olarak S1 IP adresini görür. Ardından S2, B alt ağı (S1-IP'nin ait olduğu) için dönüş trafiğini Alt Ağ-C'deki iLB'ye gönderir. Subnet-B'deki iLB ve Subnet-C'deki iLB oturum durumlarını eşitlemediğinden, yük dengeleme algoritmasına bağlı olarak trafik FW-2'de sona erebilir. FW-2 varsayılan olarak ilk (yeşil) paket hakkında hiçbir şey bilmez, bu nedenle bağlantıyı bırakır.
Bazı güvenlik duvarı satıcıları güvenlik duvarları arasında bağlantı durumunu korumayı dener, ancak bağlantı durumlarında neredeyse anında eşitlemeye ihtiyaç duyarlar. 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 Subnet-C'yi ortadan kaldırmak anlamına gelir ve bu da bizi Sanallaştırılmış sanal ağların avantajlarına getirir.
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ğlar/alt ağlar Azure'dan tek bir arka uç yönlendirici sistemi kullanır ve bu nedenle her alt ağ için yönlendirici IP'sini 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 trafiği (yeşil) başlattığında yük dengelemesi, örneğin FW-1 olur. Ardından FW-1 S2’ye bağlanır (hala yeşil). S2, yanıt trafiğini S1 IP'sine gönderir (NAT devre dışı bırakılmıştır). Yol tabloları nedeniyle S2, ağ geçidiyle aynı iLB IP'sini kullanır. iLB, trafiği ilk oturumla eşleştirebilir, bu nedenle her zaman bu trafiği FW-1'e geri işaret eder. Ardından FW-1 bunu S1'e göndererek zaman uyumlu bir trafik akışı oluşturur.
Bu kurulumun çalışması için FW'nin Alt Ağ-B ve Subnet-C'yi varsayılan alt ağı GW'ye işaret eden bir yol tablosu (dahili olarak) olması gerekir. Bu alt ağ GW, bu sanal ağın alt ağ aralığındaki ilk mantıksal olarak kullanılabilir IP'dir.
Ters ara sunucu hizmetleri üzerindeki etkisi
Ters ara sunucu hizmeti dağıttığınızda normalde FW'nin arkasında olur. Bunun yerine FW ile aynı hizaya getirebilirsiniz ve aslında trafiği FW üzerinden yönlendirebilirsiniz. Bu kurulumun avantajı, ters ara sunucu hizmetinin bağlanan istemcinin özgün IP'sini görmesidir :
Bu yapılandırma için, Subnet-E'de yol tablolarının iç yük dengeleyici aracılığıyla Subnet-B ve Subnet-C'yi yönlendirmesi gerekir. Bazı ters ara sunucu hizmetleri, FW'yi bu ağ akışında birlikte kaldırmanıza olanak sağlayan yerleşik güvenlik duvarlarına sahiptir. Yerleşik güvenlik duvarları, ters ara sunucudan doğrudan Subnet-B/C sunucularına işaret eder.
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 da bu bağlantıların arkasındaki alt ağları barındırması gerektiği anlamına gelir. Subnet-B/C bağlantısında büyük bir fark olmasa da, dönüş trafiğinin tasarımında resim tamamlanı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. Trafiği doğrudan Ağ Geçidi gerecinin kendisine göndermeniz gerekmez çünkü Subnet-D üzerindeki başka bir yol, Subnet-X için Sanal Ağ Gateway'e işaret eden bir yola sahip olacaktır. Asıl yönlendirmeyi Azure Ağ üstlenir.
Subnet-X'ten gelen dönüş trafiği Subnet-D'deki iLB'ye iletilir. GatewaySubnet, Subnet-B-C'yi iLB'ye yönlendiren özel bir yola da sahip olur. Subnet-D iLB üzerinden 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" sanal ağ yönlendirmesinin FW'leri atlamasına engel olur. Çünkü Azure ağ yığınına göre Subnet-A yalnızca sanal ağdaki bir diğer alt ağdır. Alt Ağ-A'ya farklı davranmaz, ancak bunu DMZ/internet/vb. olarak ele alırsınız.
Ö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.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- Roelf Zomerman | Üst Düzey Bulut Çözümü Mimarı
Sonraki adımlar
Bileşen teknolojileri hakkında daha fazla bilgi edinin:
İlgili kaynaklar
İlgili mimarileri keşfedin: