Så här konfigurerar du routningsavsikt och routningsprinciper för Virtual WAN-hubbar

Med avsikten virtual WAN Hub-routning kan du konfigurera enkla och deklarativa routningsprinciper för att skicka trafik till bump-in-the-wire-säkerhetslösningar som Azure Firewall, Network Virtual Appliances eller SaaS-lösningar (software-as-a-service) som distribueras i Virtual WAN-hubben.

Bakgrund

Med routnings- och routningsprinciper kan du konfigurera virtual WAN-hubben för att vidarebefordra Internetbunden och privat (punkt-till-plats-VPN, plats-till-plats-VPN, ExpressRoute, virtuellt nätverk och virtuell nätverksinstallation) trafik till en Azure-brandvägg, nästa generations virtuella brandväggsnätverksinstallation (NGFW-NVA) eller säkerhetslösningen Programvara som en tjänst (SaaS) som distribueras i den virtuella hubben.

Det finns två typer av routningsprinciper: Internettrafik och principer för privat trafikroutning. Varje Virtuell WAN-hubb kan ha högst en internettrafikroutningsprincip och en privat trafikroutningsprincip, var och en med en enda Next Hop-resurs. Även om privat trafik innehåller adressprefix för både gren och virtuellt nätverk, betraktar routningsprinciper dem som en entitet inom begreppen Routnings avsikt.

• Internet Traffic Routing Policy (Internet Traffic Routing Policy): När en internettrafikroutningsprincip har konfigurerats på en virtuell WAN-hubb vidarebefordrar alla grener (VPN för fjärranvändare (punkt-till-plats-VPN), plats-till-plats-VPN och ExpressRoute) och virtuella nätverksanslutningar till den virtuella WAN-hubben internetbunden trafik till Azure Firewall, tredjepartssäkerhetsprovider, virtuell nätverksinstallation eller SaaS-lösning som anges som en del av routningsprincipen.

  Med andra ord annonserar Virtual WAN en standardväg (0.0.0.0.0/0) till alla ekrar, gatewayer och virtuella nätverksinstallationer (distribuerade i hubben eller ekern) när en internettrafikroutningsprincip konfigureras på en Virtuell WAN-hubb.

• Princip för privat trafikroutning: När en privat trafikroutningsprincip har konfigurerats på en virtuell WAN-hubb vidarebefordras all gren- och virtuell nätverkstrafik in och ut från Virtual WAN Hub, inklusive trafik mellan hubbar, till Azure-brandväggen Next Hop, den virtuella nätverksinstallationen eller SaaS-lösningsresursen.

  Med andra ord skickas all branch-to-branch, branch-to-virtual network, virtual network-to-branch och inter-hub-trafik via Azure Firewall, Network Virtual Appliance eller SaaS-lösningen som distribueras i Virtual WAN Hub när en princip för privat trafikroutning konfigureras på Virtual WAN Hub.

Användningsfall

I följande avsnitt beskrivs två vanliga scenarier där routningsprinciper tillämpas på säkra virtuella WAN-hubbar.

Alla Virtual WAN-hubbar är skyddade (distribueras med Azure Firewall, NVA eller SaaS-lösning)

I det här scenariot distribueras alla Virtual WAN-hubbar med en Azure Firewall-, NVA- eller SaaS-lösning i dem. I det här scenariot kan du konfigurera en internettrafikroutningsprincip, en princip för privat trafikroutning eller båda på varje Virtuell WAN-hubb.

Tänk dig följande konfiguration där Hub 1 och Hub 2 har routningsprinciper för både privat trafik och Internettrafik.

Hub 1-konfiguration:

• Privat trafikprincip med Azure-brandväggen, NVA- eller SaaS-lösningen Next Hop Hub 1
• Internet traffic policy with Next Hop Hub 1 Azure Firewall, NVA or SaaS solution (Internet Traffic Policy with Next Hop Hub 1 Azure Firewall, NVA eller SaaS-lösning)

Hub 2-konfiguration:

• Privat trafikprincip med Next Hop Hub 2 Azure Firewall, NVA eller SaaS-lösning
• Internet traffic policy with Next Hop Hub 2 Azure Firewall, NVA or SaaS solution (Internet Traffic Policy with Next Hop Hub 2 Azure Firewall, NVA eller SaaS-lösning)

Följande är de trafikflöden som följer av en sådan konfiguration.

Kommentar

Internettrafik måste gå ut via den lokala säkerhetslösningen i hubben eftersom standardvägen (0.0.0.0/0) inte sprids över hubbar.

Från	Till	Virtuella hubb 1-nätverk	Hubb 1-grenar	Virtuella hubb 2-nätverk	Hubb 2-grenar	Internet
Virtuella hubb 1-nätverk	→	Hub 1 AzFW eller NVA	Hub 1 AzFW eller NVA	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 AzFW, NVA eller SaaS
Hubb 1-grenar	→	Hub 1 AzFW, NVA eller SaaS	Hub 1 AzFW, NVA eller SaaS	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 AzFW, NVA eller SaaS
Virtuella hubb 2-nätverk	→	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS
Hubb 2-grenar	→	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 1 och 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2AzFW, NVA eller SaaS

Distribuera både säkra och vanliga Virtuella WAN-hubbar

I det här scenariot är inte alla hubbar i WAN säkra virtuella WAN-hubbar (hubbar som har en säkerhetslösning distribuerad i dem).

Tänk dig följande konfiguration där Hub 1 (Normal) och Hub 2 (skyddad) distribueras i ett virtuellt WAN. Hub 2 har routningsprinciper för både privat trafik och Internettrafik.

Hub 1-konfiguration:

• N/A (kan inte konfigurera routningsprinciper om hubben inte distribueras med Azure Firewall, NVA eller SaaS-lösningen)

Hub 2-konfiguration:

• Privat trafikprincip med Lösningen Next Hop Hub 2 Azure Firewall, NVA eller SaaS.
• Internet Traffic Policy med Next Hop Hub 2 Azure Firewall, NVA eller SaaS-lösning.

Följande är de trafikflöden som följer av en sådan konfiguration. Grenar och virtuella nätverk som är anslutna till Hub 1 kan inte komma åt Internet via en säkerhetslösning som distribueras i hubben eftersom standardvägen (0.0.0.0/0) inte sprids över hubbar.

Från	Till	Virtuella hubb 1-nätverk	Hubb 1-grenar	Virtuella hubb 2-nätverk	Hubb 2-grenar	Internet
Virtuella hubb 1-nätverk	→	Direkt	Direkt	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	-
Hubb 1-grenar	→	Direkt	Direkt	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	-
Virtuella hubb 2-nätverk	→	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS
Hubb 2-grenar	→	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS	Hub 2 AzFW, NVA eller SaaS

Kända begränsningar

• Routnings avsikt är för närvarande tillgänglig i Azure public. Microsoft Azure som drivs av 21Vianet och Azure Government finns för närvarande i översikten.
• Routningssyfte förenklar routning genom att hantera routningstabellassociationer och spridningar för alla anslutningar (virtuellt nätverk, plats-till-plats-VPN, punkt-till-plats-VPN och ExpressRoute). Virtuella WAN:er med anpassade routningstabeller och anpassade principer kan därför inte användas med konstruktionerna Routnings avsikt.
• Krypterad ExpressRoute (PLATS-till-plats-VPN-tunnlar som körs via ExpressRoute-kretsar) stöds i hubbar där routnings avsikten konfigureras om Azure Firewall är konfigurerad för att tillåta trafik mellan VPN-tunnelslutpunkter (plats-till-plats VPN Gateway privat IP och lokal VPN-enhet privat IP). Mer information om nödvändiga konfigurationer finns i Encrypted ExpressRoute with routing intent (Krypterad ExpressRoute med routningssyfte).
• Följande anslutningsanvändningsfall stöds inte med routnings avsikt:
  • Statiska vägar i defaultRouteTable som pekar på en anslutning till ett virtuellt nätverk kan inte användas tillsammans med routnings avsikt. Du kan dock använda BGP-peeringfunktionen.
  • Möjligheten att distribuera både en SD-WAN-anslutnings-NVA och en separat NVA- eller SaaS-brandväggslösning i samma Virtual WAN-hubb finns för närvarande på färdplanen. När routnings avsikten har konfigurerats med Nästa hopp SaaS-lösning eller Brandvägg NVA påverkas anslutningen mellan SD-WAN NVA och Azure. Distribuera i stället SD-WAN NVA- och Firewall NVA- eller SaaS-lösningen i olika virtuella hubbar. Du kan också distribuera SD-WAN NVA i ett virtuellt ekernätverk som är anslutet till hubben och utnyttja BGP-peeringfunktionen för virtuell hubb.
  • Virtuella nätverksinstallationer (NVA) kan bara anges som nästa hoppresurs för routningssyfte om de är nästa generations brandvägg eller nästa generations brandvägg med dubbla roller och SD-WAN NVA:er. För närvarande är checkpoint, fortinet-ngfw och fortinet-ngfw-and-sdwan de enda NVA:er som är berättigade att konfigureras som nästa hopp för routningssyfte. Om du försöker ange en annan NVA misslyckas skapande av routnings avsikt. Du kan kontrollera typen av NVA genom att navigera till din virtuella hubb –> Virtuella nätverksinstallationer och sedan titta på fältet Leverantör . Palo Alto Networks Cloud NGFW stöds också som nästa hopp för routningssyfte, men anses vara en nästa hopp av typen SaaS-lösning.
  • Routnings avsiktsanvändare som vill ansluta flera ExpressRoute-kretsar till Virtual WAN och vill skicka trafik mellan dem via en säkerhetslösning som distribueras i hubben kan aktivera öppna ett supportärende för att aktivera det här användningsfallet. Mer information finns i Aktivera anslutningar mellan ExpressRoute-kretsar .

Att tänka på

Kunder som för närvarande använder Azure Firewall i Virtual WAN-hubben utan routnings avsikt kan aktivera routnings avsikt med Hjälp av Azure Firewall Manager, Virtual WAN Hub Routing Portal eller via andra Azure-hanteringsverktyg (PowerShell, CLI, REST API).

Tänk på följande innan du aktiverar routnings avsikt:

• Routningssyfte kan bara konfigureras på hubbar där det inte finns några anpassade routningstabeller och inga statiska vägar i defaultRouteTable med nästa hopp Virtual Network Anslut ion. Mer information finns i förutsättningar.
• Spara en kopia av dina gatewayer, anslutningar och routningstabeller innan du aktiverar routnings avsikt. Systemet sparar och tillämpar inte tidigare konfigurationer automatiskt. Mer information finns i återställningsstrategi.
• Routnings avsikten ändrar de statiska vägarna i defaultRouteTable. På grund av optimeringar i Azure-portalen kan tillståndet för defaultRouteTable när routnings avsikten har konfigurerats vara annorlunda om du konfigurerar routnings avsikt med REST, CLI eller PowerShell. Mer information finns i statiska vägar.
• Aktivering av routnings avsikt påverkar annonsering av prefix till lokalt. Mer information finns i prefixannonser .
• Du kan öppna ett supportärende för att aktivera anslutning mellan ExpressRoute-kretsar via en brandväggsinstallation i hubben. Om du aktiverar det här anslutningsmönstret ändras prefixen som annonseras till ExpressRoute-kretsar. Mer information finns i Om ExpressRoute .
• Routningssyfte är den enda mekanismen i Virtual WAN för att möjliggöra trafikkontroll mellan hubbar via säkerhetsinstallationer som distribueras i hubben. Trafikkontroll mellan hubbar kräver också att routnings avsikten är aktiverad på alla hubbar för att säkerställa att trafiken dirigeras symmetriskt mellan säkerhetsinstallationer som distribueras i Virtual WAN-hubbar.

Förutsättningar

För att aktivera routnings avsikt och principer måste din virtuella hubb uppfylla nedanstående förutsättningar:

• Det finns inga anpassade routningstabeller som distribueras med den virtuella hubben. De enda routningstabeller som finns är noneRouteTable och defaultRouteTable.
• Du kan inte ha statiska vägar med nästa hopp Virtual Network Anslut ion. Du kan ha statiska vägar i defaultRouteTable har nästa hopp Azure Firewall.

Alternativet för att konfigurera routningssyfte är nedtonat för hubbar som inte uppfyller ovanstående krav.

Att använda routnings avsikt (aktivera alternativ mellan hubbar) i Azure Firewall Manager har ytterligare ett krav:

• Vägar som skapats av Azure Firewall Manager följer namngivningskonventionen för private_traffic, internet_traffic eller all_traffic. Därför måste alla vägar i defaultRouteTable följa den här konventionen.

Återställningsstrategi

Kommentar

När konfigurationen av routnings avsikten tas bort helt från en hubb är alla anslutningar till hubben inställda på att spridas till standardetiketten (som gäller för "alla" defaultRouteTables i Virtual WAN). Om du överväger att implementera routnings avsikt i Virtual WAN bör du därför spara en kopia av dina befintliga konfigurationer (gatewayer, anslutningar, routningstabeller) för att tillämpa om du vill återgå till den ursprungliga konfigurationen. Systemet återställer inte automatiskt den tidigare konfigurationen.

Routnings avsikt förenklar routning och konfiguration genom att hantera routningsassociationer och spridningar av alla anslutningar i en hubb.

I följande tabell beskrivs den associerade routningstabellen och de utbredda routningstabellerna för alla anslutningar när routnings avsikten har konfigurerats.

Konfiguration av routnings avsikt	Associerad routningstabell	Distribuerade routningstabeller
Internet	defaultRouteTable	standardetikett (defaultRouteTable för alla hubbar i Virtual WAN)
Privat	defaultRouteTable	noneRouteTable
Internet och privat	defaultRouteTable	noneRouteTable

Statiska vägar i defaultRouteTable

I följande avsnitt beskrivs hur routnings avsikten hanterar statiska vägar i defaultRouteTable när routnings avsikten är aktiverad på en hubb. De ändringar som routnings avsikten gör i defaultRouteTable kan inte ångras.

Om du tar bort routnings avsikten måste du återställa den tidigare konfigurationen manuellt. Därför rekommenderar vi att du sparar en ögonblicksbild av konfigurationen innan du aktiverar routnings avsikten.

Azure Firewall Manager och Virtual WAN Hub-portalen

När routnings avsikten är aktiverad på hubben skapas statiska vägar som motsvarar de konfigurerade routningsprinciperna automatiskt i defaultRouteTable. Dessa vägar är:

Routningsnamn	Prefix	Nästa hoppresurs
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_policy_PublicTraffic	0.0.0.0/0	Azure Firewall

Kommentar

Alla statiska vägar i defaultRouteTable som innehåller prefix som inte matchar exakt med 0.0.0.0/0 eller RFC1918 supernät (10.0.0.0/8, 192.168.0.0/16 och 172.16.0.0/12) konsolideras automatiskt till en enda statisk väg med namnet private_traffic. Prefix i defaultRouteTable som matchar RFC1918 supernät eller 0.0.0.0/0 tas alltid bort automatiskt när routnings avsikten har konfigurerats, oavsett principtyp.

Tänk till exempel på scenariot där defaultRouteTable har följande vägar innan du konfigurerar routningssyfte:

Routningsnamn	Prefix	Nästa hoppresurs
private_traffic	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Azure Firewall
to_internet	0.0.0.0/0	Azure Firewall
additional_private	10.0.0.0/8, 50.0.0.0/24	Azure Firewall

Om du aktiverar routnings avsikt på den här hubben skulle det resultera i följande sluttillstånd för defaultRouteTable. Alla prefix som inte är RFC1918 eller 0.0.0.0/0 konsolideras till en enda väg med namnet private_traffic.

Routningsnamn	Prefix	Nästa hoppresurs
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_policy_PublicTraffic	0.0.0.0/0	Azure Firewall
private_traffic	40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24	Azure Firewall

Andra metoder (PowerShell, REST, CLI)

Om du skapar routnings avsikt med metoder som inte är portaler skapas automatiskt motsvarande principvägar i defaultRouteTable och tar även bort eventuella prefix i statiska vägar som är exakta matchningar med 0.0.0.0/0 eller RFC1918 supernät (10.0.0.0/8, 192.168.0.0/16 eller 172.16.0.0/12). Andra statiska vägar konsolideras dock inte automatiskt.

Tänk till exempel på scenariot där defaultRouteTable har följande vägar innan du konfigurerar routningssyfte:

Routningsnamn	Prefix	Nästa hoppresurs
firewall_route_ 1	10.0.0.0/8	Azure Firewall
firewall_route_2	192.168.0.0/16, 10.0.0.0/24	Azure Firewall
firewall_route_3	40.0.0.0/24	Azure Firewall
to_internet	0.0.0.0/0	Azure Firewall

Följande tabell representerar det slutliga tillståndet för defaultRouteTable när routnings avsikten har skapats. Observera att firewall_route_1 och to_internet togs bort automatiskt eftersom det enda prefixet i dessa vägar var 10.0.0.0/8 och 0.0.0.0/0. firewall_route_2 ändrades för att ta bort 192.168.0.0/16 eftersom prefixet är ett RFC1918 aggregerat prefix.

Routningsnamn	Prefix	Nästa hoppresurs
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Azure Firewall
_policy_PublicTraffic	0.0.0.0/0	Azure Firewall
firewall_route_2	10.0.0.0/24	Azure Firewall
firewall_route_3	40.0.0.0/24	Azure Firewall

Prefixannons till lokal plats

I följande avsnitt beskrivs hur Virtual WAN annonserar vägar till en lokal plats när routnings avsikten har konfigurerats på en virtuell hubb.

Internetroutningsprincip

Kommentar

Standardvägen 0.0.0.0/0 annonseras inte över virtuella hubbar.

Om du aktiverar internetroutningsprinciper på den virtuella hubben annonseras standardvägen 0.0.0.0/0 till alla anslutningar till hubben (Virtual Network ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, NVA i hubben och BGP-anslutningar) där standardvägen Föröka eller Aktivera Internetsäkerhetsflagga är inställd på sant. Du kan ställa in den här flaggan på false för alla anslutningar som inte bör lära sig standardvägen.

Privat routningsprincip

När en virtuell hubb konfigureras med en privat routningsprincip annonserar Virtual WAN vägar till lokala anslutningar på följande sätt:

• Vägar som motsvarar prefix som lärts från den lokala hubbens virtuella nätverk, ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, NVA-in-the-hub- eller BGP-anslutningar som är anslutna till den aktuella hubben.
• Vägar som motsvarar prefix som har lärts från virtuella fjärrhubbnätverk, ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, NVA-in-the-hub- eller BGP-anslutningar där principer för privat routning konfigureras.
• Vägar som motsvarar prefix som har lärts från virtuella fjärrhubbnätverk, ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, NVA-in-the-hub- och BGP-anslutningar där routnings avsikt inte har konfigurerats och fjärranslutningarna sprids till defaultRouteTable för den lokala hubben.
• Prefix som har lärts från en ExpressRoute-krets annonseras inte till andra ExpressRoute-kretsar om inte Global Reach är aktiverat. Om du vill aktivera ExpressRoute till ExpressRoute-överföring via en säkerhetslösning som distribueras i hubben öppnar du ett supportärende. Mer information finns i Aktivera anslutning mellan ExpressRoute-kretsar.

Överföringsanslutning mellan ExpressRoute-kretsar med routnings avsikt

Överföringsanslutning mellan ExpressRoute-kretsar i Virtual WAN tillhandahålls via två olika konfigurationer. Eftersom dessa två konfigurationer inte är kompatibla bör kunderna välja ett konfigurationsalternativ för att stödja överföringsanslutning mellan två ExpressRoute-kretsar.

Kommentar

Om du vill aktivera ExpressRoute till ExpressRoute-överföringsanslutning via en brandväggsinstallation i hubben med privata routningsprinciper öppnar du ett supportärende med Microsoft Support. Det här alternativet är inte kompatibelt med Global Reach och kräver att Global Reach inaktiveras för att säkerställa korrekt överföringsroutning mellan alla ExpressRoute-kretsar som är anslutna till Virtual WAN.

• ExpressRoute Global Reach: ExpressRoute Global Reach gör att två globala Reach-aktiverade kretsar kan skicka trafik mellan varandra direkt utan att skicka den virtuella hubben.
• Routningsprincip för privat routning: Om du konfigurerar privata routningsprinciper kan två ExpressRoute-kretsar skicka trafik till varandra via en säkerhetslösning som distribueras i hubben.

Anslut ivity across ExpressRoute circuits via en brandväggsinstallation i hubben med routnings avsikt privat routningsprincip är tillgänglig i följande konfigurationer:

• Båda ExpressRoute-kretsarna är anslutna till samma hubb och en privat routningsprincip konfigureras på den hubben.
• ExpressRoute-kretsar är anslutna till olika hubbar och en privat routningsprincip konfigureras på båda hubbarna. Därför måste båda hubbarna ha en distribuerad säkerhetslösning.

Routningsöverväganden med ExpressRoute

Kommentar

Routningsövervägandena nedan gäller för alla virtuella hubbar i de prenumerationer som aktiveras av Microsoft Support för att tillåta ExpressRoute till ExpressRoute-anslutning via en säkerhetsinstallation i hubben.

När överföringsanslutningen mellan ExpressRoute-kretsar med hjälp av en brandväggsinstallation som distribueras i den virtuella hubben har aktiverats kan du förvänta dig följande ändringar i beteendet i hur vägar annonseras till ExpressRoute lokalt:

• Virtual WAN annonserar automatiskt RFC1918 aggregerade prefix (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) till ExpressRoute-anslutna lokalt. Dessa aggregerade vägar annonseras utöver de vägar som beskrivs i föregående avsnitt.
• Virtual WAN annonserar automatiskt alla statiska vägar i defaultRouteTable till ExpressRoute-kretsansluten lokalt. Det innebär att Virtual WAN annonserar de vägar som anges i textrutan för det privata trafikprefixet till lokalt.

På grund av dessa vägannonseringsändringar innebär det att ExpressRoute-anslutna lokala enheter inte kan annonsera exakta adressintervall för RFC1918 aggregerade adressintervall (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Se till att du annonserar mer specifika undernät (inom RFC1918 intervall) i stället för aggregerade supernät och eventuella prefix i textrutan Privat trafik.

Om ExpressRoute-kretsen annonserar ett prefix som inte är RFC1918 till Azure kontrollerar du dessutom att adressintervallen som du placerar i textrutan Privata trafikprefix är mindre specifika än ExpressRoute-annonserade vägar. Om ExpressRoute-kretsen till exempel annonserar 40.0.0.0/24 lokalt placerar du ett /23 CIDR-intervall eller större i textrutan Private Traffic Prefix (exempel: 40.0.0.0/23).

Dirigera annonser till andra lokala (plats-till-plats-VPN, punkt-så-plats-VPN, NVA) påverkas inte genom att aktivera ExpressRoute till ExpressRoute-överföringsanslutning via en säkerhetsinstallation som distribueras i hubben.

Krypterad ExpressRoute

Om du vill använda Encrypted ExpressRoute (PLATS-till-plats VPN-tunnel som körs över en ExpressRoute-krets) med routningsprinciper för privat routning konfigurerar du en brandväggsregel för att tillåta trafik mellan de privata IP-adresserna för virtuellt WAN-plats-till-plats-VPN-gateway (källa) och den lokala VPN-enheten (målet). För kunder som använder djuppaketsinspektion på brandväggsenheten rekommenderar vi att du undantar trafik mellan dessa privata IP-adresser från djuppaketsinspektion.

Du kan hämta tunnelns privata IP-adresser för VPN-gatewayen virtual WAN plats-till-plats genom att ladda ned VPN-konfigurationen och visa vpnSite Anslut ions –> gatewayConfiguration –> IPAddresses. IP-adresserna som anges i fältet IPAddresses är de privata IP-adresser som tilldelas till varje instans av vpn-gatewayen plats-till-plats som används för att avsluta VPN-tunnlar via ExpressRoute. I exemplet nedan är tunnel-IP-adresser på gatewayen 192.168.1.4 och 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

De privata IP-adresser som de lokala enheterna använder för VPN-avslutning är de IP-adresser som anges som en del av VPN-platslänkanslutningen.

Använd VPN-exempelkonfigurationen och VPN-platsen ovanifrån och skapa brandväggsregler för att tillåta följande trafik. VPN Gateway-IP-adresserna måste vara käll-IP-adressen och den lokala VPN-enheten måste vara mål-IP-adressen i de konfigurerade reglerna.

Regelparameter	Värde
Käll-IP-adress	192.168.1.4 och 192.168.1.5
Källport	*
Mål-IP-adress	10.100.0.4
Målport	*
Protokoll	NÅGON

Prestanda

Konfigurera privata routningsprinciper med Encrypted ExpressRoute dirigerar VPN ESP-paket via nästa hoppsäkerhetsinstallation som distribueras i hubben. Därför kan du förvänta dig maximalt VPN-tunnelflöde för Krypterad ExpressRoute på 1 Gbit/s i båda riktningarna (inkommande från lokalt och utgående från Azure). Tänk på följande distributionsoptimeringar för att uppnå maximalt VPN-tunnelflöde:

• Distribuera Azure Firewall Premium i stället för Azure Firewall Standard eller Azure Firewall Basic.
• Se till att Azure Firewall bearbetar regeln som tillåter trafik mellan VPN-tunnelslutpunkterna (192.168.1.4 och 192.168.1.5 i exemplet ovan) först genom att göra regeln till den högsta prioriteten i din Azure Firewall-princip. Mer information om logik för bearbetning av Azure Firewall-regler finns i Bearbetningslogik för Azure Firewall-regler.
• Inaktivera djuppaket för trafik mellan VPN-tunnelslutpunkterna. Information om hur du konfigurerar Azure Firewall för att undanta trafik från djuppaketsinspektion finns i dokumentationen om förbikopplingslistan för IDPS.
• Konfigurera VPN-enheter att använda GCMAES256 för både IPSEC-kryptering och integritet för att maximera prestanda.

Konfigurera routnings avsikt via Azure-portalen

Routnings- och routningsprinciper kan konfigureras via Azure-portalen med Hjälp av Azure Firewall Manager eller Virtual WAN-portalen. Med Azure Firewall Manager-portalen kan du konfigurera routningsprinciper med nästa hoppresurs i Azure Firewall. Med Virtual WAN-portalen kan du konfigurera routningsprinciper med nästa hoppresurs i Azure Firewall, Virtuella nätverksinstallationer som distribueras i den virtuella hubben eller SaaS-lösningarna.

Kunder som använder Azure Firewall i En virtuell WAN-skyddad hubb kan antingen ange inställningen "Aktivera inter-hubb" i Azure Firewall Manager till "Aktiverad" för att använda routningssyfte eller använda Virtual WAN-portalen för att konfigurera Azure Firewall som nästa hoppresurs för routning av avsikter och principer. Konfigurationer i någon av portalerna är likvärdiga och ändringar i Azure Firewall Manager återspeglas automatiskt i Virtual WAN-portalen och vice versa.

Konfigurera routnings avsikt och principer via Azure Firewall Manager

Följande steg beskriver hur du konfigurerar routnings- och routningsprinciper på din virtuella hubb med Hjälp av Azure Firewall Manager. Azure Firewall Manager stöder endast nästa hoppresurser av typen Azure Firewall.

1. Navigera till den virtuella WAN-hubb som du vill konfigurera routningsprinciper på.

2. Under Säkerhet väljer du Inställningar för säker virtuell hubb och sedan Hantera säkerhetsprovider och routningsinställningar för den här skyddade virtuella hubben i Azure Firewall Manager.

3. Välj den hubb som du vill konfigurera dina routningsprinciper på på menyn.

4. Välj Säkerhetskonfiguration under Inställningar

5. Om du vill konfigurera en internettrafikroutningsprincip väljer du Azure Firewall eller relevant Internet Security-provider i listrutan för Internettrafik. Om inte väljer du Ingen

6. Om du vill konfigurera en princip för privat trafikroutning (för gren- och virtuell nätverkstrafik) via Azure Firewall väljer du Azure Firewall i listrutan för Privat trafik. Om inte väljer du Kringgå Azure Firewall.

   

7. Om du vill konfigurera en privat trafikroutningsprincip och ha grenar eller virtuella nätverk som annonserar icke-IANA-RFC1918 prefix, väljer du Privata trafikprefix och anger prefixintervall som inte är IANA-RFC1918 i textrutan som visas. Välj Klar.

   

8. Välj Inter-hub som ska aktiveras. Om du aktiverar det här alternativet ser du till att dina routningsprinciper tillämpas på routnings avsikten för den här virtuella WAN-hubben.

9. Välj Spara.

10. Upprepa steg 2–8 för andra säkra virtuella WAN-hubbar som du vill konfigurera routingprinciper för.

11. Nu är du redo att skicka testtrafik. Kontrollera att brandväggsprinciperna är korrekt konfigurerade för att tillåta/neka trafik baserat på dina önskade säkerhetskonfigurationer.

Konfigurera routnings avsikt och principer via Virtual WAN-portalen

Följande steg beskriver hur du konfigurerar routnings- och routningsprinciper på din virtuella hubb med hjälp av Virtual WAN-portalen.

1. Från den anpassade portallänken i bekräftelsemeddelandet från steg 3 i avsnittet Förutsättningar går du till den Virtual WAN-hubb som du vill konfigurera routningsprinciper på.

2. Under Routning väljer du Routningsprinciper.

   

3. Om du vill konfigurera en princip för privat trafikroutning (för gren- och virtuell nätverkstrafik) väljer du Azure Firewall, Network Virtual Appliance eller SaaS-lösningar under Privat trafik. Under Nästa hoppresurs väljer du relevant nästa hoppresurs.

   

4. Om du vill konfigurera en privat trafikroutningsprincip och ha grenar eller virtuella nätverk med icke-IANA-RFC1918 prefix väljer du Ytterligare prefix och anger prefixintervall som inte är IANA-RFC1918 i textrutan som visas. Välj Klar. Se till att du lägger till samma prefix i textrutan För privat trafik i alla virtuella hubbar som konfigurerats med privata route-principer för att säkerställa att rätt vägar annonseras till alla hubbar.

   

5. Om du vill konfigurera en internettrafikroutningsprincip väljer du Azure Firewall, Network Virtual Appliance eller SaaS-lösningen. Under Nästa hoppresurs väljer du relevant nästa hoppresurs.

   

6. Om du vill tillämpa konfigurationen av routnings- och routningsprinciper klickar du på Spara.

   

7. Upprepa för alla hubbar som du vill konfigurera routningsprinciper för.

8. Nu är du redo att skicka testtrafik. Se till att brandväggsprinciperna är korrekt konfigurerade för att tillåta/neka trafik baserat på dina önskade säkerhetskonfigurationer.

Konfigurera routnings avsikt med hjälp av en BICEP-mall

Mer information om mallen och stegen finns i BICEP-mallen .

Felsökning

I följande avsnitt beskrivs vanliga sätt att felsöka när du konfigurerar routnings avsikter och principer på din Virtual WAN Hub.

Effektiva vägar

När principer för privat routning konfigureras på den virtuella hubben inspekteras all trafik mellan lokala och virtuella nätverk av Azure Firewall, Network Virtual Appliance eller SaaS-lösningen i den virtuella hubben.

Därför visar de effektiva vägarna i defaultRouteTable RFC1918 aggregerade prefix (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) med nästa hopp Azure Firewall eller Network Virtual Appliance. Detta återspeglar att all trafik mellan virtuella nätverk och grenar dirigeras till Azure Firewall-, NVA- eller SaaS-lösningen i hubben för inspektion.

När brandväggen har inspekterat paketet (och paketet tillåts enligt brandväggsregelkonfigurationen) vidarebefordrar Virtual WAN paketet till slutmålet. Om du vill se vilka vägar Virtual WAN använder för att vidarebefordra inspekterade paket visar du den effektiva routningstabellen för den virtuella brandväggen eller den virtuella nätverksinstallationen.

Den effektiva routningstabellen för brandväggen hjälper till att begränsa och isolera problem i nätverket, till exempel felkonfigurationer eller problem med vissa grenar och virtuella nätverk.

Felsöka konfigurationsproblem

Om du felsöker konfigurationsproblem bör du tänka på följande:

• Kontrollera att du inte har anpassade routningstabeller eller statiska vägar i defaultRouteTable med nästa hopp för anslutning till virtuellt nätverk.
  • Alternativet för att konfigurera routnings avsikten är nedtonat i Azure-portalen om distributionen inte uppfyller kraven ovan.
  • Om du använder CLI, PowerShell eller REST misslyckas skapandeåtgärden för routnings avsikt. Ta bort avsikten för misslyckad routning, ta bort anpassade routningstabeller och statiska vägar och försök sedan skapa igen.
  • Om du använder Azure Firewall Manager kontrollerar du att befintliga vägar i defaultRouteTable heter private_traffic, internet_traffic eller all_traffic. Alternativet för att konfigurera routnings avsikt (aktivera inter-hubb) är nedtonat om vägar namnges annorlunda.
• När du har konfigurerat routnings avsikten på en hubb ska du se till att alla uppdateringar av befintliga anslutningar eller nya anslutningar till hubben skapas med de valfria associerade och spridade routningstabellfälten inställda på tomma. Att ange valfria associationer och spridningar som tomma görs automatiskt för alla åtgärder som utförs via Azure-portalen.

Felsöka datasökväg

Förutsatt att du redan har granskat avsnittet Kända begränsningar kan du felsöka datasökvägar och anslutningar på följande sätt:

• Felsökning med effektiva vägar:
  • Om privata routningsprinciper har konfigurerats bör du se vägar med nästa hoppbrandvägg i de effektiva vägarna i defaultRouteTable för RFC1918 aggregeringar (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) samt eventuella prefix som anges i textrutan för privat trafik. Kontrollera att alla virtuella nätverk och lokala prefix är undernät inom de statiska vägarna i defaultRouteTable. Om ett lokalt eller virtuellt nätverk använder ett adressutrymme som inte är ett undernät inom de effektiva vägarna i defaultRouteTable lägger du till prefixet i textrutan privat trafik.
  • Om principer för internettrafikroutning har konfigurerats bör du se en standardväg (0.0.0.0/0) i de effektiva vägarna i defaultRouteTable.
  • När du har kontrollerat att de effektiva vägarna för defaultRouteTable har rätt prefix kan du visa de effektiva vägarna för den virtuella nätverksinstallationen eller Azure Firewall. Effektiva vägar i brandväggen visar vilka vägar Virtual WAN har valt och avgör vilka mål brandväggen kan vidarebefordra paket till. Att ta reda på vilka prefix som saknas eller i ett felaktigt tillstånd hjälper till att begränsa problem med datavägar och peka på rätt VPN-, ExpressRoute-, NVA- eller BGP-anslutning för felsökning.
• Scenariospecifik felsökning:
  • Om du har en icke-skyddad hubb (hubb utan Azure Firewall eller NVA) i ditt virtuella WAN kontrollerar du att anslutningar till den icke-skyddade hubben sprids till defaultRouteTable för hubbarna med konfigurerad routnings avsikt. Om spridningar inte är inställda på defaultRouteTable kan anslutningar till den skyddade hubben inte skicka paket till den icke-skyddade hubben.
  • Om du har konfigurerat internetroutningsprinciper kontrollerar du att inställningen "Sprid standardväg" eller "Aktivera Internetsäkerhet" är inställd på "true" för alla anslutningar som ska lära sig standardvägen 0.0.0.0/0. Anslut där den här inställningen är inställd på "false" lär sig inte vägen 0.0.0.0/0, även om internetroutningsprinciper har konfigurerats.
  • Om du använder privata slutpunkter som distribueras i virtuella nätverk som är anslutna till den virtuella hubben kringgår trafik från lokala slutpunkter som är avsedda för privata slutpunkter som distribueras i virtuella nätverk som är anslutna till Virtual WAN-hubben som standard routningssyftet nästa hopp Azure Firewall, NVA eller SaaS. Detta resulterar dock i asymmetrisk routning (vilket kan leda till förlust av anslutning mellan lokala och privata slutpunkter) eftersom privata slutpunkter i virtuella ekernätverk vidarebefordrar lokal trafik till brandväggen. För att säkerställa routningssymmetri aktiverar du routningstabellens nätverksprinciper för privata slutpunkter i undernäten där privata slutpunkter distribueras. Om du konfigurerar /32-vägar som motsvarar privata ip-adresser för privat slutpunkt i textrutan Privat trafik säkerställs inte trafiksymmetrin när privata routningsprinciper konfigureras på hubben.
  • Om du använder Encrypted ExpressRoute med principer för privat routning kontrollerar du att brandväggsenheten har en regel som konfigurerats för att tillåta trafik mellan den privata IP-tunnelslutpunkten för VPN Gateway för virtuell WAN-plats till plats och den lokala VPN-enheten. ESP-paket (krypterade yttre) bör logga in i Azure Firewall-loggar. Mer information om Krypterad ExpressRoute med routningssyfte finns i dokumentationen om Krypterad ExpressRoute.

Felsöka routningsproblem i Azure Firewall

• Kontrollera att etableringstillståndet för Azure Firewall är slutfört innan du försöker konfigurera routnings avsikten.
• Om du använder prefix som inte är IANA-RFC1918 i dina grenar/virtuella nätverk kontrollerar du att du har angett dessa prefix i textrutan "Privata prefix". Konfigurerade "privata prefix" sprids inte automatiskt till andra hubbar i virtual WAN som har konfigurerats med routnings avsikt. För att säkerställa anslutningen lägger du till dessa prefix i textrutan "Privata prefix" i varje enskild hubb som har routnings avsikt.
• Om du har angett icke-RFC1918 adresser som en del av textrutan Privata trafikprefix i Firewall Manager kan du behöva konfigurera SNAT-principer i brandväggen för att inaktivera SNAT för icke-RFC1918 privat trafik. Mer information finns i Azure Firewall SNAT-intervall.
• Konfigurera och visa Azure Firewall-loggar för att felsöka och analysera nätverkstrafiken. Mer information om hur du konfigurerar övervakning för Azure Firewall finns i Azure Firewall-diagnostik. En översikt över de olika typerna av brandväggsloggar finns i Loggar och mått för Azure Firewall.
• Mer information om Azure Firewall finns i Dokumentation om Azure Firewall.

Felsökning av virtuella nätverksinstallationer

• Kontrollera att etableringstillståndet för den virtuella nätverksinstallationen har slutförts innan du försöker konfigurera routnings avsikten.
• Om du använder icke-IANA-RFC1918 prefix i dina anslutna lokala nätverk eller virtuella nätverk kontrollerar du att du har angett dessa prefix i textrutan "Privata prefix". Konfigurerade "privata prefix" sprids inte automatiskt till andra hubbar i virtual WAN som har konfigurerats med routnings avsikt. För att säkerställa anslutningen lägger du till dessa prefix i textrutan "Privata prefix" i varje enskild hubb som har routnings avsikt.
• Om du har angett icke-RFC1918 adresser som en del av textrutan Privata trafikprefix kan du behöva konfigurera SNAT-principer på din NVA för att inaktivera SNAT för vissa icke-RFC1918 privat trafik.
• Kontrollera NVA-brandväggsloggarna för att se om trafiken tas bort eller nekas av brandväggsreglerna.
• Kontakta din NVA-provider för mer support och vägledning om felsökning.

Felsöka programvara som en tjänst

• Kontrollera att SaaS-lösningens etableringstillstånd är slutfört innan du försöker konfigurera routnings avsikten.
• Mer felsökningstips finns i felsökningsavsnittet i Virtual WAN-dokumentationen eller i Palo Alto Networks Cloud NGFW-dokumentationen.

Nästa steg

Mer information om routning av virtuell hubb finns i Om routning av virtuella hubbar. Mer information om Virtual WAN finns i Vanliga frågor och svar.