Použití služby Azure Firewall ke směrování topologie s více huby a paprsky

Hvězdicová topologie je běžný model síťové architektury v Azure, který konsoliduje síťové prostředky a centralizuje síťové služby. Tato topologie poskytuje síťové připojení a zabezpečení virtuálním sítím nasazeným v různých předplatných nebo nájemnících.

Architektury hub-and-spoke můžete implementovat dvěma způsoby:

• Samostatně spravovaná hvězdicová architektura (tradiční): Udržujete plnou kontrolu nad virtuálními sítěmi rozbočovače a konfigurací směrování.
• Virtual WAN: Microsoft spravuje uzlové virtuální sítě a zjednodušuje správu prostřednictvím funkcí, jako jsou směrovací záměr a zásady směrování.

Tento článek se zaměřuje na samostatně spravované topologie hub-and-spoke, ve kterých máte plnou viditelnost a kontrolu nad virtuální sítí centra a nasazením Azure Firewall.

Pomocí Azure Virtual Network Manageru (AVNM) můžete snížit režijní náklady na správu samoobslužné implementace centra a paprsku. AVNM dokáže automatizovat konfiguraci směrovacích tabulek Azure, ale celkový návrh a techniky se v porovnání s ručním přístupem nemění. Obsah tohoto článku platí bez ohledu na to, zda používáte AVNM nebo ručně konfigurujete topologii hvězda-paprsek.

Alternativou ke směrovacím tabulkám Azure v paprskových virtuálních sítích je vkládání tras do podsítí se službou Azure Route Server, jak je uvedeno v části Výchozí injektáž trasy v paprskových virtuálních sítích. Tento model se ale běžně nepoužívá kvůli složitosti, která může vzniknout při interakci mezi bránami virtuální sítě Azure Route Server a VPN nebo ExpressRoute.

V nastavení centra a paprsku spravovaného vlastním systémem:

• Centrum: Virtuální síť, která slouží jako centrální bod připojení k vaší místní síti prostřednictvím sítě VPN, ExpressRoute nebo Software-Defined Wide Area Network (SD-WAN). Zařízení pro zabezpečení sítě, jako jsou brány firewall, se nasazují v centrální virtuální síti.
• Paprsky: Virtuální sítě, které jsou propojené s centrem a hostují vaše úlohy.

Pro úlohy rozložené do několika oblastí obvykle nasadíte jedno centrum pro každou oblast, abyste mohli agregovat provoz z větví v této oblasti. Následující diagram znázorňuje dvouregionovou samosprávovanou architekturu typu hvězdice se dvěma paprskovými virtuálními sítěmi v každé oblasti.

Hvězdicová architektura jednoregionální

Abyste porozuměli víceregionálnímu návrhu, musíte nejprve porozumět jednoregionálním konceptům. Následující diagram znázorňuje konfiguraci směrovací tabulky pro první oblast:

Zvažte požadavky na směrování pro každý potenciální tok provozu v návrhu jedné oblasti, abyste porozuměli konfiguraci trasy definované uživatelem:

• Mezi-satelitní provoz: Paprsky nejsou přímo propojeny a propojení virtuálních sítí není tranzitivní. Každý paprsk ví, jak ve výchozím nastavení směrovat do virtuální sítě centra, ale ne do jiných paprsků. Trasa aplikovaná 0.0.0.0/0 na všechny paprskové podsítě pokrývá provoz mezi paprskovými podsítěmi.
• Provoz pobočky na internet: Trasa 0.0.0.0/0 v tabulce směrování pobočky také pokrývá provoz odesílaný na veřejný internet. Tato trasa ve výchozím nastavení přepíše systémovou trasu, která je součástí veřejných podsítí. Další informace najdete v tématu Výchozí odchozí přístup v Azure.
• Provoz z internetu do spoke: Provoz z internetu do spoke obvykle nejprve prochází přes Azure Firewall. Služba Azure Firewall má nakonfigurovaná pravidla překladu cílových adres (DNAT), která také překládá zdrojovou IP adresu (Překlad zdrojových síťových adres nebo SNAT). Paprskové úlohy vnímají provoz, jako by pocházel z podsítě služby Azure Firewall. Partnerské propojení virtuálních sítí vytváří systémové trasy k rozbočovači (10.1.0.0/24), takže vedlejší sítě vědí, jak směrovat zpětný provoz.
• Provoz z místního systému do paprsku a z paprsku do místního systému: Zvažte každý směr samostatně:
  • Provoz z lokálního prostředí do hovoru: Provoz dorazí z lokální sítě do bran VPN nebo ExpressRoute. Při výchozím směrování v Azure se pro každou pobočku vytvoří systémová trasa v podsíti GatewaySubnet a dalších podsítích v centrální virtuální síti. Tyto systémové trasy musíte přepsat a nastavit další skok na privátní IP adresu Azure Firewall. V tomto příkladu potřebujete dvě trasy v směrovací tabulce přidružené k podsíti brány, jednu pro každou odbočku (10.1.1.0/24 a 10.1.2.0/24). Použití souhrnu, jako je 10.1.0.0/16, který zahrnuje všechny propojované virtuální sítě, nefunguje, protože systémové trasy vložené propojeními virtuálních sítí v podsíti brány jsou konkrétnější (/24 v porovnání se souhrnem /16). Tato směrovací tabulka musí mít povolený přepínač Rozšířit trasy brány (nastavený na Ano), jinak může být směrování brány nepředvídatelné.
  • Provoz mezi paprskem a lokálním prostředím: Partnerské vztahy virtuálních sítí mezi centrem a paprsky musí mít povolenou možnost Povolit tranzit brány na straně centra a Používat vzdálené brány povolené na straně paprsku. Tato nastavení jsou povinná, aby brány VPN a ExpressRoute inzerovaly předpony 'spokes' přes protokol BGP (Border Gateway Protocol) do místních sítí. Tato nastavení také způsobují, že paprsky se ve výchozím nastavení učí předpony inzerované z místního prostředí do Azure. Vzhledem k tomu, že místní předpony jsou konkrétnější než trasa 0.0.0.0/0 definovaná uživatelem v tabulce směrování paprsků, provoz z paprsků do místního prostředí by ve výchozím nastavení vynechal bránu firewall. Pokud chcete této situaci zabránit, nastavte přepínač Rozšířit trasy brány do tabulky směrování paprsku na Ne , aby se místní předpony nenaučily a 0.0.0.0/0 trasa se používá pro provoz do místního prostředí.

Poznámka:

Místo souhrnu sítě použijte přesné předpony IP adres virtuální sítě v směrovací tabulce přidružené k podsíti brány. Systémové trasy zavedené peerováním virtuálních sítí s okraji přepíší uživatelsky definovanou trasu, protože jsou specifičtější.

Ke snížení nároků na správu můžete spravovat směrovací tabulku přidruženou k podsítím paprsku a směrovací tabulku přidruženou k podsíti brány pomocí manažeru virtuální sítě Azure. Další informace viz Použití Azure Firewall jako dalšího skoku.

Úlohy virtuální sítě rozbočovače

Pokud nasadíte úlohy v centrální virtuální síti (například řadiče domény služby Active Directory, servery DNS nebo jinou sdílenou infrastrukturu), zvýší se tím složitost návrhu topologie hub-and-spoke. Doporučujeme, abyste se vyhnuli umístění úloh do centra a místo toho je nasadili do vyhrazené větve pro sdílené služby.

Tato část popisuje konfiguraci potřebnou pro úlohy centra, abyste mohli vyhodnotit, jestli je tato složitost pro vaše požadavky přijatelná. Také popisujeme běžnou chybu, která může způsobit asymetrický provoz, což vede k padání paketů.

Následující diagram znázorňuje návrh jedné oblasti s podsítí úloh ve virtuální síti centra:

Kritickým detailem je, že uživatelsky definované trasy nakonfigurované v podsíti brány i ve větvových podsítích jsou určeny pro konkrétní podsíť úloh a ne pro předponu adresního rozsahu celé virtuální sítě centrálního uzlu:

• Konfigurace podsítě brány: Konfigurace trasy v podsíti brány pro celou virtuální síť centra (10.1.0.0/24 v tomto příkladu) přepíše systémovou trasu pro virtuální síť centra. To způsobí, že se provoz v rámci podsítě mezi branami VPN nebo ExpressRoute odesílá do brány firewall, což může narušit činnost brány.
• Konfigurace podsítě paprsku: Konfigurace trasy v podsítích paprsků pro celou virtuální síť centra (10.1.0.0/24 v tomto příkladu) přepíše systémovou trasu vytvořenou partnerským vztahem s virtuální sítí centra. Veškerý provoz odeslaný do uzlu by byl směrován do služby Azure Firewall, včetně provozu ze samotné služby Azure Firewall, jako je provoz z internetu do propojení sítě, který prochází překladem zdrojových síťových adres (SNAT). Tato konfigurace zavádí asymetrický provoz a způsobuje výpadky paketů.

Poznámka:

Pokud nasadíte úlohy ve virtuální síti centra, nepoužívejte v trasách definovaných uživatelem předponu IP celé virtuální sítě.

Kontrola provozu mezi podsítěmi

V aktuálním nastavení se provoz mezi uzly odesílá do brány firewall, ale provoz uvnitř uzlu zůstává ve virtuální síti uzlu a řídí se pomocí skupin zabezpečení sítě. Tento návrh považuje virtuální sítě za hranici zabezpečení: brána firewall kontroluje pouze provoz, který opouští nebo vstupuje do virtuální sítě.

Pokud chcete zkontrolovat síťový provoz mezi podsítěmi ve stejné spoke virtuální síti, upravte směrovací tabulku přidruženou k těmto podsítím, jak ukazuje následující schéma:

V předchozím diagramu se v každé paprskové virtuální síti zavádějí dvě paprskové podsítě a popisují se směrovací tabulky paprsků ve virtuální síti A2. Odesílání provozu mezi jednotlivými podsítěmi do firewallu vyžaduje, aby každá podsíť měla samostatnou směrovací tabulku, protože trasy k instalaci v každé podsíti se liší.

Pro podsíť A21 potřebujete tyto dvě další trasy:

• Směr: 10.1.2.0/24Přepíše systémovou trasu pro provoz v rámci virtuální sítě. Bez jiných tras se veškerý provoz v rámci virtuální sítě odesílá do služby Azure Firewall, a to i provoz mezi virtuálními počítači ve stejné podsíti.
• Směrování do 10.1.2.0/26 s dalším skokem virtuální síť: Výjimka z předchozí trasy, takže provoz v rámci této konkrétní podsítě se neodesílá do brány firewall, ale je směrován místně v rámci virtuální sítě. Tato trasa je specifická pro každou podsíť, což je důvod, proč potřebujete pro každou podsíť samostatnou směrovací tabulku.

virtuální zařízení sítě SD-WAN

Pokud používáte SD-WAN síťová virtuální zařízení (NVA) místo bran VPN nebo ExpressRoute, je návrh podobný, jak je znázorněno v následujícím diagramu:

Existují různé způsoby integrace síťových virtuálních zařízení SD-WAN v Azure. Další informace najdete v tématu integrace SD-WAN s topologiemi sítě typu hub-and-spoke v Azure. Tento článek ukazuje integraci s využitím Azure Route Serveru, což je jedna z nejběžnějších metod směrování provozu do SD-WAN sítí. Síťové virtuální zařízení SD-WAN oznamují místní předpony na Azure Route Server prostřednictvím protokolu BGP. Azure Route Server vloží tyto předpony do podsítě služby Azure Firewall, aby služba Azure Firewall obsahuje informace o směrování pro místní sítě. Paprsky se nenaučí lokální předpony, protože možnost šíření tras brány je v tabulce směrování paprsků zakázána.

Pokud nechcete konfigurovat předponu každé virtuální sítě spoke ve směrovací tabulce přidružené k podsíti NVA, můžete umístit SD-WAN NVA do jejich vyhrazené virtuální sítě. Virtuální síť NVA se nenaučí prefixy ramen, protože nejsou přímo propojeny, a je možná souhrnná trasa, jak je znázorněno v následujícím diagramu.

Hvězdicová architektura s více oblastmi

Jakmile pochopíte, jak provoz funguje v rámci jednoho hub-and-spoke regionu, rozšíření návrhu na víceúrovňovou architekturu je jednoduché. Následující diagram znázorňuje aktualizovaný návrh sítě s rozbočovači ve dvou oblastech (A a B):

Jediným doplňkem konfigurace jsou směrovací tabulky přidružené k podsítím služby Azure Firewall v každé oblasti. Každá virtuální síť rozbočovače zná pouze předpony virtuálních sítí s přímým párováním, takže pro předpony vzdálených uzlů neexistuje žádné směrování. Přidejte trasy definované uživatelem pro každou podsíť služby Azure Firewall, aby se provoz pro každou oblast směroval do odpovídající brány Azure Firewall.

V tomto příkladu je možné snadno shrnout jednotlivé oblasti:

• Oblast A obsahuje předpony v 10.1.0.0/16
• Oblast B obsahuje předpony v 10.2.0.0/16

Definování IP adres v jednotlivých oblastech, které jsou snadno shrnuté, usnadňuje konfiguraci směrování. Jinak musíte vytvořit jednu trasu pro každé vzdálené rameno.

Povolte rozšíření tras brány v tabulce směrování podsítě služby Azure Firewall, aby se brána firewall mohla učit místní trasy z bran VPN a ExpressRoute.

Poznámka:

Pokud je Azure Firewall nasazen bez síťové karty pro správu, podsíť Azure Firewall vyžaduje výchozí trasu s dalším přeskokem "Internet" pro přidání konkrétnějších tras, jak bylo popsáno dříve.

Ke zjednodušení správy tras definovaných uživatelem v prostředí s více oblastmi můžete použít Azure Virtual Network Manager. Další informace najdete v tématu Správa tras definovaných uživatelem napříč několika topologiemi hvězdicového typu pomocí AVNM.

Další kroky

• Zjistěte, jak nasadit a nakonfigurovat bránu Azure Firewall.