Dela via

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

  • Artikel

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 routningsprinciper 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 brandvägg (NGFW), virtuell nätverksinstallation (NVA) eller säkerhetslösning för 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.

  • Routningsprincip för Internettrafik: 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 trafik för gren och virtuellt nätverk 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.

    När en princip för privat trafikroutning konfigureras på Virtual WAN Hub skickas med andra ord alla branch-till-gren-, branch-to-virtual-nätverk, virtuellt nätverk-till-gren- och inter-hubb-trafik via Azure Firewall, nätverksvirtual installation eller SaaS-lösning som distribueras i 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 Virtuella 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.

Skärmbild som visar arkitektur med två säkra hubbar.

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 Firewall, NVA eller SaaS-lösningen Next Hop Hub 1
  • 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 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 with Next Hop Hub 2 Azure Firewall, NVA eller SaaS-lösning.

Skärmbild som visar arkitektur med en skyddad hubb, en normal hubb.

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

  • I följande tabell beskrivs avaiablility för routnings avsikt i olika Azure-miljöer.
    • Routnings avsikten är inte tillgänglig i Mirosoft Azure som drivs av 21 Vianet.
    • Palo Alto Cloud NGFW är endast tillgängligt i Azure Public. Kontakta Palo Alto Networks angående avaialbility of Cloud NGFW i Azure Government och Microsoft Azure som drivs av Viacom.
    • Virtuella nätverksinstallationer är inte tillgängliga i alla Azure Government-regioner. Kontakta din NVA-partner angående tillgänglighet i Azure Government.
Molnmiljö Azure Firewall Virtuell nätverksinstallation SaaS-lösningar
Azure Public Ja Ja Ja
Azure Government Ja Begränsad Nej
Microsoft Azure drivs av 21 Vianet Nej Nej Nej
  • 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.
    • Statiska vägar i den virtuella nätverksanslutningen med "statisk vägspridning" tillämpas inte på nästa hopp-resursen som anges i privata routningsprinciper. Stöd för att tillämpa statiska vägar på virtuella nätverksanslutningar på nästa hopp för privat routningsprincip finns i översikten.
    • 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.
    • Användare av routningsavsikt 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 öppna ett supportärende för att möjliggöra detta användningsfall. Mer information finns i Aktivera anslutningar mellan ExpressRoute-kretsar.

Adressutrymmesgränser för virtuellt nätverk

Kommentar

Det maximala antalet virtuella nätverksadressutrymmen som du kan ansluta till en enda Virtuell WAN-hubb kan justeras. Öppna ett Azure Support ärende för att begära en gränsökning. Gränserna gäller på Virtual WAN-hubbnivå. Om du har flera Virtual WAN-hubbar som kräver en gränsökning begär du en gränsökning för alla Virtual WAN-hubbar i din Virtual WAN-distribution.

För kunder som använder routningsavsikt är det maximala antalet adressutrymmen 400 i alla virtuella nätverk som är direkt anslutna till en enda Virtual WAN-hubb. Den här gränsen tillämpas individuellt på varje Virtual WAN-hubb i en Virtual WAN-distribution. Virtuella nätverksadressutrymmen som är anslutna till fjärranslutna (andra Virtual WAN-hubbar i samma Virtual WAN)-hubbar räknas inte mot den här gränsen.

Om antalet direktanslutna virtuella nätverksadressutrymmen som är anslutna till en hubb överskrider gränsen misslyckas aktivering eller uppdatering av routnings avsikten på den virtuella hubben. För hubbar som redan har konfigurerats med routningssyfte där virtuella nätverksadressutrymmen överskrider gränsen till följd av en åtgärd, till exempel en uppdatering av adressutrymmet för virtuellt nätverk, kanske det nyligen anslutna adressutrymmet inte kan dirigeras.

Begär proaktivt en gränsökning om det totala antalet adressutrymmen i alla lokalt anslutna virtuella nätverk överskrider 90 % av den dokumenterade gränsen eller om du har någon planerad nätverksexpansion eller distributionsåtgärder som ökar antalet virtuella nätverksadressutrymmen efter gränsen.

Följande tabell innehåller exempel på beräkningar av adressutrymme för virtuellt nätverk.

Virtuell hubb Antal virtuella nätverk Adressutrymmen per virtuellt nätverk Totalt antal virtuella nätverksadressutrymmen som är anslutna till virtuell hubb Föreslagen åtgärd
Hubb nr 1 200 1 200 Ingen åtgärd krävs, övervaka antal adressutrymmen.
Hubb nr 2 150 3 450 Ökning av begärandegräns för användning av routnings avsikt.
Hubb nr 3 370 1 370 Ökning av begärandegräns.

Du kan använda följande Powershell-skript för att beräkna antalet adressutrymmen i virtuella nätverk som är anslutna till en enda Virtual WAN-hubb. Kör det här skriptet för alla Virtual WAN-hubbar i ditt Virtuella WAN. Ett Azure Monitor-mått som gör att du kan spåra och konfigurera aviseringar på anslutna virtuella nätverksadressutrymmen finns i översikten.

Se till att ändra resurs-ID:t för Virtual WAN Hub i skriptet så att det matchar din miljö. Om du har anslutningar mellan klientorganisationer kontrollerar du att du har tillräcklig behörighet för att läsa anslutningsobjektet för virtuellt WAN-nätverk samt den anslutna virtuella nätverksresursen.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error ocurred  while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

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 Virtuell nätverksanslutning. 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 Azure Portal optimeringar 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.
  • Routnings avsikten skickar virtuellt nätverk och lokal trafik till nästa hoppresurs som anges i routningsprincipen. Virtual WAN programmerar den underliggande Azure-plattformen för att dirigera din lokala och virtuella nätverkstrafik i enlighet med den konfigurerade routningsprincipen och bearbetar inte trafiken via Virtual Hub-routern. Eftersom paket som dirigeras via routningssyfte inte bearbetas av routern behöver du inte allokera ytterligare routningsinfrastrukturenheter för vidarebefordran av dataplanspaket på hubbar som konfigurerats med routningssyfte. Du kan dock behöva allokera ytterligare routningsinfrastrukturenheter baserat på antalet virtuella datorer i virtuella nätverk som är anslutna till Virtual WAN Hub.
  • Med routningssyfte kan du konfigurera olika nästa hopp-resurser för privata routningsprinciper och internetroutningsprinciper. Du kan till exempel ange nästa hopp för privata routningsprinciper till Azure Firewall i hubben och nästa hopp för internetroutningsprincipen till en NVA- eller SaaS-lösning i hubben. Eftersom SaaS-lösningar och brandväggs-NVA:er distribueras i samma undernät i Virtual WAN-hubben kan distribution av SaaS-lösningar med en brandväggs-NVA i samma hubb påverka saaS-lösningarnas horisontella skalbarhet eftersom det finns färre IP-adresser tillgängliga för horisontell utskalning. Dessutom kan du ha högst en SaaS-lösning distribuerad i varje Virtual WAN-hubb.

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 virtuell nätverksanslutning. 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.

Scenarier för nyckelroutning

I följande avsnitt beskrivs några viktiga routningsscenarier och routningsbeteenden när du konfigurerar routnings avsikt på en Virtual WAN-hubb.

Ö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.

Anslutning mellan ExpressRoute-kretsar via en brandväggsinstallation i hubben med en princip för routning av avsikt för privat routning ä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 vpnSiteConnections –> 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.

Skärmbild som visar IP-adressen för VPN-platsens lokala enhetstunnel.

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 för Krypterad ExpressRoute

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.

Direktdirigering till NVA-instanser för dubbelrollsanslutning och brandväggs-NVA:er

Kommentar

Direktdirigering till NVA med dubbla roller som används med privata routningsprinciper i Virtual WAN gäller endast för trafik mellan virtuella nätverk och vägar som lärts via BGP från NVA-distribuerade i Virtual WAN-hubben. ExpressRoute- och VPN-överföringsanslutningar till NVA-anslutna lokalt dirigeras inte direkt till NVA-instanser och dirigeras i stället via nva-lastbalanseraren med dubbla roller.

Vissa virtuella nätverksinstallationer kan ha funktioner för både anslutning (SD-WAN) och säkerhet (NGFW) på samma enhet. Dessa NVA:er betraktas som nva:er med dubbla roller. Kontrollera om din NVA är NVA med dubbla roller under NVA-partner.

När privata routningsprinciper har konfigurerats för nva:er med dubbla roller annonserar Virtual WAN automatiskt vägar som lärts från den Virtuella WAN-hubbens NVA-enhet till direktanslutna (lokala) virtuella nätverk samt till andra virtuella hubbar i Virtual WAN med nästa hopp som NVA-instansen i motsats till nvas interna lastbalanserare.

För aktiva-passiva NVA-konfigurationer där endast en instans av NVA:erna annonserar en väg för ett specifikt prefix till Virtual WAN (eller as-PATH-längden på vägar som lärts från en av instanserna är alltid den kortaste) ser Virtual WAN till att utgående trafik från ett Virtuellt Azure-nätverk alltid dirigeras till den aktiva (eller föredragna) NVA-instansen.

Skärmbild som visar routningsmönster för aktiva passiva NVA:er.

För aktiva och aktiva NVA-konfigurationer (flera NVA-instanser annonserar samma prefix med samma AS-PATH-längd) utför Azure automatiskt ECMP för att dirigera trafik från Azure till en lokal plats. Azures programvarudefinierade nätverksplattform garanterar inte symmetri på flödesnivå, vilket innebär att inkommande flöde till Azure och utgående flöde från Azure kan landa på olika instanser av NVA. Detta resulterar i asymmetrisk routning som tas bort av tillståndskänslig brandväggskontroll. Därför rekommenderas det inte att använda aktiva-aktiva anslutningsmönster där en NVA beter sig som en NVA med dubbla roller om inte NVA kan stödja asymmetrisk vidarebefordran eller stöd för sessionsdelning/synkronisering. Kontakta NVA-providern om du vill ha mer information om huruvida din NVA stöder asymmetrisk vidarebefordran eller delning/synkronisering av sessionstillstånd.

Skärmbild som visar routningsmönster för aktiva aktiva NVA:er.

Konfigurera routningsavsikt via Azure-portalen

Routnings- och routningsprinciper kan konfigureras via Azure Portal 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 installationer i nätverket som distribueras i den virtuella hubben eller SaaS-lösningarna.

Kunder som använder Azure Firewall i en Virtual WAN-skyddad hubb kan antingen ställa in inställningen "Aktivera inter-hubb" i Azure Firewall Manager till "Aktiverad" för att använda routningsavsikt eller använda Virtual WAN-portalen för att konfigurera Azure Firewall som nästa hoppresurs för routningsavsikt 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. Skärmbild som visar hur du ändrar inställningar för säker hubb.

  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.

    Skärmbild som visar hur du konfigurerar routningsprinciper.

  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.

    Skärmbild som visar hur du redigerar prefix för privat trafik.

  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.

    Skärmbild som visar hur du navigerar till 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.

    Skärmbild som visar hur du konfigurerar privata NVA-routningsprinciper.

  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.

    Skärmbild som visar hur du konfigurerar ytterligare privata prefix för NVA-routningsprinciper.

  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.

    Skärmbild som visar hur du konfigurerar offentliga routningsprinciper för NVA.

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

    Skärmbild som visar hur du sparar konfigurationer av routningsprinciper.

  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

Kommentar

Att få de effektiva vägar som tillämpas på Virtual WAN-routningssyftet nästa hoppresurser stöds endast för nästa hoppresurs som anges i principen för privat routning. Om du använder både privata routningsprinciper och internetroutningsprinciper kontrollerar du de effektiva vägarna på nästa hoppresurs som anges i den privata routningsprincipen för de effektiva vägarna Virtual WAN-program på internetroutningsprincipen nästa hoppresurs. Om du bara använder internetroutningsprinciper kontrollerar du de effektiva vägarna på defaultRouteTable för att visa de vägar som är programmerade på internetroutningsprincipen nästa hoppresurs.

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.

Skärmbild som visar effektiva vägar för defaultRouteTable.

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.

Skärmbild som visar effektiva vägar för Azure Firewall.

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 Portal 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 Portal.

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. Anslutningar 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 distribuerats 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 routnings avsikten 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

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.