Podrobné informace o směrování služby Virtual WAN

Azure Virtual WAN je síťové řešení, které umožňuje snadné vytváření sofistikovaných síťových topologií: zahrnuje směrování mezi oblastmi Azure mezi virtuálními sítěmi Azure a místními umístěními prostřednictvím sítě VPN typu Point-to-Site, VPN typu Site-to-Site, ExpressRoute a integrovaných zařízení SDWAN, včetně možnosti zabezpečení provozu. Ve většině scénářů není nutné mít hluboké znalosti o tom, jak funguje interní směrování Virtual WAN, ale v určitých situacích může být užitečné porozumět konceptům směrování virtual WAN.

Tento dokument zkoumá ukázkové scénáře služby Virtual WAN, které vysvětlují některá chování, se kterými se můžou organizace setkat při propojení virtuálních sítí a větví ve složitých sítích. Scénáře uvedené v tomto článku nejsou žádným způsobem doporučení k návrhu. Jedná se pouze o ukázkové topologie navržené tak, aby demonstrovaly určité funkce virtual WAN.

Scénář 1: Topologie s výchozí předvolbou směrování

První scénář v tomto článku analyzuje topologii se dvěma rozbočovači Virtual WAN, ExpressRoute, VPN a připojením SDWAN. V každém centru jsou virtuální sítě připojené přímo (virtuální sítě 11 a 21) a nepřímo prostřednictvím síťového virtuálního zařízení (virtuální sítě 121, 122, 221 a 222). VNet 12 vyměňuje informace o směrování s centrem 1 přes protokol BGP (viz partnerské vztahy protokolu BGP s virtuálním centrem) a virtuální síť 22 má nakonfigurované statické trasy, aby bylo možné zobrazit rozdíly mezi oběma možnostmi.

V každém rozbočovači slouží zařízení VPN a SDWAN dvojí účel: na jedné straně inzerují své vlastní individuální předpony (10.4.1.0/24 přes VPN v centru 1 a 10.5.3.0/24 přes SDWAN v centru 2) a na druhé inzerují stejné předpony jako okruhy ExpressRoute ve stejné oblasti (10.4.2.0/24 v centru 1 a 10.5.2.0/24 v centru 2). Tento rozdíl se použije k předvedení fungování předvoleb směrování centra Virtual WAN.

Všechna připojení virtuální sítě a větve se přidružují a šíří do výchozí směrovací tabulky. I když jsou centra zabezpečená (v každém centru je nasazená brána Azure Firewall), nejsou nakonfigurované pro zabezpečení privátního nebo internetového provozu. To by vedlo k rozšíření všech připojení do None směrovací tabulky, která by odebrala všechny nestatické trasy ze Default směrovací tabulky a poškodilo účel tohoto článku, protože efektivní okno trasy na portálu by bylo téměř prázdné (s výjimkou statických tras pro odesílání provozu do služby Azure Firewall).

Důležité

Předchozí diagram znázorňuje dvě zabezpečená virtuální centra, tato topologie se podporuje se záměrem směrování. Další informace najdete v tématu Konfigurace záměru směrování a zásad směrování centra Virtual WAN.

Za tímto účelem si centra Virtual WAN vyměňují informace mezi sebou, aby byla povolená komunikace mezi oblastmi. Můžete zkontrolovat efektivní trasy ve směrovacích tabulkách virtual WAN: Například následující obrázek ukazuje efektivní trasy v centru 1:

Tyto efektivní trasy se pak budou inzerovat službou Virtual WAN do větví a vloží je do virtuálních sítí připojených k virtuálním rozbočovačům, což zneužívá trasy definované uživatelem. Při kontrole efektivních tras ve virtuálním centru budou pole Typ dalšího segmentu směrování a Origin indikovat, odkud trasy pocházejí. Například typ dalšího segmentu směrování "Virtuální síť Připojení ion" označuje, že předpona je definována ve virtuální síti přímo připojené k Virtual WAN (virtuální sítě 11 a 12 na předchozím snímku obrazovky).

Síťové virtuální zařízení ve virtuální síti 12 vloží trasu 10.1.20.0/22 přes protokol BGP, protože typ dalšího segmentu směrování "HubBgp Připojení ion" znamená (viz partnerský vztah protokolu BGP s virtuálním centrem). Tato souhrnná trasa zahrnuje jak nepřímé paprsky VNet 121 (10.1.21.0/24), tak virtuální síť 122 (10.1.22.0/24). Virtuální sítě a větve ve vzdáleném centru jsou viditelné s dalším segmentem směrování a lze ho hub2vidět v cestě AS, že číslo 65520 autonomního systému bylo na tyto mezihubové trasy předzálohováno dvakrát.

V centru 2 je integrované síťové virtuální zařízení SDWAN. Další podrobnosti o podporovaných síťových virtuálních zařízeních pro tuto integraci najdete v tématu O síťových virtuálních virtuálních zařízeních v centru Virtual WAN. Všimněte si, že trasa do větve 10.5.3.0/24 SDWAN má další segment směrování VPN_S2S_Gateway. Tento typ dalšího segmentu směrování může dnes indikovat trasy přicházející z brány virtuální sítě Azure nebo ze síťových virtuálních zařízení integrovaných v centru.

V centru 2 je trasa pro 10.2.20.0/22 nepřímé paprsky VNet 221 (10.2.21.0/24) a virtuální síť 222 (10.2.22.0/24) nainstalovaná jako statická trasa, jak je uvedeno původem defaultRouteTable. Pokud zkontrolujete efektivní trasy pro centrum 1, tato trasa tam není. Důvodem je to, že statické trasy se nešířují přes protokol BGP, ale je potřeba je nakonfigurovat v každém centru. Proto se v centru 1 vyžaduje statická trasa, která zajišťuje připojení mezi virtuálními sítěmi a větvemi v centru 1 k nepřímým paprskům v centru 2 (virtuální sítě 221 a 222):

Po přidání statické trasy bude centrum 1 obsahovat také trasu 10.2.20.0/22 :

Scénář 2: Předvolba směrování globálního dosahu a centra

I když centrum 1 zná předponu ExpressRoute z okruhu 2 (10.5.2.0/24) a hub 2 zná předponu ExpressRoute z okruhu 1 (10.4.2.0/24), trasy ExpressRoute ze vzdálených oblastí se neinzerují zpět na místní propojení ExpressRoute. Proto se vyžaduje, aby mezi umístěními ExpressRoute mezi sebou komunikovat služba ExpressRoute Global Reach :

Důležité

Předchozí diagram znázorňuje dvě zabezpečená virtuální centra, tato topologie se podporuje se záměrem směrování. Další informace najdete v tématu Konfigurace záměru směrování a zásad směrování centra Virtual WAN.

Jak je vysvětleno v předvolbách směrování virtuálního centra, Služba Virtual WAN upřednostňuje trasy přicházející z ExpressRoute podle výchozího nastavení. Vzhledem k tomu, že trasy jsou inzerovány z rozbočovače 1 do okruhu ExpressRoute 1, od okruhu 1 do okruhu 2 a z okruhu ExpressRoute 2 do centra 2 (a naopak), virtuální rozbočovače dávají přednost této cestě před více přímým propojením mezi rozbočovači. Efektivní trasy v centru 1 ukazují toto:

Jak můžete vidět v trasách, ExpressRoute Global Reach předepíše číslo autonomního systému ExpressRoute (12076) několikrát předtím, než odešlete trasy zpět do Azure, aby tyto trasy byly méně vhodnější. Priorita směrování výchozího centra Virtual WAN pro ExpressRoute ale při rozhodování o směrování ignoruje délku cesty AS.

Efektivní trasy v centru 2 budou podobné:

Předvolbu směrování je možné změnit na VPN nebo AS-Path, jak je vysvětleno v předvolbách směrování virtuálního centra. Můžete například nastavit předvolbu sítě VPN, jak je znázorněno na tomto obrázku:

S předvolbou směrování rozbočovače sítě VPN vypadají efektivní trasy v centru 1 takto:

Předchozí obrázek ukazuje, že trasa má 10.4.2.0/24 nyní další segment směrování VPN_S2S_Gateway, zatímco výchozí předvolba směrování ExpressRoute byla ExpressRouteGateway. V centru 2 se však trasa stále 10.5.2.0/24 zobrazí s dalším segmentem směrování ExpressRoute, protože v tomto případě alternativní trasa nepochází ze služby VPN Gateway, ale ze síťového virtuálního zařízení integrovaného v centru:

Provoz mezi rozbočovači ale stále preferuje trasy přicházející přes ExpressRoute. Pokud chcete použít efektivnější přímé připojení mezi virtuálními rozbočovači, můžete v obou centrech nastavit předvolbu trasy na "AS Path":

Trasy pro vzdálené paprsky a větve v centru 1 teď budou mít další segment směrování Remote Hub podle očekávání:

Můžete vidět, že předpona IP adresy pro centrum 2 (192.168.2.0/23) se stále zobrazuje přes odkaz Global Reach, ale to by nemělo mít vliv na provoz, protože by neměl být žádný provoz adresovaný zařízením v centru 2. Tato trasa ale může být problém, pokud se v obou centrech navazují tunely SDWAN mezi sebou.

Mějte ale na paměti, že 10.4.2.0/24 se teď upřednostňuje před bránou VPN Gateway. K tomu může dojít v případě, že trasy inzerované prostřednictvím sítě VPN mají kratší cestu AS než trasy inzerované přes ExpressRoute. Jakmile nakonfigurujete místní zařízení VPN tak, aby se předpovědělo číslo autonomního systému (65501) na trasy VPN, aby bylo méně vhodnější, centrum 1 teď jako další segment směrování vybere ExpressRoute pro 10.4.2.0/24:

Centrum 2 zobrazí podobnou tabulku pro efektivní trasy, kde se virtuální sítě a větve v druhém centru teď zobrazují Remote Hub jako další segment směrování:

Scénář 3: Křížové propojení okruhů ExpressRoute s oběma rozbočovači

Aby bylo možné přidat přímé propojení mezi oblastmi Azure a místními umístěními připojenými přes ExpressRoute, je často žádoucí připojit jeden okruh ExpressRoute k několika rozbočovačům Virtual WAN v topologii někdy popsané jako "přímka", jak ukazuje následující topologie:

Důležité

Předchozí diagram znázorňuje dvě zabezpečená virtuální centra, tato topologie se podporuje se záměrem směrování. Další informace najdete v tématu Konfigurace záměru směrování a zásad směrování centra Virtual WAN.

Virtual WAN ukazuje, že oba okruhy jsou připojené k oběma rozbočovačům:

Po návratu k výchozí předvolbě směrování rozbočovače ExpressRoute se trasy do vzdálených větví a virtuálních sítí v centru 1 znovu zobrazí ExpressRoute jako další segment směrování. I když tentokrát není důvod Global Reach, ale skutečnost, že okruhy ExpressRoute odrazí zpět inzerované trasy, které z jednoho centra dostanou do druhého. Například efektivní trasy centra 1 s předvolbou směrování rozbočovače ExpressRoute jsou následující:

Opětovná změna předvolby směrování rozbočovače na AS Path vrátí trasy mezi rozbočovači na optimální cestu pomocí přímého připojení mezi rozbočovači 1 a 2:

Další kroky

Další informace o službě Virtual WAN najdete tady:

• Nejčastější dotazy ke službě Virtual WAN