Delen via

Scenario: Verkeer routeren via een NVA

Bij het werken met Virtual WAN virtueel hub-routering zijn er nogal wat beschikbare scenario's. In dit NVA-scenario is het doel om verkeer te routeren via een NVA (virtueel netwerkapparaat) voor verbinding van vestiging naar virtueel netwerk en van virtueel netwerk naar vestiging. Voor informatie over virtuele hub-routering, zie About virtual hub routing.

Opmerking

Als u al een installatie hebt met routes die vooraf gaan aan de nieuwe mogelijkheden hoe u routering van virtuele hubs configureert , gebruikt u de stappen in deze versies van de artikelen:

Ontwerp

In this scenario we'll use the following naming convention:

  • "NVA VNets" voor virtuele netwerken waar gebruikers een NVA hebben geïmplementeerd en andere virtuele netwerken als spaken hebben verbonden (VNet 2 en VNet 4 in de Figure 2 verder in het artikel).
  • "NVA Spokes" voor virtuele netwerken verbonden met een NVA VNet (VNet 5, VNet 6, VNet 7 en VNet 8 in Figuur 2 verderop in het artikel).
  • "Non-NVA VNets" voor virtuele netwerken die zijn verbonden met Virtual WAN, zonder dat er een NVA of andere VNets mee zijn gepeerconnecteerd (VNet 1 en VNet 3 in Figuur 2 verderop in het artikel).
  • "Hubs" voor door Microsoft beheerde Virtual WAN-hubs, waaraan NVA-VNets zijn gekoppeld. NVA-spoke-VNets hoeven niet verbonden te zijn met Virtual WAN-hubs, alleen met NVA-VNets.

The following connectivity matrix summarizes the flows supported in this scenario:

Connectivity matrix

From Aan: NVA Spokes NVA VNets Non-NVA VNets Branches
NVA Spokes → Over NVA VNet Peering Over NVA VNet Over NVA VNet
NVA VNets → Peering Direct Direct Direct
Non-NVA VNets → Over NVA VNet Direct Direct Direct
Branches → Over NVA VNet Direct Direct Direct

Elke cel in de connectiviteitsmatrix beschrijft hoe een VNet of tak (de "Van" kant van de stroom, de rijkoppen in de tabel) communiceert met een bestemmings-VNet of tak (de "Naar" kant van de stroom, de kolomkoppen in cursief in de tabel). "Direct" betekent dat connectiviteit in de Virtual WAN zelf wordt geboden, "Peering" betekent dat connectiviteit wordt geboden door een door de gebruiker gedefinieerde route in de VNet. "Over NVA VNet" betekent dat de connectiviteit de NVA doorkruist die is ingezet in de NVA VNet. Houd rekening met de volgende items:

  • NVA-spokes worden niet beheerd door Virtual WAN. Als resultaat worden de mechanismen waarmee ze communiceren met andere VNets of filialen door de gebruiker onderhouden. Connectiviteit naar de NVA VNet wordt geleverd door een VNet-peering, en een standaardroute naar 0.0.0.0/0 die naar de NVA wijst als volgende hop, zou connectiviteit naar het internet, naar andere spaken en naar filialen moeten dekken.
  • NVA VNets zijn op de hoogte van hun eigen NVA-spaken, maar niet van NVA-spaken die verbonden zijn met andere NVA VNets. Bijvoorbeeld, in Figuur 2 verderop in dit artikel, is VNet 2 op de hoogte van VNet 5 en VNet 6, maar niet van andere spaken zoals VNet 7 en VNet 8. Een statische route is nodig om de prefixen van andere spaken in NVA-VNets te injecteren.
  • Evenzo zullen filialen en niet-NVA VNets niets weten over NVA-spokes, aangezien NVA-spokes niet verbonden zijn met Virtual WAN-hubs. Als gevolg hiervan zijn hier ook statische routes nodig.

Rekening houdend met het feit dat de NVA-spokes niet worden beheerd door Virtual WAN, vertonen alle andere rijen hetzelfde connectiviteitspatroon. As a result, a single route table (the Default one) is:

  • Virtual networks (non-hub VNets and user-hub VNets):
    • Associated route table: Default
    • Verspreiden naar routeringstabellen: Default
  • Branches:
    • Associated route table: Default
    • Propageren naar route tabellen: Default

In dit scenario moeten we echter nadenken over welke statische routes we moeten configureren. Elke statische route bestaat uit twee componenten: een deel in de Virtual WAN-hub dat de Virtual WAN-componenten vertelt welke verbinding voor elke 'spoke' moet worden gebruikt, en een ander deel in die specifieke verbinding dat wijst naar het concrete IP-adres dat is toegewezen aan de NVA (of naar een load balancer voor meerdere NVA's), zoals Figuur 1 laat zien.

Figure 1

Figure 1

With that, the static routes that we need in the Default table to send traffic to the NVA spokes behind the NVA VNet are as follows:

Beschrijving Routetabel Static route
VNet 2 Default 10.2.0.0/16 -> eastusconn
VNet 4 Default 10.4.0.0/16 -> weconn

Now, these static routes will be advertised to your on-premises branches, and the Virtual WAN hub will know which VNet connection to forward traffic to. However, the VNet connection needs to know what to do when receiving this traffic: This is where the connection route tables are used. Here we'll use the shorter prefixes (/24 instead of the longer /16), to make sure that these routes have preference over routes that are imported from the NVA VNets (VNet 2 and VNet 4):

Beschrijving Verbinding Statische route
VNet 5 eastusconn 10.2.1.0/24 -> 10.2.0.5
VNet 6 eastusconn 10.2.2.0/24 -> 10.2.0.5
VNet 7 weconn 10.4.1.0/24 -> 10.4.0.5
VNet 8 weconn 10.4.2.0/24 -> 10.4.0.5

Nu weten NVA-VNets, niet-NVA-VNets en filialen hoe ze alle NVA-spaken kunnen bereiken. Voor meer informatie over virtuele hub-routing, zie Over virtuele hub-routing.

Architectuur

In Figuur 2 zijn er twee hubs; Hub1 en Hub2.

  • Hub1 en Hub2 zijn direct verbonden met NVA VNets VNet 2 en VNet 4.

  • VNet 5 en VNet 6 zijn verbonden met VNet 2.

  • VNet 7 en VNet 8 zijn gekoppeld met VNet 4.

  • VNets 5,6,7,8 are indirect spokes, not directly connected to a virtual hub.

Figure 2

Figure 2

Overwegingen

  • Voor dit scenario kunt u een NVA van derden of Azure Firewall gebruiken in VNet 2 en VNet 4.

  • Dit scenario biedt geen ondersteuning voor Secure Hubs met routeringsintentie vanwege de beperkingen van het routeringsbeleid met betrekking tot statische routes. U kunt echter de BGP-peeringfunctie gebruiken om indirecte spokes te gebruiken in combinatie met Secure Hubs met routeringsintentie.

Scenario werkproces

To set up routing via NVA, here are the steps to consider:

  1. Identificeer de NVA spoke VNet-verbinding. In Figuur 2 zijn ze VNet 2 Connection (eastusconn) en VNet 4 Connection (weconn).

    Zorg ervoor dat er UDR's zijn opgezet:

    • Van VNet 5 en VNet 6 naar VNet 2 NVA IP
    • Van VNet 7 en VNet 8 naar VNet 4 NVA IP

    Je hoeft VNets 5,6,7,8 niet direct op de virtuele hubs aan te sluiten. Zorg ervoor dat NSG's in VNets 5,6,7,8 verkeer toestaan voor filialen (VPN/ER/P2S) of VNets die zijn verbonden met hun externe VNets. Bijvoorbeeld, VNets 5 en 6 moeten ervoor zorgen dat NSG's verkeer toestaan voor on-premises adresprefixen en VNets 7 en 8 die verbonden zijn met de externe Hub 2.

Virtual WAN ondersteunt geen scenario waarin VNets 5 en 6 verbinding maken met de virtuele hub en communiceren via de VNet 2 NVA IP-adres; daarom is het nodig om VNets 5 en 6 aan VNet 2 te koppelen, evenals VNets 7 en 8 aan VNet 4.

  1. Voeg een geaggregeerde statische routeringsinvoer toe voor VNets 2,5,6 aan de standaard routeringstabel van Hub 1.

    Example

    Opmerking

    Om de routing te vereenvoudigen en de wijzigingen in de Virtual WAN-hubrouteringstabellen te verminderen, raden we de nieuwe BGP-peering met de Virtual WAN-hub aan. Voor meer informatie, zie de volgende artikelen:

  2. Configure a static route for VNets 5,6 in VNet 2’s virtual network connection. To set up routing configuration for a virtual network connection, see virtual hub routing.

  3. Voeg een geaggregeerde statische route-invoer voor VNets 4, 7, 8 toe aan de standaard routeringstabel van Hub 1.

  4. Repeat steps 2, 3 and 4 for Hub 2’s Default route table.

Dit resulteert in wijzigingen in de routeringsconfiguratie, zoals weergegeven in Figuur 3.

Figure 3

Figure 3

Volgende stappen