Cloud mění způsob návrhu infrastruktury, včetně návrhu bran firewall, protože síť už není fyzická nebo 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é rozhraním Azure API: Tato možnost používá dvě směrovací tabulky, jednu aktivní, jednu pasivní k přepnutí 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á rozhraním Azure API: Tato možnost používá sekundární IP adresu na FWs, kterou je možné přesouvat mezi aktivní a samostatnou FW.
- Spravovaná službou Load Balancer: Tato možnost používá Azure Load Balancer k tomu, aby fungovala jako IP adresa brány pro podsíť, která pak předá provoz aktivnímu 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í instruovat 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. Navíc neumožňuje konfiguraci aktivní-aktivní, kde obě brány firewall fungují současně.
To je důvod, proč je třetí možnost upřednostňovaná. 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žívat jen 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 FW-1. Převzetí služeb při selhání na FW-2 může v tomto scénáři probíhat rychle. Pro odchozí provoz můžeme na interní straně 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 nástroje pro vyrovnávání zatížení (iLB), který zvolí bránu firewall, která pak přeloží překlad adres (NAT) pro externí překlad:
Brány firewall se třemi rameny
K problémům dochází, když do brány firewall přidáme další rozhraní a vy potřebujete zakázat překlad překladu 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ší, když se podíváte na toky provozu, včetně nástrojů 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 překladu adres (NAT) uvidí S2 JAKO zdrojovou adresu IP adresu S1. S2 pak odešle návratový provoz pro podsíť B (do které patří S1-IP adresa) do nástroje iLB v podsíti C. Vzhledem k tomu, že iLB v podsíti B a iLB v podsíti C nesynchronizují stavy relací, v závislosti na provozu algoritmu vyrovnávání zatížení může končit FW-2. FW-2 ve výchozím nastavení nezná 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řebovali by téměř okamžitou synchronizaci, aby byli v stavech připojení 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ředchozím příkladu toto řešení znamená odstranění 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íť nebo podsítě používají jeden back-endový směrovač z Azure a proto není nutné pro každou podsíť zadávat 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. Vzhledem k tomu, že S1 spouští provoz (zelený), bude vyrovná se zatížením, 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 překlad adres (NAT je zakázaný). Kvůli směrovacím tabulkám používá S2 stejnou IP adresu nástroje iLB jako její brána. ILB může odpovídat provozu počáteční relaci, takže vždy bude odkazovat tento provoz zpět na FW-1. FW-1 ji pak odešle do S1 a vytvoří synchronní tok 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íť GW je první logicky dostupná IP adresa v rozsahu podsítí v dané virtuální síti.
Dopad na služby reverzních proxy serverů
Když nasadíte službu reverzního proxy serveru, obvykle by byla za FW. Místo toho ho můžete umístit do souladu s FW a skutečně směrovat provoz přes FW. Výhodou tohoto nastavení je, že služba reverzního proxy serveru by viděla původní IP adresu připojujícího 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í odebrat FW všechny společně v tomto toku sítě. Integrované brány firewall ukazují 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í také pojmout podsítě za těmito připojeními. I když připojení podsítě B/C není velký rozdíl, je v návrhu návratového provozu dokončení obrázku:
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). Provoz nemusíte posílat přímo do samotného zařízení brány, protože jiná trasa v podsíti D bude obsahovat trasu pro podsíť X, která ji přesměruje 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řesměruje do interního nástroje pro vyrovnávání zatížení v podsíti D. Podsíť GatewaySubnet bude mít také vlastní trasu, která odkazuje podsíť B-C na iLB. Podsíť D není přes interní nástroj pro vyrovnávání zatížení. 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í zabraňuje "běžnému" směrování virtuální sítě, aby se vyhnulo obejití FWs. Z pohledu struktury sítě Azure je tato podsíť A jenom další podsítí ve virtuální síti. Nebude zacházet s podsítí A jinak, i když ji považujete za DMZ, Internet atd.
Shrnutí
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í.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- Roelf Zomerman | Vedoucí architekt cloudových řešení
Další kroky
Další informace o technologiích komponent:
Související prostředky
Prozkoumejte související architektury: