Uitgebreide informatie over Virtual WAN-routering
Azure Virtual WAN is een netwerkoplossing waarmee u eenvoudig geavanceerde netwerktopologieën kunt maken: het omvat routering tussen Azure-regio's tussen Azure-VNets en on-premises locaties via punt-naar-site-VPN, site-naar-site-VPN, ExpressRoute en geïntegreerde SDWAN-apparaten, waaronder de optie om het verkeer te beveiligen. In de meeste scenario's is het niet vereist dat u uitgebreide kennis hebt van de werking van interne Routering van Virtual WAN, maar in bepaalde situaties kan het handig zijn om inzicht te krijgen in de concepten van Virtual WAN-routering.
In dit document worden voorbeeldscenario's van Virtual WAN verkend die enkele van de gedragingen uitleggen die organisaties kunnen tegenkomen bij het verbinden van hun VNets en vertakkingen in complexe netwerken. De scenario's die in dit artikel worden weergegeven, zijn geen enkele ontwerpaanbevelingen, ze zijn alleen voorbeeldtopologieën die zijn ontworpen om bepaalde Virtual WAN-functies te demonstreren.
Scenario 1: topologie met standaardrouteringsvoorkeur
In het eerste scenario in dit artikel wordt een topologie geanalyseerd met twee Virtual WAN-hubs, ExpressRoute, VPN en SDWAN-connectiviteit. In elke hub zijn er VNets rechtstreeks verbonden (VNets 11 en 21) en indirect via een NVA (VNets 121, 122, 221 en 222). VNet 12 wisselt routeringsinformatie uit met hub 1 via BGP (zie BGP-peering met een virtuele hub) en VNet 22 heeft statische routes geconfigureerd, zodat verschillen tussen beide opties kunnen worden weergegeven.
In elke hub dienen de VPN- en SDWAN-apparaten een dubbel doel: aan de ene kant adverteren ze hun eigen afzonderlijke voorvoegsels (via VPN in hub 1 en 10.5.3.0/24 via SDWAN in hub 2), en aan de andere kant adverteren ze dezelfde voorvoegsels als de ExpressRoute-circuits in dezelfde regio (10.4.2.0/2410.4.1.0/24in hub 1 en 10.5.2.0/24 in hub 2). Dit verschil wordt gebruikt om te laten zien hoe de routeringsvoorkeur van de Virtual WAN-hub werkt.
Alle VNet- en vertakkingsverbindingen worden gekoppeld en doorgegeven aan de standaardroutetabel. Hoewel de hubs zijn beveiligd (er is een Azure Firewall geïmplementeerd in elke hub), zijn ze niet geconfigureerd om privé- of internetverkeer te beveiligen. Dit zou ertoe leiden dat alle verbindingen worden doorgegeven aan de None routetabel, waardoor alle niet-statische routes uit de Default routetabel worden verwijderd en het doel van dit artikel worden verslagen omdat de effectieve routeblade in de portal bijna leeg zou zijn (met uitzondering van de statische routes om verkeer naar de Azure Firewall te verzenden).
Belangrijk
In het vorige diagram ziet u twee beveiligde virtuele hubs. Deze topologie wordt ondersteund met routeringsintentie. Zie Routeringsintentie en routeringsbeleid voor Virtual WAN Hub configureren voor meer informatie.
Standaard wisselen de Virtual WAN-hubs informatie uit tussen elkaar, zodat communicatie tussen regio's is ingeschakeld. U kunt de effectieve routes in Virtual WAN-routetabellen inspecteren: in de volgende afbeelding ziet u bijvoorbeeld de effectieve routes in hub 1:
Deze effectieve routes worden vervolgens geadverteerd door Virtual WAN naar vertakkingen en injecteren ze in de VNets die zijn verbonden met de virtuele hubs, waardoor het gebruik van door de gebruiker gedefinieerde routes niet nodig is. Wanneer u de effectieve routes in een virtuele hub inspecteert, geven de velden 'Next Hop Type' en 'Origin' aan waar de routes vandaan komen. Een volgend hoptype van 'Virtual Network Verbinding maken ion' geeft bijvoorbeeld aan dat het voorvoegsel is gedefinieerd in een VNet dat rechtstreeks is verbonden met Virtual WAN (VNets 11 en 12 in de vorige schermafbeelding)
De NVA in VNet 12 injecteert de route 10.1.20.0/22 via BGP, zoals het volgende hoptype 'HubBgp Verbinding maken ion' impliceert (zie BGP-peering met een virtuele hub). Deze samenvattingsroute omvat zowel indirecte spokes VNet 121 (10.1.21.0/24) als VNet 122 (10.1.22.0/24). VNets en vertakkingen in de externe hub zijn zichtbaar met een volgende hop van hub2, en het is te zien in het AS-pad dat het autonome systeemnummer 65520 twee keer is voorbereid op deze interhub-routes.
In hub 2 is er een geïntegreerd SDWAN Network Virtual Appliance. Ga naar Over NVA's in een Virtual WAN-hub voor meer informatie over ondersteunde NVA's voor deze integratie. Houd er rekening mee dat de route naar de SDWAN-vertakking 10.5.3.0/24 een volgende hop van VPN_S2S_Gateway. Dit type volgende hop kan vandaag wijzen op routes die afkomstig zijn van een Virtuele Azure-netwerkgateway of van NVA's die zijn geïntegreerd in de hub.
In hub 2 wordt de route voor 10.2.20.0/22 de indirecte spokes VNet 221 (10.2.21.0/24) en VNet 222 (10.2.22.0/24) geïnstalleerd als een statische route, zoals aangegeven door de oorsprong defaultRouteTable. Als u de effectieve routes voor hub 1 controleert, is die route er niet. De reden hiervoor is dat statische routes niet worden doorgegeven via BGP, maar in elke hub moeten worden geconfigureerd. Daarom is een statische route vereist in hub 1 om connectiviteit te bieden tussen de VNets en vertakkingen in hub 1 met de indirecte spokes in hub 2 (VNets 221 en 222):
Na het toevoegen van de statische route bevat hub 1 ook de 10.2.20.0/22 route:
Scenario 2: Routeringsvoorkeur voor Global Reach en hub
Zelfs als hub 1 het ExpressRoute-voorvoegsel van circuit 2 (10.5.2.0/24) kent en hub 2 het ExpressRoute-voorvoegsel van circuit 1 (10.4.2.0/24) kent, worden ExpressRoute-routes van externe regio's niet teruggeadverteerd naar on-premises ExpressRoute-koppelingen. ExpressRoute Global Reach is daarom vereist om de ExpressRoute-locaties met elkaar te laten communiceren:
Belangrijk
In het vorige diagram ziet u twee beveiligde virtuele hubs. Deze topologie wordt ondersteund met routeringsintentie. Zie Routeringsintentie en routeringsbeleid voor Virtual WAN Hub configureren voor meer informatie.
Zoals uitgelegd in de routeringsvoorkeur van virtuele hubs, biedt Virtual WAN de voorkeur aan routes die afkomstig zijn van ExpressRoute per standaardinstelling. Omdat routes worden geadverteerd van hub 1 naar het ExpressRoute-circuit 1, van het ExpressRoute-circuit 1 naar het circuit 2, en van het ExpressRoute-circuit 2 naar hub 2 (en omgekeerd), geven virtuele hubs nu de voorkeur aan dit pad via de meer directe koppeling tussen hubs. De effectieve routes in hub 1 laten dit zien:
Zoals u in de routes kunt zien, prependeert ExpressRoute Global Reach meerdere keren het ExpressRoute Autonomous System Number (12076) voordat routes naar Azure worden verzonden om deze routes minder geschikt te maken. De standaard-hubrouteringsprioriteit van Virtual WAN van ExpressRoute negeert echter de LENGTE van het AS-pad bij het nemen van een beslissing over routering.
De effectieve routes in hub 2 zijn vergelijkbaar:
De routeringsvoorkeur kan worden gewijzigd in VPN of AS-pad, zoals wordt uitgelegd in de routeringsvoorkeur van de virtuele hub. U kunt bijvoorbeeld de voorkeur instellen op VPN, zoals wordt weergegeven in deze afbeelding:
Met een hubrouteringsvoorkeur van VPN zien de effectieve routes in hub 1 er als volgt uit:
In de vorige afbeelding ziet u dat de route naar 10.4.2.0/24 nu een volgende hop heeft, VPN_S2S_Gatewayterwijl de standaardrouteringsvoorkeur van ExpressRoute het was ExpressRouteGateway. In hub 2 wordt de route naar 10.5.2.0/24 echter nog steeds weergegeven met een volgende hop van ExpressRoute, omdat in dit geval de alternatieve route niet afkomstig is van een VPN-gateway, maar van een NVA die is geïntegreerd in de hub:
Verkeer tussen hubs geeft echter nog steeds de voorkeur aan de routes die via ExpressRoute binnenkomen. Als u de efficiëntere directe verbinding tussen de virtuele hubs wilt gebruiken, kan de routevoorkeur worden ingesteld op 'AS-pad' op beide hubs:
Nu hebben de routes voor externe spokes en vertakkingen in hub 1 een volgende hop zoals Remote Hub bedoeld:
U kunt zien dat het IP-voorvoegsel voor hub 2 (192.168.2.0/23) nog steeds bereikbaar is via de Global Reach-koppeling, maar dit mag geen invloed hebben op verkeer, omdat er geen verkeer moet zijn dat is geadresseerd aan apparaten in hub 2. Deze route kan echter een probleem zijn, als er NVA's waren in beide hubs die SDWAN-tunnels tussen elkaar tot stand brengen.
Houd er echter rekening mee dat 10.4.2.0/24 dit nu de voorkeur heeft boven de VPN Gateway. Dit kan gebeuren als de routes die via VPN worden geadverteerd een korter AS-pad hebben dan de routes die via ExpressRoute worden geadverteerd. Na het configureren van het on-premises VPN-apparaat om het autonome systeemnummer (65501) toe te staan aan de VPN-routes om de minder voorkeur te geven, selecteert hub 1 nu ExpressRoute als volgende hop voor 10.4.2.0/24:
Hub 2 toont een vergelijkbare tabel voor de effectieve routes, waarbij de VNets en vertakkingen in de andere hub nu worden weergegeven als Remote Hub volgende hop:
Scenario 3: De ExpressRoute-circuits kruislings verbinden met beide hubs
Om directe koppelingen toe te voegen tussen de Azure-regio's en de on-premises locaties die zijn verbonden via ExpressRoute, is het vaak wenselijk om één ExpressRoute-circuit te verbinden met meerdere Virtual WAN-hubs in een topologie die soms wordt beschreven als 'bow tie', zoals in de volgende topologie wordt weergegeven:
Belangrijk
In het vorige diagram ziet u twee beveiligde virtuele hubs. Deze topologie wordt ondersteund met routeringsintentie. Zie De intentie en routeringsbeleid voor Virtual WAN Hub configureren voor meer informatie.
Virtual WAN laat zien dat beide circuits zijn verbonden met beide hubs:
Als u teruggaat naar de standaardvoorkeur voor hubroutering van ExpressRoute, worden de routes naar externe vertakkingen en VNets in hub 1 opnieuw ExpressRoute weergegeven als volgende hop. Hoewel deze keer de reden niet Global Reach is, maar het feit dat de ExpressRoute-circuits de routeadvertenties die ze van de ene hub naar de andere krijgen, niet terugsturen. De effectieve routes van hub 1 met hubrouteringsvoorkeur van ExpressRoute zijn bijvoorbeeld als volgt:
Als u de voorkeur voor hubroutering weer wijzigt in AS-pad, worden de tussen hubroutes naar het optimale pad geretourneerd met behulp van de directe verbinding tussen hubs 1 en 2:
Volgende stappen
Zie voor meer informatie over Virtual WAN: