Nasazení vysoce dostupných síťových virtuálních zařízení

Tento článek vysvětluje nejběžnější možnosti nasazení sady síťových virtuálních zařízení (NVA) pro zajištění vysoké dostupnosti v Azure. Síťové virtuální zařízení se obvykle používá k řízení toku provozu mezi segmenty sítě klasifikovanými s různými úrovněmi zabezpečení, například mezi virtuální sítí De-Militarized zónou (DMZ) a veřejným internetem nebo pro připojení externích umístění k Azure, jako jsou zařízení VPN nebo SDWAN (Software-Defined WAN).

Existuje mnoho vzorů návrhu, ve kterých se síťová virtuální zařízení používají ke kontrole provozu mezi různými zónami zabezpečení, například:

• Kontrola výchozího přenosu dat z virtuálních počítačů na internet a zabránění exfiltraci dat
• Kontrola příchozího přenosu dat z internetu do virtuálních počítačů a zabránění útokům
• Pokud chcete filtrovat provoz mezi virtuálními počítači v Azure, abyste zabránili laterálním přesunům ohrožených systémů.
• Pokud chcete filtrovat provoz mezi místními systémy a virtuálními počítači Azure, pokud se považují za patřící do různých úrovní zabezpečení. (Například pokud Azure hostuje DMZ a místní interní aplikace.)
• Ukončení tunelů VPN nebo SDWAN z externích umístění, jako jsou místní sítě nebo jiné veřejné cloudy.

Existuje mnoho příkladů síťových virtuálních zařízení, včetně následujících:

• Síťové brány firewall
• Reverzní proxy servery vrstvy 4
• Koncové body sítě VPN IPsec
• Zařízení SDWAN
• Webové reverzní proxy servery s funkcí firewallu webových aplikací
• Internetové proxy servery, které omezují, ke kterým internetovým stránkám je možné přistupovat z Azure
• Nástroje pro vyrovnávání zatížení vrstvy 7

Všechna tato síťová virtuální zařízení je možné vložit do návrhu Azure se vzory popsanými v tomto článku. Dokonce i síťová virtuální zařízení Azure, jako je azure firewall a Azure Application Gateway, použít návrhy popsané dále v tomto článku. Pochopení těchto možností je důležité jak z hlediska návrhu, tak při řešení potíží se sítí.

První otázka, na kterou je potřeba odpovědět, je důvod, proč je vyžadována vysoká dostupnost síťových virtuálních zařízení. Důvodem je to, že tato zařízení řídí komunikaci mezi síťovými segmenty. Pokud nejsou dostupné, síťový provoz nemůže tokovat a aplikace přestanou fungovat. Naplánované a neplánované výpadky občas způsobí výpadky síťových virtuálních zařízení (jako jakýkoli jiný virtuální počítač v Azure nebo jiném cloudu). Instance se přenesou i v případě, že jsou tato síťová virtuální zařízení nakonfigurovaná se spravovanými disky Premium tak, aby poskytovala smlouvu SLA s jednou instancí v Azure. Proto vysoce dostupné aplikace vyžadují alespoň druhé síťové virtuální zařízení, které může zajistit připojení.

požadavky na : tento článek předpokládá základní znalosti sítí Azure, azure Load Balancersa směrování provozu virtuální sítě (UDRS).

Při výběru nejlepší možnosti nasazení síťového virtuálního zařízení do virtuální sítě Azure je nejdůležitějším aspektem, který je potřeba vzít v úvahu, jestli dodavatel síťového virtuálního zařízení ověřil a ověřil tento konkrétní návrh. Dodavatel musí také poskytnout požadovanou konfiguraci síťového virtuálního zařízení, která je potřebná k integraci síťového virtuálního zařízení v Azure. Pokud dodavatel síťového virtuálního zařízení nabízí různé alternativy jako podporované možnosti návrhu síťového virtuálního zařízení, můžou rozhodnutí ovlivnit tyto faktory:

• Doba konvergence: jak dlouho trvá v každém návrhu, aby se provoz od instance síťového virtuálního zařízení, který selhal, ztlumil?
• Podpora topologie: Jaké konfigurace síťového virtuálního zařízení podporují jednotlivé možnosti návrhu? Aktivní/aktivní, aktivní/pohotovostní, clustery síťového virtuálního zařízení se škálováním na více systémů s redundancí n+1?
• Symetrie provozu: Přinutí konkrétní návrh síťového virtuálního zařízení provádět překlad zdrojových síťových adres (SNAT) u paketů, aby se zabránilo asymetrickým směrováním? Nebo je symetrie provozu vynucena jinými prostředky?

Následující části v dokumentu popisují nejběžnější architektury používané k integraci síťových virtuálních zařízení do hvězdicové sítě.

Přehled architektur vysoké dostupnosti

Následující architektury popisují prostředky a konfiguraci nezbytné pro vysoce dostupné síťové virtuální zařízení:

Návrh Load Balanceru

Tento návrh používá dva nástroje pro vyrovnávání zatížení Azure k zveřejnění clusteru síťových virtuálních zařízení pro zbytek sítě. Tento přístup se často používá jak pro stavové, tak bezstavové síťové virtuální zařízení:

• Interní Load Balancer se používá k přesměrování interního provozu z Azure a místního prostředí do síťových virtuálních zařízení. Tento interní nástroj pro vyrovnávání zatížení je nakonfigurovaný s pravidly portů vysoké dostupnosti, aby se každý port TCP/UDP přesměroval na instance síťového virtuálního zařízení.
• Veřejný Load Balancer zveřejňuje síťová virtuální zařízení na internetu. Vzhledem k tomu, že porty vysoké dostupnosti pro příchozí provoz, je potřeba otevřít každý jednotlivý port TCP/UDP ve vyhrazeném pravidlu vyrovnávání zatížení.

Následující diagram popisuje posloupnost segmentů směrování, které pakety z internetu na aplikační server v paprskové virtuální síti sledují procházením síťového virtuálního zařízení brány firewall za účelem řízení provozu do a z veřejného internetu (označovaného také jako provoz na sever/jih):

Stáhněte si soubor Visio této architektury.

Mechanismus odesílání provozu z paprsků do veřejného internetu prostřednictvím síťových virtuálních zařízení je User-Defined trasa pro 0.0.0.0/0 s ip adresou interního nástroje pro vyrovnávání zatížení.

Pro provoz mezi Azure a veřejným internetem prochází každý směr toku provozu jinou službou Azure Load Balancer. K tomu dochází i v případě, že síťové virtuální zařízení brány firewall má jednu síťovou kartu pro veřejné i interní sítě, protože paket příchozího přenosu dat prochází veřejným albem a výstupní paket prochází interním albem. Vzhledem k tomu, že oba směry toku procházející různými nástroji pro vyrovnávání zatížení, pokud je vyžadována symetrie provozu, stejně jako obvykle u většiny bran firewall, musí instance síťového virtuálního zařízení provádět překlad zdrojových síťových adres (SNAT), aby přilákaly návratový provoz a vyhnuly se asymetrii provozu.

Stejný návrh s nástroji pro vyrovnávání zatížení je možné použít i ke kontrole provozu mezi Azure a místními sítěmi (východ/západ), kde se týká pouze interního nástroje pro vyrovnávání zatížení:

Mechanismus odesílání provozu mezi paprsky prostřednictvím síťových virtuálních zařízení je úplně stejný, takže není k dispozici žádný jiný diagram. V ukázkových diagramech výše, protože paprsk1 neví o rozsahu paprsku 2, 0.0.0.0/0 trasy definované uživatelem odesílají provoz adresovaný paprsku2 internímu službě Azure Load Balancer síťového virtuálního zařízení.

Pro přenosy mezi místními sítěmi a Azure nebo mezi virtuálními počítači Azure je v síťových virtuálních zařízeních s jedním síťovým rozhraním zaručená interní službou Azure Load Balancer: když oba směry toku provozu procházejí stejným nástrojem pro vyrovnávání zatížení Azure, bude stejná instance síťového virtuálního zařízení zvolena nástrojem pro vyrovnávání zatížení. V případě síťových virtuálních zařízení se dvěma síťovými adaptéry, kde je pro každý smysl komunikace interní nástroj pro vyrovnávání zatížení, musí být přenosová symetrie poskytována přes SNAT, jak je uvedeno v příkladu sever/jih výše.

Dalším problémem, kterým síťová virtuální zařízení se dvěma síťovými virtuálními sítěmi čelí v tomto návrhu, je místo, kde odesílat odpovědi na kontroly stavu nástroje pro vyrovnávání zatížení. Azure Load Balancer vždy používá stejnou IP adresu jako zdroj pro kontroly stavu (168.63.129.16). Síťové virtuální zařízení musí být schopné odeslat odpověď na kontrolu stavu, která je zdrojová z této IP adresy, na stejném rozhraní, které bylo přijato. Obvykle to vyžaduje více směrovacích tabulek v operačním systému, protože cílové směrování by odeslalo odpověď na kontroly stavu vždy přes stejnou síťovou kartu.

Azure Load Balancer má dobrou konvergenční dobu v jednotlivých výpadkech síťového virtuálního zařízení. Vzhledem k tomu, že sondy stavu je možné odesílat každých 5 sekund a trvá 3 neúspěšné sondy k deklaraci instance back-endu, obvykle trvá 10 až 15 sekund, než Azure Load Balancer konverguje provoz do jiné instance síťového virtuálního zařízení.

Toto nastavení podporuje konfiguraci aktivní,aktivní i aktivní/pohotovostní. V případě konfigurace aktivní/pohotovostní sítě musí instance síťového virtuálního zařízení nabízet port TCP/UDP nebo koncový bod HTTP, který reaguje pouze na sondy stavu Load Balanceru pro instanci, která je v aktivní roli.

Použití nástrojů pro vyrovnávání zatížení L7

Konkrétním případem tohoto návrhu pro bezpečnostní zařízení je nahrazení veřejného Load Balanceru Azure nástrojem pro vyrovnávání zatížení vrstvy 7, jako je azure Application Gateway (což se dá považovat za vlastní síťové virtuální zařízení). V tomto případě síťová virtuální zařízení vyžadují pouze interní Load Balancer pro provoz přicházející ze systémů úloh. Tento mechanismus někdy používají zařízení se dvěma síťovými rozhraními, aby se zabránilo potížím se směrováním kontrol stavu Azure Load Balanceru popsaných v předchozí části. Jedním z omezení tohoto návrhu je, že podporuje pouze protokoly vrstvy 7 podporované nástrojem pro vyrovnávání zatížení vrstvy 7, obvykle HTTP(S).

Síťové virtuální zařízení by mělo přijímat příchozí provoz pro protokoly, které váš nástroj pro vyrovnávání zatížení vrstvy 7 nepodporuje, a potenciálně veškerý příchozí provoz. Další podrobnosti o této konfiguraci při použití služby Azure Firewall jako síťového virtuálního zařízení a služby Azure Application Gateway jako webového reverzního proxy serveru vrstvy 7 najdete v tématu Firewall a Application Gateway pro virtuální sítě.

Azure Route Server

azure Route Server je služba, která umožňuje síťové virtuální zařízení komunikovat s Azure SDN přes protokol BGP (Border Gateway Protocol). Síťová virtuální zařízení nejen zjistí, které předpony IP adres existují ve virtuálních sítích Azure, ale můžou vkládat trasy do efektivních směrovacích tabulek virtuálních počítačů v Azure.

V diagramu nad každou instancí síťového virtuálního zařízení je partnerský vztah přes protokol BGP s Azure Route Serverem. V podsítích paprsků není nutná žádná směrovací tabulka, protože Azure Route Server programy trasy inzerované síťovými virtuálními zařízeními. Pokud jsou na virtuálních počítačích Azure naprogramované dvě nebo více tras, používají nástroj ECMP (Equal Cost MultiPathing) k výběru jedné z instancí síťového virtuálního zařízení pro každý tok provozu. V důsledku toho je SNAT v tomto návrhu nutností, pokud je požadavkem symetrie provozu.

Tato metoda vložení podporuje jak aktivní,tak aktivní (všechna síťová virtuální zařízení inzerují stejné trasy na Azure Route Server) a aktivní/pohotovostní (jedno síťové virtuální zařízení inzeruje trasy s kratší cestou AS než druhá). Azure Route Server podporuje maximálně 8 sousedství protokolu BGP. Pokud tedy používáte cluster s horizontálním navýšením kapacity aktivních síťových virtuálních zařízení, tento návrh podporuje maximálně 8 instancí síťového virtuálního zařízení.

Doba konvergence je v tomto nastavení rychlá a je ovlivněna keepalive a holdtime časovače sousedství protokolu BGP. I když má Azure Route Server výchozí keepalive a holdtime časovače (60 sekund a 180 sekund), síťová virtuální zařízení můžou během zřizování sousedství protokolu BGP vyjednat nižší časovače. Nastavení příliš nízkých časovačů může vést k instibility protokolu BGP.

Tento návrh je nejběžnější možností síťových virtuálních zařízení, které potřebují komunikovat se směrováním Azure, například síťová virtuální zařízení SDWAN nebo IPsec, která mají obvykle dobrou podporu protokolu BGP a potřebují se naučit předpony nakonfigurované ve virtuálních sítích Azure nebo inzerovat určité trasy přes privátní partnerské vztahy ExpressRoute. Tento typ zařízení je obvykle bezstavový, takže symetrie provozu není problém, a proto se SNAT nevyžaduje.

Gateway Load Balancer

nástroj pro vyrovnávání zatížení služby Azure Gateway představuje nový způsob vkládání síťových virtuálních zařízení do cesty k datům, aniž by bylo nutné směrovat provoz pomocí tras User-Defined. U virtuálních počítačů, které zpřístupňují své úlohy přes Azure Load Balancer nebo veřejnou IP adresu, je možné příchozí a odchozí provoz transparentně přesměrovat na cluster síťových virtuálních zařízení umístěných v jiné virtuální síti. Následující diagram popisuje cestu, kterou pakety sledují pro příchozí provoz z veřejného internetu v případě, že úlohy zpřístupňují aplikaci přes Azure Load Balancer:

Jednou zhlavníchch metodou síťového virtuálního zařízení je to, že pro zajištění symetrie provozu není vyžadován zdrojový překlad síťových adres (SNAT). Další výhodou této možnosti návrhu je to, že stejné síťové virtuální zařízení je možné použít ke kontrole provozu do/z různých virtuálních sítí, čímž dosáhnete víceklientské architektury z hlediska síťového virtuálního zařízení. Mezi virtuální sítí síťového virtuálního zařízení a virtuálními sítěmi úloh není vyžadován žádný partnerský vztah virtuálních sítí a v této virtuální síti nejsou vyžadovány žádné trasy User-Defined, což výrazně zjednodušuje konfiguraci.

Injektáž služby pomocí Nástroje pro vyrovnávání zatížení brány se dá použít pro příchozí toky, které dorazí na veřejný Load Balancer Azure (a jejich návratový provoz) a pro odchozí toky pocházející z Azure. East-West provoz mezi virtuálními počítači Azure nemůže využít Load Balancer brány pro injektáž síťového virtuálního zařízení.

V clusteru síťového virtuálního zařízení se sondy kontroly stavu Azure Load Balanceru používají ke zjištění selhání jednotlivých instancí síťového virtuálního zařízení a dosažení rychlé konvergenční doby (10–15 sekund).

Změna PIP-UDR

Myšlenka za tímto návrhem spočívá v nastavení, které by se vyžadovalo bez redundance síťového virtuálního zařízení, a upravilo se v případě výpadku síťového virtuálního zařízení. Následující diagram ukazuje, jak je veřejná IP adresa Azure přidružená k aktivnímu síťovému virtuálnímu zařízení (NVA1) a User-Defined trasy v paprskech mají jako další segment směrování aktivní IP adresu síťového virtuálního zařízení (10.0.0.37).

PIP/UDR

Pokud se aktivní síťové virtuální zařízení stane nedostupným, pohotovostní síťové virtuální zařízení zavolá rozhraní AZURE API, aby znovu namapoval veřejnou IP adresu a paprskové User-Defined trasy do sebe (nebo přesunula privátní IP adresu). Tato volání rozhraní API mohou trvat několik minut, což je důvod, proč tento návrh nabízí nejhorší konvergenci všech možností v tomto dokumentu.

Dalším omezením tohoto návrhu je, že se podporují pouze konfigurace aktivní/pohotovostní, což může vést k problémům se škálovatelností: pokud potřebujete zvýšit šířku pásma podporovanou síťovými virtuálními zařízeními, jedinou možností tohoto návrhu je vertikální navýšení kapacity obou instancí.

Jednou z výhod tohoto návrhu je, že k zajištění symetrie provozu není potřeba žádný zdrojový překlad síťových adres (SNAT), protože v daném okamžiku je aktivní jenom jedno síťové virtuální zařízení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Keith Mayer | Hlavní architekt cloudového řešení
• Telmo Sampaio | Principal Service Engineering Manager
• Jose Moreno | Hlavní inženýr

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Zjistěte, jak implementovat zabezpečenou hybridní síťovou pomocí služby Azure Firewall.
• hraniční sítě – architektura přechodu na cloud
• Cloud DMZ – architektura přechodu na cloud