Dela via

Scenario: Dirigera trafik via NVA:ar med hjälp av anpassade inställningar

  • Artikel

När du arbetar med Routning av virtuella hubbar i Azure Virtual WAN har du många tillgängliga alternativ. Fokus i den här artikeln är när du vill dirigera trafik via en virtuell nätverksinstallation (NVA) för kommunikation mellan virtuella nätverk och grenar och använda en annan NVA för internetbunden trafik. Mer information finns i Om routning av virtuella hubbar.

Anteckning

Observera att för routningsscenarierna nedan måste Virtual WAN hubb- och eker-Virtual Network som innehåller NVA finnas i samma Azure-region.

Design

  • Ekrar för virtuella nätverk som är anslutna till den virtuella hubben. (Till exempel VNet 1, VNet 2 och VNet 3 i diagrammet senare i den här artikeln.)
  • Tjänst-VNet för virtuella nätverk där användare har distribuerat en NVA för att inspektera trafik som inte är internet, och eventuellt med vanliga tjänster som nås av ekrar. (Till exempel VNet 4 i diagrammet senare i den här artikeln.)
  • Perimeter-VNet för virtuella nätverk där användare har distribuerat en NVA som ska användas för att inspektera internetbunden trafik. (Till exempel VNet 5 i diagrammet senare i den här artikeln.)
  • Hubbar för Virtual WAN hubbar som hanteras av Microsoft.

I följande tabell sammanfattas de anslutningar som stöds i det här scenariot:

Från Om du vill Spokes (ekrar) Tjänst-VNet Grenar Internet
Spokes (ekrar) -> Direkt Direkt via tjänst-VNet via perimeter-VNet
Tjänst-VNet -> Direkt saknas Direkt
Grenar -> via tjänst-VNet Direkt Direkt

Var och en av cellerna i anslutningsmatrisen beskriver om anslutningen flödar direkt över Virtual WAN eller över ett av de virtuella nätverken med en NVA.

Observera följande information:

  • Ekrar:
    • Ekrar når andra ekrar direkt över Virtual WAN hubbar.
    • Ekrar får anslutning till grenar via en statisk väg som pekar på det virtuella tjänstnätverket. De lär sig inte specifika prefix från grenarna, eftersom dessa prefix är mer specifika och åsidosätter sammanfattningen.
    • Ekrar skickar Internettrafik till perimeternätverket via en direkt VNet-peering.
  • Grenar kommer till ekrar via en statisk routning som pekar på det virtuella tjänstnätverket. De lär sig inte specifika prefix från de virtuella nätverk som åsidosätter den sammanfattade statiska vägen.
  • Det virtuella tjänstnätverket liknar ett virtuellt nätverk för delade tjänster som måste kunna nås från varje virtuellt nätverk och varje gren.
  • Det virtuella perimeternätverket behöver inte ha anslutning över Virtual WAN, eftersom den enda trafik som det stöder kommer via direkt peering för virtuella nätverk. För att förenkla konfigurationen använder du dock samma anslutningsmodell som för det virtuella perimeternätverket.

Det finns tre olika anslutningsmönster som översätts till tre routningstabeller. Associationerna till de olika virtuella nätverken är:

  • Ekrar:
    • Associerad routningstabell: RT_V2B
    • Spridning till routningstabeller: RT_V2B och RT_SHARED
  • VIRTUELLA NVA-nätverk (tjänst-VNet och DMZ VNet):
    • Associerad routningstabell: RT_SHARED
    • Spridning till routningstabeller: RT_SHARED
  • Grenar:
    • Associerad routningstabell: Standard
    • Spridning till routningstabeller: RT_SHARED och standard

Anteckning

Kontrollera att de virtuella ekernätverken inte sprids till standardetiketten. Detta säkerställer att trafik från grenar till virtuella ekernätverk vidarebefordras till NVA:erna.

Dessa statiska vägar säkerställer att trafik till och från det virtuella nätverket och grenen går via NVA i det virtuella tjänstnätverket (VNet 4):

Description Routningstabell Statisk väg
Grenar RT_V2B 10.2.0.0/16 –> vnet4conn
NVA-ekrar Standardvärde 10.1.0.0/16 –> vnet4conn

Nu kan du använda Virtual WAN för att välja rätt anslutning för att skicka paketen till. Du måste också använda Virtual WAN för att välja rätt åtgärd att vidta när du tar emot dessa paket. Du använder anslutningsvägstabellerna för detta enligt följande:

Description Anslutning Statisk väg
VNet2Branch vnet4conn 10.2.0.0/16 -> 10.4.0.5
Branch2VNet vnet4conn 10.1.0.0/16 -> 10.4.0.5

Mer information finns i Om routning av virtuella hubbar.

Arkitektur

Följande diagram visar arkitekturen som beskrevs tidigare i artikeln.

I diagrammet finns det en hubb. Hubb 1.

  • Hub 1 är direkt ansluten till virtuella NVA-nätverk VNet 4 och VNet 5.

  • Trafik mellan VNets 1, 2, 3 och grenarna förväntas gå via VNet 4 NVA 10.4.0.5.

  • All internetbunden trafik från VNets 1, 2 och 3 förväntas gå via VNet 5 NVA 10.5.0.5.

Diagram över nätverksarkitektur.

Arbetsflöde

Diagram över arbetsflödet.

Tänk på följande steg för att konfigurera routning via NVA:

  1. För att internetbunden trafik ska gå via VNet 5 behöver du VNets 1, 2 och 3 för att ansluta direkt via peering för virtuella nätverk till VNet 5. Du behöver också en användardefinierad väg som konfigurerats i de virtuella nätverken för 0.0.0.0/0 och nästa hopp 10.5.0.5.

    Om du inte vill ansluta VNets 1, 2 och 3 till VNet 5 och i stället bara använda NVA i VNet 4 för att dirigera 0.0.0.0/0-trafik från grenar (lokala VPN- eller ExpressRoute-anslutningar) går du till det alternativa arbetsflödet.

    Men om du vill att VNet-till-VNet-trafik ska passera genom NVA, måste du koppla bort VNet 1,2,3 från den virtuella hubben och ansluta den eller stapla den ovanför NVA Spoke VNet4. I Virtual WAN överförs VNet-till-VNet-trafik via Virtual WAN-hubben eller en Virtual WAN hubbens Azure Firewall (säker hubb). Om virtuella nätverk peerkopplas direkt med VNet-peering kan de kommunicera direkt genom att kringgå överföringen via den virtuella hubben.

  2. I Azure Portal går du till din virtuella hubb och skapar en anpassad routningstabell med namnet RT_Shared. Den här tabellen lär sig vägar via spridning från alla virtuella nätverk och grenanslutningar. Du kan se den här tomma tabellen i följande diagram.

    • Vägar: Du behöver inte lägga till några statiska vägar.

    • Association: Välj VNets 4 och 5, vilket innebär att anslutningarna för dessa virtuella nätverk associeras med routningstabellen RT_Shared.

    • Förökning: Eftersom du vill att alla grenar och virtuella nätverksanslutningar ska sprida sina vägar dynamiskt till den här routningstabellen väljer du grenar och alla virtuella nätverk.

  3. Skapa en anpassad routningstabell med namnet RT_V2B för att dirigera trafik från VNets 1, 2 och 3 till grenar.

    • Vägar: Lägg till en aggregerad statisk vägpost för grenar, med nästa hopp som VNet 4-anslutning. Konfigurera en statisk väg i VNet 4:s anslutning för grenprefix. Ange nästa hopp som den specifika IP-adressen för NVA i VNet 4.

    • Association: Välj alla virtuella nätverk 1, 2 och 3. Detta innebär att VNet-anslutningarna 1, 2 och 3 associeras med den här routningstabellen och kan lära sig vägar (statiska och dynamiska via spridning) i den här routningstabellen.

    • Förökning: Anslutningar sprider vägar till routningstabeller. Om du väljer VNets 1, 2 och 3 kan du sprida vägar från VNets 1, 2 och 3 till den här routningstabellen. Det finns inget behov av att sprida vägar från grenanslutningar till RT_V2B, eftersom den virtuella nätverkstrafiken för grenen går via NVA i VNet 4.

  4. Redigera standardroutningstabellen DefaultRouteTable.

    Alla VPN-, Azure ExpressRoute- och användarens VPN-anslutningar är associerade med standardroutningstabellen. Alla VPN-, ExpressRoute- och användar-VPN-anslutningar sprider vägar till samma uppsättning routningstabeller.

    • Vägar: Lägg till en aggregerad statisk vägpost för VNets 1, 2 och 3, med nästa hopp som VNet 4-anslutning. Konfigurera en statisk väg i VNet 4:s anslutning för Aggregerade prefix för VNet 1, 2 och 3. Ange nästa hopp som den specifika IP-adressen för NVA i VNet 4.

    • Association: Kontrollera att alternativet för grenar (VPN/ER/P2S) är markerat, vilket säkerställer att lokala grenanslutningar är kopplade till standardroutningstabellen.

    • Spridning från: Kontrollera att alternativet för grenar (VPN/ER/P2S) är markerat, vilket säkerställer att lokala anslutningar sprider vägar till standardroutningstabellen.

Alternativt arbetsflöde

I det här arbetsflödet ansluter du inte VNets 1, 2 och 3 till VNet 5. I stället använder du NVA i VNet 4 för att dirigera 0.0.0.0/0-trafik från grenar (lokala VPN- eller ExpressRoute-anslutningar).

Diagram över alternativt arbetsflöde.

Tänk på följande steg för att konfigurera routning via NVA:

  1. I Azure Portal går du till din virtuella hubb och skapar en anpassad routningstabell med namnet RT_NVA för att dirigera trafik via NVA 10.4.0.5

    • Vägar: Ingen åtgärd krävs.

    • Association: Välj VNet4. Detta innebär att VNet-anslutning 4 associerar till den här routningstabellen och kan lära sig vägar (statiska och dynamiska via spridning) i den här routningstabellen.

    • Förökning: Anslutningar sprider vägar till routningstabeller. Om du väljer VNets 1, 2 och 3 kan du sprida vägar från VNets 1, 2 och 3 till den här routningstabellen. Om du väljer grenar (VPN/ER/P2S) kan du sprida vägar från grenar/lokala anslutningar till den här routningstabellen. Alla VPN-, ExpressRoute- och användar-VPN-anslutningar sprider vägar till samma uppsättning routningstabeller.

  2. Skapa en anpassad routningstabell med namnet RT_VNET för att dirigera trafik från VNets 1, 2 och 3 till grenar eller Internet (0.0.0.0/0) via VNet4 NVA. VNet-till-VNet-trafik kommer att vara direkt och inte via VNet 4:s NVA. Om du vill att trafiken ska gå via NVA kopplar du från VNet 1, 2 och 3 och ansluter dem med VNet-peering till VNet4.

    • Vägar: 

      • Lägg till en aggregerad väg "10.2.0.0/16" med nästa hopp som VNet 4-anslutning för trafik som går från VNets 1, 2 och 3 mot grenar. I VNet4-anslutningen konfigurerar du en väg för "10.2.0.0/16" och anger att nästa hopp är den specifika IP-adressen för NVA i VNet 4.

      • Lägg till vägen "0.0.0.0/0" med nästa hopp som VNet 4-anslutning. "0.0.0.0/0" läggs till för att innebära att trafik skickas till Internet. Det innebär inte specifika adressprefix som rör virtuella nätverk eller grenar. I VNet4-anslutningen konfigurerar du en väg för "0.0.0.0/0" och anger att nästa hopp är den specifika IP-adressen för NVA i VNet 4.

    • Association: Välj alla virtuella nätverk 1, 2 och 3. Detta innebär att VNet-anslutningarna 1, 2 och 3 associeras med den här routningstabellen och kan lära sig vägar (statiska och dynamiska via spridning) i den här routningstabellen.

    • Förökning: Anslutningar sprider vägar till routningstabeller. Om du väljer VNets 1, 2 och 3 kan du sprida vägar från VNets 1, 2 och 3 till den här routningstabellen. Kontrollera att alternativet för grenar (VPN/ER/P2S) inte är markerat. Detta säkerställer att lokala anslutningar inte kan komma åt de virtuella nätverken 1, 2 och 3 direkt.

  3. Redigera standardroutningstabellen DefaultRouteTable.

    Alla VPN-, Azure ExpressRoute- och användarens VPN-anslutningar är associerade med standardroutningstabellen. Alla VPN-, ExpressRoute- och användar-VPN-anslutningar sprider vägar till samma uppsättning routningstabeller.

    • Vägar: 

      • Lägg till en aggregerad väg "10.1.0.0/16" för VNets 1, 2 och 3 med nästa hopp som VNet 4-anslutning.

      • Lägg till vägen "0.0.0.0/0" med nästa hopp som VNet 4-anslutning. "0.0.0.0/0" läggs till för att innebära att trafik skickas till Internet. Det innebär inte specifika adressprefix som rör virtuella nätverk eller grenar. I föregående steg för VNet4-anslutningen skulle du redan ha konfigurerat en väg för "0.0.0.0/0", med nästa hopp som den specifika IP-adressen för NVA i VNet 4.

    • Association: Kontrollera att alternativet för grenar (VPN/ER/P2S) är markerat. Detta säkerställer att lokala grenanslutningar är kopplade till standardroutningstabellen. Alla VPN-, Azure ExpressRoute- och användarens VPN-anslutningar är endast associerade med standardroutningstabellen.

    • Spridning från: Kontrollera att alternativet för grenar (VPN/ER/P2S) är markerat. Detta säkerställer att lokala anslutningar sprider vägar till standardroutningstabellen. Alla VPN-, ExpressRoute- och användar-VPN-anslutningar sprider vägar till "samma uppsättning routningstabeller".

Överväganden

  • Portalanvändare måste aktivera "Sprid till standardväg" på anslutningar (VPN/ER/P2S/VNet) för att 0.0.0.0/0-vägen ska börja gälla.

  • PS/CLI/REST-användare måste ange flaggan "enableinternetsecurity" till true för att vägen 0.0.0.0/0 ska börja gälla.

  • Den virtuella nätverksanslutningen stöder inte "multiple/unique" nästa hopp-IP till samma virtuella nätverksinstallation i ett virtuellt ekernätverk "om" en av vägarna med nästa hopp-IP anges vara offentlig IP-adress eller 0.0.0.0/0 (Internet).

  • När 0.0.0.0/0 har konfigurerats som en statisk väg på en virtuell nätverksanslutning tillämpas den vägen på all trafik, inklusive resurserna i själva ekern. Det innebär att all trafik vidarebefordras till IP-adressen för nästa hopp för den statiska vägen (NVA Privat IP). I distributioner med en 0.0.0.0/0-väg med NÄSTA hopp NVA IP-adress konfigurerad på en virtuell ekernätverksanslutning, för att komma åt arbetsbelastningar i samma virtuella nätverk som NVA direkt (dvs. så att trafiken inte passerar genom NVA), anger du en /32-väg på den virtuella ekernätverksanslutningen. Om du till exempel vill komma åt 10.1.3.1 direkt anger du 10.1.3.1/32 nästa hopp 10.1.3.1 på den virtuella ekernätverksanslutningen.

  • För att förenkla routningen och minska ändringarna i Virtual WAN hubbroutningstabeller rekommenderar vi att du använder det nya alternativet "BGP-peering med Virtual WAN hubb".

Nästa steg