Cloud mění způsob návrhu infrastruktury, včetně návrhu bran firewall, protože síť už není fyzická ani ve virtuálních sítích LAN. Ve virtuálních sítích nejsou dostupné všechny funkce fyzické sítě. Jde mimo jiné o použití plovoucích IP adres nebo provoz všesměrového vysílání, který ovlivňuje implementaci architektur s vysokou dostupností (HA). Nástroje pro vyrovnávání zatížení pro síťová virtuální zařízení (NVA) mohou/musí být implementovány určitým způsobem, aby bylo možné v rámci virtuální sítě dosáhnout architektury s vysokou dostupností (HA). Tato příručka nabízí strukturovaný přístup k návrhu vysoce dostupných bran firewall v Azure s využitím virtuálních zařízení třetích stran.
Možnosti pro návrh vysoce dostupných síťových virtuálních zařízení
Při nasazování architektur HA je k dispozici několik možností, jak zajistit převzetí služeb při selhání:
- Směrovací tabulky spravované pomocí Azure API: Tato možnost využívá dvě směrovací tabulky, jednu aktivní a jednu pasivní, pro přepínání IP adresy aktivní brány pro všechny služby spuštěné ve virtuální síti nebo podsíti.
- Plovoucí IP adresa spravovaná Azure API: Tato možnost využívá sekundární IP adresu FW, která se dá přesouvat mezi aktivní a pohotovostní branou firewall.
- Správa pomocí Load Balanceru: Tato možnost využívá Azure Load Balancer jako IP adresu brány pro podsíť, která potom přesměrovává provoz na aktivní FW. Může dokonce použít přesměrování provozu typu aktivní–aktivní a poskytovat skutečné vyrovnávání zatížení.
Problémem s prvními dvěma možnostmi spočívá v tom, že převzetí služeb při selhání je pomalé. FW musí dát pokyn k převzetí služeb při selhání, což je v podstatě „rekonfigurace“ služeb Azure prostřednictvím nového nasazení. V závislosti na tom, jak rychle se nasazení dokončí, budou mít toky provozu výpadek několik minut. Kromě toho se nepovoluje konfigurace typu aktivní–aktivní, kde obě brány firewall pracují současně.
Proto se upřednostní třetí možnost. Doba mimo provoz je minimalizovaná, protože nástroj pro vyrovnávání zatížení může při selhání téměř převzít služby při selhání do pohotovostní brány firewall (v režimu aktivní–pasivní) nebo jenom odebrat zatížení z chybové brány firewall (v aktivní–aktivní). Nemůžete ale použít nástroje pro vyrovnávání zatížení jako výchozí brány, protože ovlivňují tok provozu a pakety TCP musí být stavové.
Brány firewall se dvěma rameny
Následující obrázek začíná se dvěma branami firewall (FW-1 a FW-2), externím nástrojem pro vyrovnávání zatížení a back-endovým serverem S1.
Tato architektura je jednoduchá instalace, která se používá pro příchozí provoz. Paket dorazí do nástroje pro vyrovnávání zatížení, který zvolí cílovou bránu firewall ze své konfigurace. Zvolená brána firewall potom odešle provoz na back-endový (webový) server. Pokud má FW-1 povolený SNAT, server S1 uvidí provoz, který pochází z interní IP adresy FW-1, takže také odešle odpověď na paket do FW-1. Převzetí služeb při selhání na FW-2 může v tomto scénáři probíhat rychle. U odchozího provozu můžeme na interní stranu přidat další nástroj pro vyrovnávání zatížení. Když server S1 spustí provoz, použije se stejný princip. Provoz se dostane do interního lb (iLB), který zvolí bránu firewall, která pak přeloží překlad adres (NAT) pro externí řešení:
Brány firewall se třemi rameny
K problémům dochází, když do brány firewall přidáme další rozhraní a potřebujete zakázat překlad adres (NAT) mezi interními zónami. V tomto případě se podívejte na podsíť B a podsíť C:
Směrování L3 mezi interními zónami (podsíť B a podsíť C) bude mít vyrovnané zatížení bez překladu adres (NAT). Toto nastavení bude jasnější a bude se dívat na toky provozu, včetně nástroje pro vyrovnávání zatížení v jiném zobrazení. Následující diagram znázorňuje situaci, kdy jsou interní nástroje pro vyrovnávání zatížení (iLB) propojené s konkrétní síťovou kartou na branách firewall:
Při provozu L3 (bez NAT) uvidí S2 jako zdrojovou adresu IP adresu S1. S2 pak odešle vrácený provoz pro podsíť B (do které patří S1-IP) do iLB v podsíti C. Protože nástroj iLB v podsíti B a nástroji iLB v podsíti C nesynchronují stavy relací, v závislosti na algoritmu vyrovnávání zatížení může provoz na FW-2 skončit. FW-2 ve výchozím nastavení neví nic o počátečním (zeleném) paketu, takže připojení zahodí.
Někteří dodavatelé brány firewall se snaží zachovat stav připojení mezi branami firewall, ale potřebují téměř okamžitou synchronizaci, aby stavy připojení byly aktuální. Obraťte se na dodavatele brány firewall, jestli toto nastavení doporučuje.
Nejlepší způsob, jak se vypořádat s problémem, je jeho eliminace. V příkladu výše toto řešení znamená eliminaci podsítě C, což nám přináší výhody virtualizovaných virtuálních sítí.
Izolovaní hostitelé v podsíti se skupinami zabezpečení sítě
Pokud v jedné podsíti existují dva virtuální počítače, můžete použít skupinu zabezpečení sítě, který izoluje provoz mezi nimi. Ve výchozím nastavení je provoz uvnitř virtuální sítě zcela povolený. Přidání pravidla Odepřít vše do skupiny zabezpečení sítě izoluje všechny virtuální počítače od sebe navzájem.
Virtuální sítě používající stejné back-endové (virtuální) směrovače
Virtuální sítě a podsítě používají jeden systém back-endového směrovače z Azure, a proto není nutné pro každou podsíť zadat IP adresu směrovače. Cíl trasy může být kdekoli ve stejné virtuální síti nebo i mimo ni.
U virtualizovaných sítí můžete řídit trasy v každé podsíti. Tyto trasy mohou také odkazovat na jednu IP adresu v jiné podsíti. Ve výše uvedeném obrázku by to byl nástroj iLB v podsíti D, který vyrovnává zatížení dvou bran firewall. Když S1 spustí provoz (zelený), bude vyrovnávání zatížení na, například FW-1. FW-1 se pak připojí k S2 (stále zeleně). S2 odešle provoz odpovědi na IP adresu S1 (protože je zakázaný naT). Kvůli směrovacím tabulkám používá S2 stejnou IP adresu iLB jako jeho brána. ILB může odpovídat provozu do počáteční relace, takže bude vždy odkazovat tento provoz zpět na FW-1. FW-1 ho pak odešle do S1 a navázání synchronního toku provozu.
Aby toto nastavení fungovalo, musí mít FW směrovací tabulku (interně) odkazující podsíť B a podsíť C na výchozí podsíť GW. Tato podsíť je první logicky dostupná IP adresa v rozsahu podsítě v této virtuální síti.
Dopad na služby reverzních proxy serverů
Když nasazujete službu reverzního proxy serveru, obvykle by byla za FW. Místo toho ho můžete umístit do řádku s FW a ve skutečnosti směrovat provoz přes FW. Výhodou tohoto nastavení je, že služba reverzního proxy serveru uvidí původní IP adresu připojující se klienta:
Pro tuto konfiguraci musí směrovací tabulky v podsíti E odkazovat na podsíť B a podsíť C prostřednictvím interního nástroje pro vyrovnávání zatížení. Některé služby reverzního proxy serveru mají integrované brány firewall, které umožňují v tomto síťovém toku odebrat bránu FW najednou. Předdefinované brány firewall odkazovat z reverzního proxy serveru přímo na servery podsítě B/C.
V tomto scénáři se na reverzním proxy serveru bude vyžadovat překlad adres na základě zdroje (SNAT) a zároveň bude potřeba zabránit tomu, aby zpětný provoz procházel skrz do podsítě A a byl odmítnut bránami FW.
VPN/ER
Azure poskytuje vysoce dostupné služby VPN/ER s podporou protokolu BGP prostřednictvím bran virtuální sítě Azure. Většina architektů si tyto služby nechává pro back-end nebo připojení, které není vystaveno internetu. Toto nastavení znamená, že směrovací tabulka musí pojmout také podsítě za těmito připojeními. I když u připojení mezi podsítí B/C není velký rozdíl, v návrhu návratového provozu je dokončený obrázek:
V této architektuře provoz, který dorazí do brány FW, například z podsítí B až X, se pošle do nástroje iLB, který ho pak pošle jedné z bran firewall. Interní trasa uvnitř brány FW pošle provoz zpět do podsítě GW (první dostupná IP adresa v podsíti D). Nemusíte posílat provoz přímo do samotného zařízení brány, protože jiná trasa v podsíti D bude mít trasu pro podsíť X, která ji odkazuje na bránu virtuální sítě. Sítě Azure se o skutečné směrování postarají.
Návratový provoz přicházející z podsítě X se předá nástroji iLB v podsíti D. GatewaySubnet bude mít také vlastní trasu, která odkazuje podsíť B-C na iLB. Podsíť D není přes iLB. Bude se považovat za obvyklé směrování mezi virtuálními sítěmi.
I když to ve schématu není, dávalo by smysl, aby podsítě B, C, D a brány zahrnovaly také trasu pro podsíť A, která by ji směrovala do nástroje iLB. Toto uspořádání zabrání "běžnému" směrování virtuální sítě, aby se obešly pracovní skupiny zabezpečení. Z pohledu struktury sítě Azure je tato podsíť A jenom další podsítí ve virtuální síti. Nebude považovat podsíť A za odlišnou, i když ji považujete za DMZ, internet atd.
Souhrn
Stručně řečeno, způsob práce s branami firewall v místních sítích (fyzických nebo založených na VLAN) se stejným počtem rozhraní (virtuálních nebo fyzických) není stejný jako v Azure. V případě potřeby stále můžete (do určité míry) mít implementace typu aktivní–aktivní a vyčistit směrovací tabulky, ale existují lepší způsoby jak zajistit, aby bylo možné minimalizovat výpadky při selhání.
Další informace o využití nástrojů pro vyrovnávání zatížení jako bran pro veškerý provoz najdete v přehledu portů s vysokou dostupností.
Další kroky
Další informace o technologiích komponent:
Prozkoumání souvisejících architektur:
- Implementace zabezpečené hybridní sítě
- Hybridní připojení
- Rozšíření místní sítě s využitím sítě VPN
- Volba mezi partnerským vztahem virtuální sítě a bránami sítě VPN
- Řešení potíží s hybridním připojením VPN
- Hvězdicová topologie sítě v Azure
- Připojení samostatných serverů pomocí síťového adaptéru Azure
- Vlastní suverenita dat & požadavky na závažnost dat
- SQL Server 2008 R2 s podporou převzetí služeb při selhání v Azure