Výchozí injektáž trasy v paprskových virtuálních sítích

Jednou z nejběžnějších architektur v Azure je návrh hvězdicové architektury, kde úlohy nasazené v paprskové virtuální síti odesílají provoz prostřednictvím sdílených síťových zařízení, která existují ve virtuální síti centra. Trasy definované uživatelem (UDR) obvykle musí být v paprskových virtuálních sítích nakonfigurované tak, aby směrovaly provoz směrem k bezpečnostním zařízením v centru. Tento návrh ale vyžaduje, aby správci mohli tyto trasy spravovat napříč mnoha paprsky.

Azure Route Server nabízí centralizovaný bod, kde síťová virtuální zařízení můžou inzerovat trasy, které vloží do paprskových virtuálních sítí. Správci tak nemusí vytvářet a aktualizovat směrovací tabulky ve virtuálních sítích paprsků.

Topologie

Následující diagram znázorňuje jednoduchý návrh hvězdicové hvězdicové architektury s virtuální sítí centra a dvěma paprskovými virtuálními sítěmi. V centru se nasadilo síťové virtuální zařízení a směrovací server. Bez směrového serveru by se trasy definované uživatelem musely konfigurovat v každém paprsku. Tyto trasy definované uživatelem obvykle obsahují výchozí trasu pro 0.0.0.0/0, která odesílá veškerý provoz z paprskových virtuálních sítí přes síťové virtuální zařízení. Tento scénář je možné použít například ke kontrole provozu pro účely zabezpečení.

Se směrovacím serverem ve virtuální síti centra není nutné používat trasy definované uživatelem. Síťové virtuální zařízení inzeruje předpony sítě na směrovací server, který je vloží, aby se zobrazily v efektivních trasách libovolného virtuálního počítače nasazeného ve virtuální síti centra nebo paprskových virtuálních sítích, které jsou v partnerském vztahu s virtuální sítí rozbočovače s nastavením Použít bránu vzdálené virtuální sítě nebo směrovací server.

Připojení ivity k místnímu prostředí prostřednictvím síťového virtuálního zařízení

Pokud se síťové virtuální zařízení používá k poskytování připojení k místní síti prostřednictvím sítí IPsec VPN nebo technologií SD-WAN, lze stejný mechanismus použít k přilákání provozu z paprsků do síťového virtuálního zařízení. Síťové virtuální zařízení se navíc může dynamicky učit předpony Azure ze směrovacího serveru Azure a inzerovat je pomocí protokolu dynamického směrování do místního prostředí. Následující diagram popisuje toto nastavení:

Kontrola privátního provozu přes síťové virtuální zařízení

Předchozí části znázorňují provoz kontrolovaný síťovým virtuálním zařízením vložením 0.0.0.0/0 výchozí trasy ze síťového virtuálního zařízení na směrovací server. Pokud ale chcete prostřednictvím síťového virtuálního zařízení pouze zkontrolovat provoz paprsku na paprsky a paprsky do místního provozu, měli byste zvážit, že Azure Route Server neinzeruje trasu, která je stejná nebo delší předpona než adresní prostor virtuální sítě naučený z síťového virtuálního zařízení. Jinými slovy, Azure Route Server tyto předpony nevkážou do virtuální sítě a nenaprogramují se na síťové karty virtuálních počítačů v hvězdicových virtuálních sítích.

Azure Route Server ale bude inzerovat větší podsíť než adresní prostor virtuální sítě, který se naučí ze síťového virtuálního zařízení. Z síťového virtuálního zařízení je možné inzerovat supernet toho, co máte ve virtuální síti. Pokud například vaše virtuální síť používá adresní prostor 10.0.0.0/16RFC 1918, může síťové virtuální zařízení inzerovat 10.0.0.0/8 na Azure Route Server a tyto předpony se vloží do hvězdicových virtuálních sítí. Toto chování virtuální sítě se odkazuje v tématu O protokolu BGP se službou VPN Gateway.

Důležité

Pokud máte scénář, ve kterém se inzerují předpony se stejnou délkou z ExpressRoute a síťového virtuálního zařízení, Azure preferuje a programuje trasy získané z ExpressRoute. Další informace naleznete v následující části.

Připojení ivity k místnímu prostředí prostřednictvím bran virtuální sítě

Pokud síť VPN nebo brána ExpressRoute existuje ve stejné virtuální síti jako směrovací server a síťové virtuální zařízení, které poskytují připojení k místním sítím, trasy získané těmito bránami se naprogramují i v paprskových virtuálních sítích. Tyto trasy přepíší výchozí trasu (0.0.0.0/0) vloženou serverem směrování, protože by byly konkrétnější (delší síťové masky). Následující diagram popisuje předchozí návrh, kde byla přidána brána ExpressRoute.

Podsítě v paprskových virtuálních sítích nemůžete nakonfigurovat tak, aby se učily pouze trasy ze serveru Azure Route. Zakázáním příkazu "Rozšířit trasy brány" ve směrovací tabulce přidružené k podsíti by se zabránilo oběma typům tras (trasám z brány virtuální sítě a trasám ze serveru Azure Route Server), které se mají v této podsíti vložit do síťových adaptérů.

Ve výchozím nastavení směrovací server inzeruje všechny předpony získané ze síťového virtuálního zařízení do ExpressRoute. To nemusí být žádoucí, například kvůli omezením tras ExpressRoute nebo samotného směrového serveru. V takovém případě může síťové virtuální zařízení oznámit své trasy na směrovací server včetně komunity no-advertise protokolu BGP (s hodnotou 65535:65282). Když route Server přijme trasy s touto komunitou protokolu BGP, vloží je do podsítí, ale neinzeruje je jiným partnerským uzlům protokolu BGP (jako jsou brány ExpressRoute nebo brány VPN nebo jiné síťové virtuální zařízení).

Koexistence SDWAN s ExpressRoute a službou Azure Firewall

Konkrétním případem předchozího návrhu je, když zákazníci vloží bránu Azure Firewall do toku provozu a kontrolují veškerý provoz procházející do místních sítí, a to buď přes ExpressRoute, nebo přes zařízení SD-WAN nebo VPN. V této situaci mají všechny podsítě paprsků směrovací tabulky, které brání paprskům v učení jakékoli trasy z ExpressRoute nebo směrového serveru a mají výchozí trasy (0.0.0.0/0) s bránou Azure Firewall jako další segment směrování, jak ukazuje následující diagram:

Podsíť služby Azure Firewall se učí trasy přicházející z ExpressRoute i síťového virtuálního zařízení VPN/SDWAN a rozhoduje, jestli odesílá provoz jedním nebo druhým směrem. Jak je popsáno v předchozí části, pokud zařízení síťového virtuálního zařízení inzeruje více než 200 tras na směrovací server, měl by odesílat své trasy BGP označené komunitou no-advertiseprotokolu BGP . Tímto způsobem se předpony SDWAN nevkážou zpět do místního prostředí přes Express-Route.

Symetrie provozu

Pokud se v aktivním/aktivním scénáři používá více instancí síťového virtuálního zařízení pro lepší odolnost nebo škálovatelnost, je symetrie provozu požadavkem, pokud síťová virtuální zařízení potřebují zachovat stav připojení. Jedná se například o případ bran firewall nové generace.

• Pro připojení z virtuálních počítačů Azure k veřejnému internetu síťové virtuální zařízení používá překlad zdrojových síťových adres (SNAT), aby odchozí provoz byl zdroj z veřejné IP adresy síťového virtuálního zařízení, čímž dosáhne symetrie provozu.
• U příchozího provozu z internetu do úloh spuštěných ve virtuálních počítačích se kromě překladu cílových síťových adres (DNAT) síťová virtuální zařízení budou muset provést překlad zdrojových síťových adres (SNAT), aby se zajistilo, že se zpětný provoz z virtuálních počítačů přesune do stejné instance síťového virtuálního zařízení, která zpracovala první paket.
• Pro připojení Azure k Azure, protože zdrojový virtuální počítač převezme rozhodnutí o směrování nezávisle na cíli, je pro dosažení symetrie provozu vyžadován SNAT.

V nastavení aktivní/pasivní se dá nasadit i několik instancí síťového virtuálního zařízení, například pokud některý z nich inzeruje horší trasy (s delší cestou AS) než druhá. V tomto případě azure Route Server vloží upřednostňovanou trasu pouze do virtuálních počítačů virtuální sítě a méně upřednostňovaná trasa se použije jenom v případě, že primární instance síťového virtuálního zařízení přestane inzerovat přes protokol BGP.

Různé směrovací servery, které inzerují trasy branám virtuální sítě a virtuálním sítím

Jak vidíte v předchozích částech, Azure Route Server má dvojitou roli:

• Zjišťuje a inzeruje trasy do/z bran virtuální sítě (VPN a ExpressRoute).
• Konfiguruje naučené trasy ve své virtuální síti a přímo v partnerských virtuálních sítích.

Tato duální funkce je často zajímavá, ale někdy to může být škodlivé pro určité požadavky. Pokud je například směrovací server nasazený ve virtuální síti s síťovým virtuálním zařízením, který inzeruje trasu 0.0.0.0/0 a bránu ExpressRoute inzeruje předpony z místního prostředí, nakonfiguruje všechny trasy (jak 0.0.0.0.0/0 ze síťového virtuálního zařízení, tak z místních předpon) na virtuálních počítačích ve virtuální síti a přímo v partnerských virtuálních sítích. Vzhledem k tomu, že místní předpony budou konkrétnější než 0.0.0.0/0, provoz mezi místním prostředím a Azure obchází síťové virtuální zařízení. Pokud to není žádoucí, předchozí části tohoto článku ukazují, jak zakázat šíření protokolu BGP v podsítích virtuálních počítačů a nakonfigurovat trasy definované uživatelem.

Existuje ale alternativní, dynamičtější přístup. Je možné použít různé směrovací servery Azure pro různé funkce: jeden z nich bude zodpovědný za interakci s branami virtuální sítě a druhý pro interakci se směrováním virtuální sítě. Následující diagram znázorňuje možný návrh pro toto:

Route Server 1 v centru slouží k vložení předpon z SDWAN do ExpressRoute. Vzhledem k tomu, že paprskové virtuální sítě jsou v partnerském vztahu s virtuální sítí centra bez brány vzdálené virtuální sítě nebo směrového serveru (v partnerském vztahu paprskových virtuálních sítí) a používají bránu této virtuální sítě nebo směrovací server (průchod bránou v partnerském vztahu virtuálních sítí centra), paprskové virtuální sítě se tyto trasy nenaučí (ani předpony SDWAN ani předpony ExpressRoute).

K šíření tras do paprskových virtuálních sítí používá síťové virtuální zařízení směrovací server 2 nasazený v nové pomocné virtuální síti. Síťové virtuální zařízení rozšíří pouze jednu 0.0.0.0/0 trasu na směrovací server 2. Vzhledem k tomu, že paprskové virtuální sítě jsou v partnerském vztahu s touto pomocnou virtuální sítí s použitím brány vzdálené virtuální sítě nebo směrového serveru (v partnerském vztahu paprskových virtuálních sítí) a použijte bránu této virtuální sítě nebo směrovací server (průchod bránou v partnerském vztahu virtuálních sítí centra), 0.0.0.0/0 trasa se naučí všemi virtuálními počítači v paprskech.

Dalším segmentem směrování pro trasu 0.0.0.0/0 je síťové virtuální zařízení, takže paprskové virtuální sítě stále musí být v partnerském vztahu s virtuální sítí centra. Dalším důležitým aspektem, který je potřeba si všimnout, je, že virtuální síť centra musí být v partnerském vztahu s virtuální sítí, ve které je nasazený Route Server 2, jinak nebude moct vytvořit sousedství protokolu BGP.

Pokud se provoz z ExpressRoute do paprskových virtuálních sítí odešle do síťového virtuálního zařízení brány firewall za účelem kontroly, vyžaduje se směrovací tabulka v podsíti brány GatewaySubnet, jinak brána virtuální sítě ExpressRoute odešle virtuálním počítačům pakety pomocí tras získaných z partnerského vztahu virtuálních sítí. Trasy v této směrovací tabulce by se měly shodovat s předponami paprsku a dalším segmentem směrování by měla být IP adresa síťového virtuálního zařízení brány firewall (nebo nástroj pro vyrovnávání zatížení před síťovými virtuálními sítěmi brány firewall) pro redundanci. Síťové virtuální zařízení brány firewall může být stejné jako síťové virtuální zařízení SDWAN v diagramu výše, nebo se může jednat o jiné zařízení, jako je Azure Firewall, protože síťové virtuální zařízení SDWAN může inzerovat trasy s dalším směrováním směřujícím na jiné IP adresy. Následující diagram znázorňuje tento návrh s přidáním služby Azure Firewall:

Poznámka:

U jakéhokoli provozu z místního prostředí určeného pro privátní koncové body tento provoz vynechá síťové virtuální zařízení brány firewall nebo bránu Azure Firewall v centru. Výsledkem je ale asymetrické směrování (což může vést ke ztrátě připojení mezi místními a privátními koncovými body) jako privátní koncové body předávací místní provoz do brány firewall. Pokud chcete zajistit symetrii směrování, povolte zásady sítě směrovací tabulky pro privátní koncové body v podsítích, kde jsou nasazené privátní koncové body.

Tento návrh umožňuje automatické vkládání tras do paprskových virtuálních sítí bez zásahu z jiných tras získaných z ExpressRoute, VPN nebo prostředí SDWAN a přidání síťových virtuálních zařízení brány firewall pro kontrolu provozu.

Související obsah

• Přečtěte si další informace o podpoře Azure Route Serveru pro ExpressRoute a Azure VPN.
• Zjistěte, jak nakonfigurovat partnerský vztah mezi Azure Route Serverem a síťovým virtuálním zařízením.