Konfigurieren von Routingabsichten und Routingrichtlinien für den Virtual WAN-Hub

Artikel
09/25/2024

Mit Routingabsichten für den Virtual WAN-Hub können Sie einfache und deklarative Routingrichtlinien einrichten, um Datenverkehr an „Bump-in-the-Wire“-Sicherheitslösungen wie Azure Firewall, virtuelle Netzwerkgeräte oder SaaS (Software-as-a-Service)-Lösungen zu senden, die im Virtual WAN-Hub bereitgestellt werden.

Hintergrund

Routingabsicht und Routingrichtlinien ermöglichen es Ihnen, Ihren Virtual WAN-Hub so zu konfigurieren, dass internetgebundener und privater (Point-to-Site-VPN, Site-to-Site-VPN, ExpressRoute, Virtual Network und virtuelle Netzwerkgeräte) Datenverkehr über eine Azure Firewall, eine Firewall der nächsten Generation (NGFW), ein virtuelles Netzwerkgerät (NVA) oder eine Sicherheits-SaaS (Software-as-a-Service)-Lösung, die im virtuellen Hub bereitgestellt wird, weitergeleitet wird.

Es gibt zwei Arten von Routingrichtlinien: Richtlinien zum Routing von Internetdatenverkehr und Routingrichtlinien für privaten Datenverkehr. Jeder Virtual WAN-Hub kann höchstens jeweils eine Routing-Richtlinie für Internetdatenverkehr und für privaten Datenverkehr mit jeweils einer einzigen Next-Hop-Ressource haben. Während privater Datenverkehr sowohl Branch- als auch Virtual Network-Adresspräfixe umfasst, werden diese von Routingrichtlinien in Konzepten der Routingabsicht als eine Entität betrachtet.

Routingrichtlinie für Internetdatenverkehr: Wenn auf einem virtuellen WAN-Hub eine Routingrichtlinie für den Internetverkehr konfiguriert ist, leiten alle Branches (Remotebenutzer-VPN (Point-to-Site-VPN), Site-to-Site-VPN und ExpressRoute) und virtuellen Netzwerkverbindungen zu diesem virtuellen WAN-Hub den internetgebundenen Datenverkehr an die Azure Firewall, den Sicherheitsanbieter eines Drittanbieters, das virtuelle Netzwerkgerät oder die SaaS-Lösung weiter, die als Teil der Routingrichtlinie angegeben wurde.

Anders ausgedrückt: Wenn eine Routingrichtlinie für Internetdatenverkehr für einen Virtual WAN-Hub konfiguriert ist, kündigt Virtual WAN eine Standardroute (0.0.0.0/0) für alle Spokes, Gateways und (im Hub oder Spoke bereitgestellten) virtuellen Netzwerkgeräte an.
Routingrichtlinie für privaten Datenverkehr: Wenn eine Routingrichtlinie für privaten Datenverkehr für einen Virtual WAN-Hub konfiguriert ist, wird der gesamte eingehende und ausgehende Branch- und Virtual Network-Datenverkehr des Virtual WAN-Hubs, einschließlich zwischen Hubs, an die Ressource der Azure Firewall des nächsten Hops, die Ressource des virtuelle Netzwerkgeräts oder die Ressource der SaaS-Lösung weitergeleitet.

Anders ausgedrückt: Wenn eine Routingrichtlinie für privaten Datenverkehr auf dem Virtual WAN-Hub konfiguriert ist, wird der gesamte Datenverkehr von Branch zu Branch, von Branch zu virtuellem Netzwerk, von virtuellem Netzwerk zu Branch und zwischen Hubs, über die Azure Firewall, ein virtuelles Netzwerkgerät oder die SaaS-Lösung gesendet, die im Virtual WAN-Hub bereitgestellt sind.

Anwendungsfälle

Im folgenden Abschnitt werden zwei gängige Szenarien beschrieben, in denen Routingrichtlinien auf geschützte Virtual WAN-Hubs angewendet werden.

Alle Virtual WAN-Hubs sind gesichert (bereitgestellt mit Azure Firewall, einem NVA oder einer SaaS-Lösung)

Alle Virtual WAN-Hubs werden in diesem Szenario mit einer darin enthaltenen Azure Firewall, einem NVA oder einer SaaS-Lösung bereitgestellt. In diesem Szenario können Sie auf jedem Virtual WAN-Hub eine Richtlinie für das Routing von Internetdatenverkehr, eine Richtlinie für das Routing von privatem Datenverkehr oder beide Richtlinien konfigurieren.

Betrachten Sie die folgende Konfiguration, bei der Hub 1 und Hub 2 über Routingrichtlinien für privaten und Internetdatenverkehr verfügen.

Hub 1-Konfiguration:

Richtlinie für privaten Datenverkehr mit Hub 1-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung
Richtlinie für Internetdatenverkehr mit Hub 1-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung

Hub 2-Konfiguration:

Richtlinie für privaten Datenverkehr mit Hub 2-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung
Richtlinie für Internetdatenverkehr mit Hub 2-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung

Im Folgenden sind die Datenverkehrsflüsse aufgeführt, die sich aus einer solchen Konfiguration ergeben.

Hinweis

Der Internetdatenverkehr muss die lokale Sicherheitslösung im Hub durchlaufen, da die Standardroute (0.0.0.0/0) nicht über Hubs hinweg weitergegeben wird.

From	Beschreibung	VNets von Hub 1	Branches von Hub 1	VNets von Hub 2	Branches von Hub 2	Internet
VNets von Hub 1	→	Hub 1 AzFW oder NVA	Hub 1 AzFW oder NVA	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 AzFW, NVA oder SaaS
Branches von Hub 1	→	Hub 1 AzFW, NVA oder SaaS	Hub 1 AzFW, NVA oder SaaS	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 AzFW, NVA oder SaaS
VNets von Hub 2	→	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS
Branches von Hub 2	→	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 1 und 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2AzFW, NVA oder SaaS

Bereitstellung sowohl gesicherter als auch regulärer Virtual WAN-Hubs

In diesem Szenario sind nicht alle Hubs im WAN gesichert Virtual WAN-Hubs (Hubs, in denen eine Sicherheitslösung bereitgestellt ist).

Betrachten Sie die folgende Konfiguration, bei der Hub 1 (Normal) und Hub 2 (Geschützt) in einem Virtual WAN bereitgestellt werden. Hub 2 verfügt über Routingrichtlinien für privaten und Internetdatenverkehr.

Hub 1-Konfiguration:

N/V (kann keine Routingrichtlinien konfigurieren, wenn der Hub nicht mit Azure Firewall, NVA oder SaaS-Lösung bereitgestellt wird)

Hub 2-Konfiguration:

Richtlinie für privaten Datenverkehr mit Hub 2-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung.
Richtlinie für Internetdatenverkehr mit Hub 2-Azure Firewall des nächsten Hops, NVA oder SaaS-Lösung.

Im Folgenden sind die Datenverkehrsflüsse aufgeführt, die sich aus einer solchen Konfiguration ergeben. Branches und virtuelle Netzwerke, die mit Hub 1 verbunden sind, können über eine im Hub bereitgestellte Sicherheitslösung nicht auf das Internet zugreifen, da die Standardroute (0.0.0.0/0) nicht über Hubs weitergegeben wird.

From	Beschreibung	VNets von Hub 1	Branches von Hub 1	VNets von Hub 2	Branches von Hub 2	Internet
VNets von Hub 1	→	Direkt	Direkt	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	-
Branches von Hub 1	→	Direkt	Direkt	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	-
VNets von Hub 2	→	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS
Branches von Hub 2	→	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS	Hub 2 AzFW, NVA oder SaaS

Bekannte Einschränkungen

In der folgenden Tabelle sehen Sie die Verfügbarkeit der Routingabsicht in verschiedenen Azure-Umgebungen.
- Die Routingabsicht ist in Mirosoft Azure, betrieben von 21Vianet, nicht verfügbar.
- Palo Alto Cloud NGFW ist nur in der öffentlichen Azure-Cloud verfügbar. Wenden Sie sich an Palo Alto Networks bezüglich der Verfügbarkeit von Cloud NGFW in Azure Government und Microsoft Azure, betrieben von Viacom.
- Virtuelle Netzwerkappliances sind nicht in allen Azure Government-Regionen verfügbar. Wenden Sie sich an Ihren NVA-Partner bezüglich der Verfügbarkeit in Azure Government.

Cloudumgebung	Azure Firewall	Virtuelles Netzwerkgerät	Schnelles Erstellen von SaaS-Lösungen
Azure öffentlich	Ja	Ja	Ja
Azure Government	Ja	Begrenzt	No
Microsoft Azure, betrieben von 21Vianet	No	Nr.	No

Die Routingabsicht vereinfacht das Routing, indem Zuordnungen und Weitergaben in Routingtabellen für alle Verbindungen (Virtual Network, Site-to-Site-VPN, Point-to-Site-VPN und ExpressRoute) verwaltet werden. Virtual WAN-Instanzen mit benutzerdefinierten Routingtabellen und benutzerdefinierten Richtlinien können deshalb nicht mit den Routingabsichtskonstrukten verwendet werden.
Eine verschlüsselte ExpressRoute-Instanz (Site-to-Site-VPN-Tunnel, die über ExpressRoute-Leitungen ausgeführt werden) wird in Hubs unterstützt, in denen die Routingabsicht konfiguriert ist, wenn Azure Firewall so konfiguriert ist, dass Datenverkehr zwischen VPN-Tunnelendpunkten (private IP-Adresse des Site-to-Site-VPN-Gateways und private IP-Adresse des lokalen VPN-Geräts) zugelassen wird. Weitere Informationen zu den erforderlichen Konfigurationen finden Sie unter Verschlüsselte ExpressRoute-Instanz mit Routingabsicht.
Die folgenden Konnektivitätsanwendungsfälle werden mit der Routingabsicht nicht unterstützt:
- Statische Routen in der defaultRouteTable, die auf eine Virtual Network-Verbindung verweisen, können nicht in Verbindung mit der Routingabsicht verwendet werden. Sie können jedoch das BGP-Peering-Feature verwenden.
- Statische Routen für die virtuelle Netzwerkverbindung mit der „statischen Routenverteilung“ werden nicht auf die nächste Hop-Ressource angewendet, die in privaten Routingrichtlinien angegeben ist. Die Unterstützung für die Anwendung statischer Routen auf Verbindungen im virtuellen Netzwerk auf den nächsten Hop der privaten Routing-Richtlinie ist in Planung.
- Die Möglichkeit, sowohl ein SD-WAN-Konnektivitäts-NVA als auch eine separate Firewall-NVA- oder SaaS-Lösung in demselben Virtual WAN-Hub bereitzustellen, ist derzeit in der Roadmap enthalten. Nachdem die Routingabsicht mit einer SaaS-Lösung des nächsten Hops oder einem Firewall-NVA konfiguriert wurde, wird die Konnektivität zwischen dem SD-WAN-NVA und Azure beeinträchtigt. Stellen Sie stattdessen das SD-WAN-NVA und die Firewall-NVA- oder SaaS-Lösung in verschiedenen virtuellen Hubs bereit. Alternativ können Sie das SD-WAN-NVA auch in einem Spoke-Virtual Network bereitstellen, das mit dem Hub verbunden ist, und die BGP-Peeringfunktion des virtuellen Hubs nutzen.
- Virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) können nur als Ressource des nächsten Hops für die Routingabsicht angegeben werden, wenn es sich um eine Firewall der nächsten Generation oder eine Firewall der nächsten Generation mit dualer Rolle und SD-WAN-NVAs handelt. Derzeit sind Prüfpunkt, fortinet-ngfw und fortinet-ngfw-and-sdwan die einzigen berechtigten NVAs, die als nächster Hop für die Routingabsicht konfiguriert werden können. Wenn Sie versuchen, ein anderes NVA anzugeben, schlägt die Erstellung der Routingabsicht fehl. Sie können den Typ des NVA überprüfen, indem Sie zu Ihrem virtuellen Hub –> Virtuelle Netzwerkgeräte navigieren und sich dann das Feld Anbieter ansehen. Palo Alto Networks Cloud NGFW wird auch als nächster Hop für Routing Intent unterstützt, wird jedoch als nächster Hop SaaS-Lösung betrachtet.
- Benutzer der Routingabsicht, die mehrere ExpressRoute-Leitungen mit Virtual WAN verbinden und Datenverkehr zwischen ihnen über eine im Hub bereitgestellte Sicherheitslösung senden möchten, können einen Supportfall eröffnen, um diesen Anwendungsfall zu aktivieren. Weitere Informationen finden Sie unter Aktivieren der Konnektivität zwischen ExpressRoute-Leitungen.

Grenzwerte für den Adressraum des virtuellen Netzwerks

Hinweis

Die maximale Anzahl von VNet-Adressräumen, die Sie mit einem einzelnen Virtual WAN-Hub verbinden können, ist anpassbar. Öffnen Sie einen Azure-Supportfall, um eine Grenzwerterhöhung anzufordern. Die Grenzwerte gelten auf der Ebene des Virtual WAN-Hubs. Wenn Sie über mehrere Virtual WAN-Hubs verfügen, für die eine Grenzwerterhöhung erforderlich ist, fordern Sie eine Grenzwerterhöhung für alle Virtual WAN-Hubs in Ihrer Virtual WAN-Bereitstellung an.

Für Kunden, die Routingabsicht verwenden, beträgt die maximale Anzahl von Adressräumen in allen virtuellen Netzwerken, die mit einem einzelnen Virtual WAN-Hub direkt verbunden sind, 400. Dieser Grenzwert wird einzeln auf jeden Virtual WAN-Hub in einer Virtual WAN-Bereitstellung angewendet. VNet-Adressräume, die mit Remote-Hubs (andere Virtual WAN-Hubs in demselben Virtual WAN) verbunden sind, werden nicht auf diesen Grenzwert angerechnet.

Wenn die Anzahl der direkt verbundenen VNet-Adressräume, die mit einem Hub verbunden sind, den Grenzwert überschreitet, schlägt die Aktivierung oder Aktualisierung der Routingabsicht auf dem virtuellen Hub fehl. Für Hubs, die bereits mit Routingabsicht konfiguriert sind, bei denen die VNet-Adressräume den Grenzwert aufgrund eines Vorgangs wie einer Aktualisierung des VNet-Adressraums überschreiten, ist der neu verbundene Adressraum möglicherweise nicht routingfähig.

Fordern Sie proaktiv eine Erhöhung des Grenzwerts an, wenn die Gesamtzahl der Adressräume aller lokal verbundenen virtuellen Netzwerke 90 % des dokumentierten Grenzwerts überschreitet oder wenn es geplante Netzwerkerweiterungs- oder Bereitstellungsvorgänge gibt, die die Anzahl der VNet-Adressräume über den Grenzwert hinaus erhöhen.

Die folgende Tabelle enthält Beispielberechnungen für den VNet-Adressraum.

Virtueller Hub	Anzahl virtueller Netzwerke	Adressräume pro virtuellem Netzwerk	Gesamtanzahl der VNet-Adressräume, die mit dem virtuellen Hub verbunden sind	Vorgeschlagene Maßnahme
Hub 1	200	1	200	Keine Maßnahme erforderlich, Adressraumanzahl überwachen
Hub 2	150	3	450	Grenzwerterhöhung anfordern, um Routingabsicht zu verwenden
Hub 3	370	1	370	Grenzwerterhöhung anfordern

Sie können das folgende PowerShell-Skript verwenden, um die Anzahl der Adressräume in virtuellen Netzwerken zu schätzen, die mit einem einzelnen Virtual WAN-Hub verbunden sind. Führen Sie dieses Skript für alle Virtual WAN-Hubs in Ihrem Virtual WAN aus. Eine Azure Monitor-Metrik, mit der Sie Warnungen in verbundenen VNet-Adressräumen nachverfolgen und konfigurieren können, befindet sich auf der Roadmap.

Stellen Sie sicher, dass Sie die Ressourcen-ID des Virtual WAN-Hubs im Skript an Ihre Umgebung anpassen. Wenn Sie mandantenübergreifende virtuelle Netzwerkverbindungen haben, stellen Sie sicher, dass Sie über ausreichende Berechtigungen verfügen, um das Virtual WAN-Verbindungsobjekt sowie die verbundene virtuelle Netzwerkressource zu lesen.

$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

Überlegungen

Kunden, die derzeit Azure Firewall im Virtual WAN-Hub ohne Routingabsicht verwenden, können die Routingabsicht über Azure Firewall Manager, das Routingportal im Virtual WAN-Hub oder über andere Azure-Verwaltungstools (PowerShell, CLI, REST-API) aktivieren.

Bevor Sie die Routingabsicht aktivieren, sollten Sie Folgendes beachten:

Die Routingabsicht kann nur auf Hubs konfiguriert werden, in denen keine benutzerdefinierten Routingtabellen und keine statischen Routen in der defaultRouteTable mit einer Virtual Network-Verbindung des nächsten Hops vorhanden sind. Weitere Informationen finden Sie unter Voraussetzungen.
Speichern Sie eine Kopie Ihrer Gateways, Verbindungen und Routingtabellen, bevor Sie die Routingabsicht aktivieren. Das System wird vorherige Konfigurationen nicht automatisch speichern und anwenden. Weitere Informationen finden Sie unter Rollbackstrategie.
Die Routingabsicht ändert die statischen Routen in der defaultRouteTable. Aufgrund Azure-Portal Optimierungen kann der Status der defaultRouteTable nach dem Konfigurieren der Routingabsicht unterschiedlich sein, wenn Sie die Routingabsicht mithilfe von REST, CLI oder PowerShell konfigurieren. Weitere Informationen finden Sie unter Statische Routen.
Das Aktivieren der Routingabsicht wirkt sich auf die Ankündigung von Präfixen für lokale Umgebungen aus. Weitere Informationen finden Sie unter Präfix-Ankündigungen.
Sie können einen Supportfall öffnen, um die Konnektivität über ExpressRoute-Leitungen über eine Firewall-Appliance im Hub zu ermöglichen. Durch Aktivieren dieses Konnektivitätsmusters werden die Präfixe geändert, die zu ExpressRoute-Leitungen angekündigt wurden. Weitere Informationen finden Sie unter Infos zu ExpressRoute .
Die Routingabsicht ist der einzige Mechanismus in Virtual WAN, um Datenverkehrsüberprüfungen zwischen Hubs über im Hub bereitgestellte Sicherheitsappliances zu ermöglichen. Die Datenverkehrsüberprüfung zwischen Hubs erfordert außerdem, dass die Routingabsicht auf allen Hubs aktiviert wird, um sicherzustellen, dass der Datenverkehr symmetrisch zwischen Sicherheitsappliances weitergeleitet wird, die in Virtual WAN-Hubs bereitgestellt sind.
Die Routingabsicht sendet das virtuelle Netzwerk und den lokalen Datenverkehr an die nächste Hopressource, die in der Routingrichtlinie angegeben ist. Virtual WAN programmiert die zugrunde liegende Azure-Plattform, Ihren lokalen Datenverkehr und den im virtuellen Netzwerk gemäß der konfigurierten Routingrichtlinie weiterzuleiten, und verarbeitet den Datenverkehr nicht über den virtuellen Hubrouter. Da Pakete, die über Routingabsichten weitergeleitet werden, nicht vom Router verarbeitet werden, müssen Sie keine zusätzlichen Routinginfrastruktureinheiten für die Datenebenen-Paketweiterleitung auf Hubs zuweisen, die mit Routingabsicht konfiguriert sind. Möglicherweise müssen Sie jedoch zusätzliche Routinginfastruktureinheiten basierend auf der Anzahl der VMs in virtuellen Netzwerken zuordnen, die mit dem Virtual WAN-Hub verbunden sind.
Die Routingabsicht ermöglicht es Ihnen, verschiedene Ressourcen für den nächsten Hop für private und Internet-Routing-Richtlinien zu konfigurieren. Beispielsweise können Sie den nächsten Hop für private Routing-Richtlinien auf die Azure-Firewall im Hub und den nächsten Hop für Internet-Routing-Richtlinien auf eine NVA- oder SaaS-Lösung im Hub festlegen. Da SaaS-Lösungen und Firewall-NVAs im selben Subnetz im Virtual WAN-Hub bereitgestellt werden, kann die Bereitstellung von SaaS-Lösungen mit einer Firewall-NVA im selben Hub die horizontale Skalierbarkeit der SaaS-Lösungen beeinträchtigen, da weniger IP-Adressen für die horizontale Skalierung verfügbar sind. Darüber hinaus kann in jedem Virtual WAN-Hub höchstens eine SaaS-Lösung bereitgestellt werden.

Voraussetzungen

Um Routingabsichten und Routingrichtlinien zu aktivieren, muss Ihr virtueller Hub die folgenden Voraussetzungen erfüllen:

Es sind keine benutzerdefinierten Routingtabellen mit dem virtuellen Hub bereitgestellt. Die einzigen Routingtabellen, die vorhanden sind, sind die noneRouteTable und die defaultRouteTable.
Sie können keine statischen Routen mit einer Virtual Network-Verbindung des nächsten Hubs haben. Sie können statische Routen in der defaultRouteTable mit einer Azure Firewall des nächsten Hops haben.

Die Option zum Konfigurieren der Routingabsicht ist für Hubs, welche die oben genannten Anforderungen nicht erfüllen, abgeblendet.

Die Verwendung der Routingabsicht (Aktivieren der Option zwischen Hubs) in Azure Firewall Manager hat eine zusätzliche Anforderung:

Routen, die von Azure Firewall Manager erstellt werden, folgen der Namenskonvention von private_traffic, internet_traffic oder all_traffic. Daher müssen alle Routen in der defaultRouteTable dieser Konvention folgen.

Rollbackstrategie

Hinweis

Wenn die Routingabsichtskonfiguration vollständig von einem Hub entfernt wird, werden alle Verbindungen mit dem Hub so festgelegt, dass sie an die Standardbezeichnung weitergegeben werden. Dies gilt für alle Standardroutingtabellen (defaultRouteTables) in der Virtual WAN-Instanz. Wenn Sie daher die Implementierung der Routingabsicht in Virtual WAN in Erwägung ziehen, sollten Sie eine Kopie Ihrer vorhandenen Konfigurationen (Gateways, Verbindungen, Routingtabellen) speichern, um sie anzuwenden, wenn Sie die zur ursprünglichen Konfiguration zurückkehren möchten. Das System stellt Ihre vorherige Konfiguration nicht automatisch wieder her.

Die Routingabsicht vereinfacht das Routing und die Konfiguration, indem Routenzuordnungen und Weitergaben aller Verbindungen in einem Hub verwaltet werden.

In der folgenden Tabelle werden die zugeordnete Routingtabelle und die weitergegebenen Routingtabellen aller Verbindungen beschrieben, sobald die Routingabsicht konfiguriert ist.

Routingabsichtskonfiguration	Zugeordnete Routingtabelle	Weitergegebene Routingtabellen
Internet	defaultRouteTable	Standardbezeichnung (defaultRouteTable aller Hubs im Virtual WAN)
Privat	defaultRouteTable	noneRouteTable
Internet und Privat	defaultRouteTable	noneRouteTable

Statische Routen in defaultRouteTable

Im folgenden Abschnitt wird beschrieben, wie die Routingabsicht statische Routen in der defaultRouteTable verwaltet, wenn die Routingabsicht auf einem Hub aktiviert ist. Die Änderungen, welche die Routingabsicht an der defaultRouteTable vornimmt, sind irreversibel.

Wenn Sie die Routingabsicht entfernen, müssen Sie Ihre vorherige Konfiguration manuell wiederherstellen. Daher empfehlen wir, eine Momentaufnahme Ihrer Konfiguration zu speichern, bevor Sie die Routingabsicht aktivieren.

Azure Firewall Manager und Virtual WAN-Hubportal

Wenn die Routingabsicht auf dem Hub aktiviert ist, werden statische Routen, die den konfigurierten Routingrichtlinien entsprechen, automatisch in der defaultRouteTable erstellt. Diese Routen sind:

Routenname	Präfixe	Ressource für den nächsten Hop
_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

Hinweis

Alle statischen Routen in der defaultRouteTable, die Präfixe enthalten, die nicht exakt mit 0.0.0.0/0 oder den RFC1918-Supernetzen (10.0.0.0/8, 192.168.0.0/16 und 172.16.0.0/12) übereinstimmen werden automatisch in einer einzigen statischen Route mit dem Namen private_traffic konsolidiert. Präfixe in der defaultRouteTable, die mit RFC1918-Supernetzen oder 0.0.0.0/0 übereinstimmen, werden immer automatisch entfernt, sobald die Routingabsicht konfiguriert ist, unabhängig vom Richtlinientyp.

Betrachten Sie beispielsweise das Szenario, in dem die defaultRouteTable über die folgenden Routen vor dem Konfigurieren der Routingabsicht verfügt:

Routenname	Präfixe	Ressource für den nächsten Hop
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

Das Aktivieren der Routingabsicht für diesen Hub würde den folgenden Endstatus der defaultRouteTable zur Folge haben. Alle Präfixe, die nicht RFC1918 oder 0.0.0.0/0 sind, werden in einer einzelnen Route namens private_traffic konsolidiert.

Routenname	Präfixe	Ressource für den nächsten Hop
_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

Andere Methoden (PowerShell, REST, CLI)

Beim Erstellen einer Routingabsicht mithilfe von Nicht-Portal-Methoden werden automatisch die entsprechenden Richtlinienrouten in der defaultRouteTable erstellt und außerdem werden alle Präfixe in statischen Routen, die exakt mit 0.0.0.0/0 oder RFC1918-Supernetzen (10.0.0.0/8, 192.168.0.0/16 oder 172.16.0.0/12) übereinstimmen. Andere statische Routen werden jedoch nicht automatisch konsolidiert.

Betrachten Sie beispielsweise das Szenario, in dem die defaultRouteTable über die folgenden Routen vor dem Konfigurieren der Routingabsicht verfügt:

Routenname	Präfixe	Ressource für den nächsten Hop
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

Die folgende Tabelle stellt den endgültigen Zustand der defaultRouteTable dar, nachdem die Erstellung der Routingabsicht erfolgreich war. Beachten Sie, dass firewall_route_1 und to_internet automatisch entfernt wurden, da die einzige Präfixe in diesen Routen 10.0.0.0/8 und 0.0.0.0/0 waren. firewall_route_2 wurde geändert, um 192.168.0.0/16 zu entfernen, da dieses Präfix ein RFC1918-Aggregatpräfix ist.

Routenname	Präfixe	Ressource für den nächsten Hop
_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

Präfixankündigung für lokale Umgebungen

Im folgenden Abschnitt wird beschrieben, wie Virtual WAN die Routen an den lokalen Standort ankündigt, nachdem die Routingabsicht auf einem virtuellen Hub konfiguriert wurde.

Internetroutingrichtlinie

Hinweis

Die Standardroute 0.0.0.0/0 wird nicht über virtuelle Hubs angekündigt.

Wenn Sie Internetroutingrichtlinien auf dem virtuellen Hub aktivieren, wird die Standardroute 0.0.0.0/0 für alle Verbindungen mit dem Hub (Virtual Network ExpressRoute, Site-zu-Site-VPN, Punkt-zu-Site-VPN, NVA im Hub und BGP-Verbindungen) angekündigt, bei denen das Flag Standardroute weitergeben oder Internetsicherheit aktivieren auf WAHR festgelegt ist. Sie können dieses Flag für alle Verbindungen auf FALSCH festlegen, welche die Standardroute nicht erlernen sollten.

Richtlinie für privates Routing

Wenn ein virtueller Hub mit einer Richtlinie für privates Routing konfiguriert ist, kündigt Virtual WAN Routen an lokale Verbindungen wie folgt an:

Routen, die Präfixen entsprechen, die aus den virtuellen Netzwerken des lokalen Hubs, ExpressRoute, Site-zu-Site-VPN, Punkt-zu-Site-VPN, NVA im Hub oder BGP-Verbindungen, die mit dem aktuellen Hub verbunden sind, gelernt wurden.
Routen, die Präfixen entsprechen, die von virtuellen Remotehubnetzwerken, ExpressRoute, Site-zu-Site-VPN, Punkt-zu-Site-VPN, NVA im Hub oder BGP-Verbindungen gelernt wurden, bei denen private Routingrichtlinien konfiguriert sind.
Routen, die Präfixen entsprechen, die von virtuellen Remotehubnetzwerken, ExpressRoute, Site-zu-Site-VPN, Punk-zu-Site-VPN, NVA im Hub und BGP-Verbindungen gelernt wurden, bei denen die Routingabsicht nicht konfiguriert ist und die Remoteverbindungen an die defaultRouteTable des lokalen Hubs weitergegeben werden.
Präfixe, die von einer ExpressRoute-Verbindung gelernt wurden, werden nur dann für andere ExpressRoute-Leitungen angekündigt, wenn Global Reach aktiviert ist. Wenn Sie ExpressRoute-zu-ExpressRoute-Transit über eine im Hub bereitgestellte Sicherheitslösung aktivieren möchten, öffnen Sie einen Supportfall. Weitere Informationen finden Sie unter Aktivieren der Konnektivität zwischen ExpressRoute-Leitungen.

Wichtige Routingszenarien

Im folgenden Abschnitt werden einige wichtige Routing-Szenarien und Routing-Verhaltensweisen bei der Konfiguration der Routingabsicht auf einem Virtual WAN-Hub beschrieben.

Transitkonnektivität zwischen ExpressRoute-Leitungen mit Routingabsicht

Die Transitkonnektivität zwischen ExpressRoute-Leitungen innerhalb von Virtual WAN wird über zwei verschiedene Konfigurationen bereitgestellt. Da diese beiden Konfigurationen nicht kompatibel sind, müssen Kunden eine der Konfigurationsoptionen auswählen, um die Transitkonnektivität zwischen zwei ExpressRoute-Leitungen zu unterstützen.

Hinweis

Öffnen Sie einen Supportfall beim Microsoft-Support, um ExpressRoute-zu-ExpressRoute-Transitkonnektivität über eine Firewall-Appliance im Hub mit privaten Routingrichtlinien zu aktivieren. Diese Option ist nicht mit Global Reach kompatibel und erfordert die Deaktivierung von Global Reach, um ein ordnungsgemäßes Transitrouting zwischen allen ExpressRoute-Leitung sicherzustellen, die mit Virtual WAN verbunden sind.

ExpressRoute Global Reach: ExpressRoute Global Reach ermöglicht es zwei Leitungen mit Global Reach-Aktivierung, sich Datenverkehr direkt ohne Übertragung über den virtuellen Hub zu senden.
Private Routingrichtlinie für Routingabsicht: Die Konfiguration privater Routingrichtlinien ermöglicht es zwei ExpressRoute-Leitungen, sich gegenseitig Datenverkehr über eine im Hub installierte Sicherheitslösung zu senden.

Die Konnektivität zwischen ExpressRoute-Leitungen über eine Firewall-Appliance im Hub ohne private Routingrichtlinie für die Routingabsicht ist in den folgenden Konfigurationen verfügbar:

Beide ExpressRoute-Leitungen sind mit demselben Hub verbunden, und auf diesem Hub ist eine private Routingrichtlinie konfiguriert.
ExpressRoute-Leitungen sind mit verschiedenen Hubs verbunden, und eine private Routingrichtlinie ist für beide Hubs konfiguriert. Daher muss für beide Hubs eine Sicherheitslösung bereitgestellt werden.

Routingüberlegungen mit ExpressRoute

Hinweis

Die folgenden Routingüberlegungen gelten für alle virtuellen Hubs in den Abonnements, die von Microsoft-Support aktiviert werden, um Verbindungen von ExpressRoute zu ExpressRoute über eine Sicherheitsappliance im Hub zuzulassen.

Nachdem die Transitkonnektivität über ExpressRoute-Leitungen mithilfe einer Firewall-Appliance aktiviert ist, die im virtuellen Hub bereitgestellt wurde, können Sie die folgenden Verhaltensänderungen bei der Ankündigung von Routen für lokale ExpressRoute-Umgebungen erwarten:

Virtual WAN kündigt automatisch RFC1918-Aggregatpräfixe (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) für lokal verbundene ExpressRoute an. Diese aggregierten Routen werden zusätzlich zu den Routen angekündigt, die im vorherigen Abschnitt beschrieben wurden.
Virtual WAN kündigt automatisch alle statischen Routen in der defaultRouteTable für lokal verbundene ExpressRoute-Leitungen an. Dies bedeutet, dass Virtual WAN die Routen, die im Textfeld „Präfix für privaten Datenverkehr“ angegeben sind, lokal ankündigen.

Aufgrund dieser Änderungen an der Routenankündigung bedeutet dies, dass lokale verbundene ExpressRoute keine genauen Adressbereiche für RFC1918-Aggregat-Adressbereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ankündigen kann. Stellen Sie sicher, dass Sie spezifischere Subnetze (innerhalb von RFC1918-Bereichen) im Gegensatz zu aggregierten Supernetzen und Präfixen im Textfeld „Privater Datenverkehr“ ankündigen.

Wenn Ihre ExpressRoute-Leitung ein anderes Präfix als ein RFC1918-Präfix in Azure ankündigt, stellen Sie außerdem sicher, dass die im Textfeld für Präfixe für privaten Datenverkehr angegebenen Adressbereiche weniger spezifisch sind als angekündigte ExpressRoute-Routen. Wenn die ExpressRoute-Leitung beispielsweise 40.0.0.0/24 aus der lokalen Umgebung ankündigt, geben Sie im Textfeld für Präfixe für privaten Datenverkehr den CIDR-Bereich /23 oder einen größeren Bereich (Beispiel: 40.0.0.0.0/23) ein.

Routenankündigungen für andere lokale Ressourcen (Site-to-Site-VPN, Point-to-Site-VPN, NVA) sind nicht betroffen, wenn ExpressRoute-zu-ExpressRoute-Transitkonnektivität über eine im Hub bereitgestellte Sicherheitsappliance aktiviert wird.

Verschlüsseltes ExpressRoute

Um eine verschlüsselte ExpressRoute-Instanz (Site-to-Site-VPN-Tunnel, der über eine ExpressRoute-Leitung ausgeführt wird) mit privaten Routingrichtlinien für die Routingabsicht zu verwenden, konfigurieren Sie eine Firewallregel, um Datenverkehr zwischen den privaten IP-Adressen des Tunnels des Virtual WAN-Site-to-Site-VPN-Gateways (Quelle) und dem lokalen VPN-Gerät (Ziel) zuzulassen. Kunden, die eine umfassende Paketüberprüfung auf dem Firewallgerät verwenden, wird empfohlen, Datenverkehr zwischen diesen privaten IP-Adressen von der umfassenden Paketüberprüfung auszuschließen.

Sie können die privaten IP-Adressen des Tunnels des Virtual WAN-Site-to-Site-VPN-Gateways abrufen, indem Sie die VPN-Konfiguration herunterladen und vpnSiteConnections –> gatewayConfiguration –> IPAddresses anzeigen. Die im Feld „IPAddresses“ aufgeführten IP-Adressen sind die privaten IP-Adressen, die jeder Instanz des Site-to-Site-VPN-Gateways zugewiesen sind, das zum Beenden von VPN-Tunneln über ExpressRoute verwendet wird. Im folgenden Beispiel sind die Tunnel-IP-Adressen auf dem Gateway 192.168.1.4 und 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
          }
        }

Die privaten IP-Adressen, die die lokalen Geräte für die VPN-Beendigung verwenden, sind die IP-Adressen, die im Rahmen der VPN-Standortlinkverbindung angegeben werden.

Erstellen Sie mithilfe der VPN-Beispielkonfiguration und des VPN-Standorts von oben Firewallregeln, um den folgenden Datenverkehr zuzulassen. Bei den IP-Adressen von VPN Gateway muss es sich um die Quell-IP-Adresse handeln, und beim lokalen VPN-Gerät muss es sich um die Ziel-IP-Adresse in den konfigurierten Regeln handeln.

Regelparameter	Wert
Quell-IP	192.168.1.4 und 192.168.1.5
Quellport	*
Ziel-IP	10.100.0.4
Zielport	*
Protocol	ANY

Leistung für verschlüsselte ExpressRoute

Das Konfigurieren privater Routingrichtlinien mit verschlüsseltem ExpressRoute leitet VPN-ESP-Pakete über die Sicherheitsappliance des nächsten Hops weiter, die im Hub bereitgestellt wird. Daher können Sie für verschlüsseltes ExpressRoute einen maximalen VPN-Tunneldurchsatz von 1 GBit/s in beide Richtungen erwarten (eingehend aus der lokalen Umgebung und ausgehend von Azure). Zur Erzielung des maximalen VPN-Tunneldurchsatzes können folgende Bereitstellungsoptimierungen in Betracht gezogen werden:

Stellen Sie Azure Firewall Premium anstelle von Azure Firewall Standard oder Azure Firewall Basic bereit.
Stellen Sie sicher, dass Azure Firewall die Regel, die Datenverkehr zwischen den VPN-Tunnelendpunkten zulässt (192.168.1.4 und 192.168.1.5 im obigen Beispiel), zuerst verarbeitet, indem Sie in Ihrer Azure Firewall-Richtlinie die höchste Priorität für die Regel festlegen. Weitere Informationen zur Verarbeitungslogik für Azure Firewall-Regeln finden Sie unter Logik für die Azure Firewall-Regelverarbeitung.
Deaktivieren Sie Deep-Packet für den Datenverkehr zwischen den VPN-Tunnel-Endpunkten. Informationen zum Konfigurieren von Azure Firewall zum Ausschließen von Datenverkehr aus der umfassenden Paketüberprüfung finden Sie in der Dokumentation zur IDPS-Umgehungsliste.
Konfigurieren Sie VPN-Geräte für die Verwendung von GCMAES256 für IPsec-Verschlüsselung und -Integrität, um die Leistung zu maximieren.

Direkte Weiterleitung an NVA-Instanzen für Dual-Role-Konnektivität und Firewall-NVAs

Hinweis

Direktes Routing zu Dual-Role-NVAs, die mit privaten Routing-Richtlinien im virtuellen WAN verwendet werden, gilt nur für den Verkehr zwischen virtuellen Netzwerken und Routen, die über BGP von NVAs im virtuellen WAN-Hub gelernt wurden. ExpressRoute- und VPN-Transit-Konnektivität zu NVA-verbundenen lokalen Systemen wird nicht direkt zu NVA-Instanzen geleitet, sondern über den Load Balancer des Dual-Role-NVA.

Bestimmte virtuelle Netzwerkgeräte können sowohl Konnektivitäts- (SD-WAN) als auch Sicherheitsfunktionen (NGFW) auf demselben Gerät bieten. Diese NVAs werden als Dual-Role-NVAs betrachtet. Prüfen Sie unter NVA-Partner, ob Sie ein Dual-Role-NVA haben oder nicht.

Wenn private Routingrichtlinien für Dual-Role-NVAs konfiguriert sind, kündigt Virtual WAN automatisch Routen an, die von dem NVA-Gerät dieses virtuellen WAN-Hubs erlernt wurden, sowohl an direkt angeschlossene (lokale) virtuelle Netzwerke als auch an andere virtuelle Hubs im virtuellen WAN, wobei der nächste Hop die NVA-Instanz und nicht das interne Lastenausgleichsmodul des NVAs ist.

Bei aktiv-passiven NVA-Konfigurationen, bei denen nur eine Instanz der NVAs eine Route für ein bestimmtes Präfix an Virtual WAN ankündigt (oder die AS-PATH-Länge von Routen, die von einer der Instanzen gelernt wurden, immer die kürzeste ist), stellt Virtual WAN sicher, dass ausgehender Verkehr von einem Azure Virtual Network immer an die aktive (oder bevorzugte) NVA-Instanz weitergeleitet wird.

Bei aktiv-aktiven NVA-Konfigurationen (mehrere NVA-Instanzen kündigen das gleiche Präfix mit der gleichen AS-PATH-Länge an) führt Azure automatisch ECMP aus, um den Datenverkehr von Azure zu lokalen Systemen zu leiten. Die softwaredefinierte Netzwerkplattform von Azure garantiert keine Symmetrie auf Flow-Ebene, d. h. der eingehende Flow zu Azure und der ausgehende Flow von Azure können auf verschiedenen Instanzen des NVA landen. Dies führt zu einem asymmetrischen Routing, das von der zustandsbehafteten Firewallüberprüfung verworfen wird. Es wird daher nicht empfohlen, aktiv-aktive Konnektivitätsmuster zu verwenden, bei denen sich ein NVA wie ein Dual-Role-NVA verhält, es sei denn, das NVA kann asymmetrische Weiterleitung oder Sitzungsfreigabe/Synchronisierung unterstützen. Weitere Informationen darüber, ob Ihr NVA asymmetrische Weiterleitung oder gemeinsame Nutzung/Synchronisierung des Sitzungsstatus unterstützt, erhalten Sie von Ihrem NVA-Anbieter.

Konfigurieren der Routingabsicht über das Azure-Portal

Routingabsichten und Routingrichtlinien können über das Azure-Portal mit Azure Firewall Manager oder dem Virtual WAN-Portal konfiguriert werden. Im Azure Firewall Manager-Portal können Sie Routingrichtlinien über Azure Firewall mit Ressourcen des nächsten Hops konfigurieren. Im Virtual WAN-Portal können Sie Routingrichtlinien über Azure Firewall mit Ressourcen des nächsten Hops konfigurieren, wenn virtuelle Netzwerkgeräte in den virtuellen Hub- oder SaaS-Lösungen bereitgestellt werden.

Kunden, die Azure Firewall in einem per Virtual WAN gesicherten Hub verwenden, können entweder die Einstellung „Inter-Hub aktivieren“ des Azure Firewall Manager auf „Aktiviert“ festlegen, um die Routingabsicht zu verwenden, oder sie können Azure Firewall im Virtual WAN-Portal direkt als Ressource des nächsten Hops für die Routingabsicht und die Routingrichtlinien konfigurieren. Konfigurationen in beiden Portalen sind gleichwertig, und Änderungen in Azure Firewall Manager werden automatisch in Virtual WAN Portal reflektiert und umgekehrt.

Konfigurieren von Routingabsichten und Routingrichtlinien über Azure Firewall Manager

In den folgenden Schritten wird beschrieben, wie Sie Routingabsichten und Routingrichtlinien für Ihren virtuellen Hub mit Azure Firewall Manager konfigurieren. Azure Firewall Manager unterstützt nur Ressourcen für den nächsten Hop vom Typ „Azure Firewall“.

Navigieren Sie zu dem Virtual WAN-Hub, für den Sie Routingrichtlinien konfigurieren möchten.
Wählen Sie unter Sicherheit Einstellungen für einen geschützten virtuellen Hub und dann Sicherheitsanbieter- und Routeneinstellungen für diesen geschützten virtuellen Hub in Azure Firewall Manager verwalten.
Wählen Sie im Menü den Hub aus, für den Sie Ihre Routingrichtlinien konfigurieren möchten.
Wählen Sie Sicherheitskonfiguration unter Einstellungen aus.
Wenn Sie eine Richtlinie für die Weiterleitung des Internetdatenverkehrs konfigurieren möchten, wählen Sie Azure Firewall oder den entsprechenden Internetsicherheitsanbieter aus der Dropdownliste für Internetdatenverkehr aus. Wählen Sie andernfalls Keine aus.
Wenn Sie eine Richtlinie für die Weiterleitung von privatem Datenverkehr (für Zweigstellen- und virtuellen Netzwerkdatenverkehr) über Azure Firewall konfigurieren möchten, wählen Sie Azure Firewall im Dropdownmenü für Privater Datenverkehr aus. Andernfalls wählen Sie Azure Firewall umgehen aus.
Wenn Sie eine Richtlinie für das Routing von privatem Datenverkehr konfigurieren möchten und über Zweigstellen oder virtuelle Netzwerke verfügen, die Nicht-IANA-RFC1918-Präfixe ankündigen, wählen Sie Präfixe für privaten Datenverkehr aus, und geben Sie die Nicht-IANA-RFC1918-Präfixbereiche im angezeigten Textfeld an. Wählen Sie Fertigaus.
Wählen Sie für Inter-hub (Zwischen Hubs) die Option Aktiviert aus. Wenn Sie diese Option aktivieren, wird sichergestellt, dass Ihre Routingrichtlinien auf die Routingabsicht dieses Virtual WAN-Hubs angewendet werden.
Wählen Sie Speichern aus.
Wiederholen Sie die Schritte 2 bis 8 für andere geschützte Virtual WAN-Hubs, für die Sie Routingrichtlinien konfigurieren möchten.
An diesem Punkt können Sie Testdatenverkehr senden. Stellen Sie sicher, dass Ihre Firewallrichtlinien entsprechend konfiguriert sind, um Datenverkehr basierend auf Ihren gewünschten Sicherheitskonfigurationen zu erlauben bzw. zu verweigern.

Konfigurieren von Routingabsichten und Routingrichtlinien über das Virtual WAN-Portal

In den folgenden Schritten wird beschrieben, wie Sie Routingabsichten und Routingrichtlinien für Ihren virtuellen Hub mithilfe des Virtual WAN-Portals konfigurieren.

Navigieren Sie über den benutzerdefinierten Portallink in der Bestätigungs-E-Mail von Schritt 3 im Abschnitt Voraussetzungen zu dem Virtual WAN-Hub, für den Sie Routingrichtlinien konfigurieren möchten.
Unter Routing die Option Routingrichtlinien auswählen.
Wenn Sie eine Routingrichtlinie für privaten Datenverkehr (für Branch- und Virtual Network-Datenverkehr) konfigurieren möchten, wählen Sie unter Privater Datenverkehr die Optionen Azure Firewall, Virtuelles Netzwerkgerät oder SaaS-Lösungen aus. Wählen Sie unter Ressource des nächsten Hops die relevante Ressource des nächsten Hops aus.
Wenn Sie eine Routingrichtlinie für privaten Datenverkehr konfigurieren möchten und Zweigstellen oder virtuelle Netzwerke haben, die Nicht-IANA-RFC1918-Präfixe verwenden, wählen Sie Zusätzliche Präfixe aus und geben Sie die Nicht-IANA-RFC1918-Präfixbereiche im angezeigten Textfeld an. Wählen Sie Fertigaus. Achten Sie darauf, dass Sie dem Textfeld „Präfix für privaten Datenverkehr“ in allen virtuellen Hubs, die mit Richtlinien für privates Routing konfiguriert sind, dasselbe Präfix hinzufügen, um sicherzustellen, dass für alle Hubs die richtigen Routen angekündigt werden.
Wenn Sie eine Routingrichtlinie für Internetdatenverkehr konfigurieren möchten, wählen Sie Azure Firewall, virtuelles Netzwerkgerät oder SaaS-Lösung aus. Wählen Sie unter Ressource des nächsten Hops die relevante Ressource des nächsten Hops aus.
Zum Anwenden Ihrer Routingabsicht- und Routing-Richtlinienkonfiguration auf Speichern klicken.
Wiederholen Sie dies für alle Hubs, für die Sie Routing-Richtlinien konfigurieren möchten.
An diesem Punkt können Sie Testdatenverkehr senden. Stellen Sie sicher, dass Ihre Firewallrichtlinien entsprechend konfiguriert sind, um Datenverkehr basierend auf Ihren gewünschten Sicherheitskonfigurationen zu erlauben bzw. zu verweigern.

Konfigurieren der Routingabsicht mithilfe einer BICEP-Vorlage

Informationen zu den Vorlagen und Schritten finden Sie in der BICEP-Vorlage.

Problembehandlung

Im folgenden Abschnitt werden allgemeine Möglichkeiten zur Problembehandlung beschrieben, wenn Sie Routingabsichten und Routingrichtlinien für Ihren Virtual WAN-Hub konfigurieren.

Effektive Routen

Hinweis

Das Abrufen der effektiven Routen, die auf Virtual WAN Routingabsicht für die nächste Hopressource angewendet werden, wird nur für die nächste Hopressource unterstützt, die in der privaten Routingrichtlinie angegeben ist. Wenn Sie sowohl private als auch Internetroutingrichtlinien verwenden, überprüfen Sie die effektiven Routen für die nächste Hopressource, die in der privaten Routingrichtlinie angegeben ist, auf die WAN-Programme für effektive Routen in der Internetroutingrichtlinie als nächste Hopressource. Wenn Sie nur Internetroutingrichtlinien verwenden, überprüfen Sie die effektiven Routen in der defaultRouteTable, um die in der Internetroutingrichtlinie programmierten Routen als nächste Hopressource anzuzeigen.

Wenn private Routingrichtlinien auf dem virtuellen Hub konfiguriert sind, wird der gesamte Datenverkehr zwischen lokalen und virtuellen Netzwerken von Azure Firewall, einer virtuellen Netzwerkappliance oder einer SaaS-Lösung im virtuellen Hub überprüft.

Daher zeigen die effektiven Routen der defaultRouteTable die RFC1918-Aggregatpräfixe (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) mit dem Azure Firewall des nächsten Hops oder virtuelle Netzwerkgeräten an. Dies spiegelt wider, dass der gesamte Datenverkehr zwischen virtuellen Netzwerken und Branches zur Überprüfung an Azure Firewall, NVA oder SaaS-Lösung im Hub weitergeleitet wird.

Nachdem die Firewall das Paket überprüft hat (und das Paket gemäß Firewallregelkonfiguration zulässig ist), leitet Virtual WAN das Paket an das endgültige Ziel weiter. Um zu sehen, welche Routen Virtual WAN zum Weiterleiten überprüfter Pakete verwendet, sehen Sie sich die effektive Routingtabelle der Firewall oder des virtuellen Netzwerkgeräts an.

Die effektive Routingtabelle der Firewall hilft dabei, Probleme in Ihrem Netzwerk einzugrenzen und zu isolieren, z. B. falsche Konfigurationen oder Probleme mit bestimmten Branches und virtuellen Netzwerken.

Problembehandlung von Konfigurationsproblemen

Bei der Problembehandlung von Konfigurationsproblemen sollten Sie Folgendes berücksichtigen:

Stellen Sie sicher, dass Sie keine benutzerdefinierten Routingtabellen oder statischen Routen in der defaultRouteTable mit der Virtual Network-Verbindung des nächsten Hops haben.
- Die Option zum Konfigurieren der Routingabsicht ist im Azure-Portal abgeblendet, wenn Ihre Bereitstellung die oben genannten Anforderungen nicht erfüllt.
- Wenn Sie CLI, PowerShell oder REST verwenden, tritt beim Erstellungsvorgang für die Routingabsicht ein Fehler auf. Löschen Sie die fehlerhafte Routingabsicht, entfernen Sie die benutzerdefinierten Routingtabellen und statischen Routen, und versuchen Sie dann, dies erneut zu erstellen.
- Wenn Sie Azure Firewall Manager verwenden, stellen Sie sicher, dass vorhandene Routen in der defaultRouteTable als private_traffic, internet_traffic oder all_traffic benannt sind. Die Option zum Konfigurieren der Routingabsicht (Aktivieren zwischen Hubs) ist abgeblendet, wenn Routen anders benannt sind.
Stellen Sie nach dem Konfigurieren der Routingabsicht für einen Hub sicher, dass Updates vorhandener Verbindungen oder die Erstellung neuer Verbindungen mit dem Hub mit den auf leer festgelegten optionalen zugeordneten und weitergegebenen Routingtabellenfelder durchgeführt werden. Das Festlegen der optionalen Zuordnungen und Weitergaben als leer erfolgt automatisch für alle Vorgänge, die über das Azure-Portal ausgeführt werden.

Problembehandlung für den Datenpfad

Wenn Sie den Abschnitt Bekannte Einschränkungen bereits überprüft haben, finden Sie hier einige Möglichkeiten zur Problembehandlung mit dem Datenpfad und der Konnektivität:

Problembehandlung bei effektiven Routen:
- Wenn private Routingrichtlinien konfiguriert sind, sollten Routen mit Firewall des nächsten Hops in den effektiven Routen der defaultRouteTable für RFC1918-Aggregate (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) sowie alle im Textfeld für privaten Datenverkehr angegebenen Präfixe angezeigt werden. Stellen Sie sicher, dass alle Virtual Network- und lokalen Präfixe Subnetze innerhalb der statischen Routen in der defaultRouteTable sind. Wenn ein lokales Netzwerk oder Virtual Network einen Adressraum verwendet, der kein Subnetz innerhalb der effektiven Routen in der defaultRouteTable ist, fügen Sie das Präfix in das Textfeld für privaten Datenverkehr ein.
- Wenn Routingrichtlinien für Internetdatenverkehr konfiguriert sind, sollten Sie eine Standardroute (0.0.0.0/0) in den effektiven Routen der defaultRouteTable sehen.
- Nachdem Sie überprüft haben, ob die effektiven Routen der defaultRouteTable die richtigen Präfixe haben, sehen Sie sich die effektiven Routen des virtuellen Netzwerkgeräts oder von Azure Firewall an. Effektive Routen auf der Firewall zeigen an, welche Routen Virtual WAN ausgewählt hat, und bestimmt, an welche Ziele die Firewall Pakete weiterleiten kann. Wenn Sie herausfinden, welche Präfixe fehlen oder sich in einem falschen Zustand befinden, können Sie Datenpfadprobleme eingrenzen und auf die richtige VPN-, ExpressRoute-, NVA- oder BGP-Verbindung für die Problembehandlung verweisen.
Szenariospezifische Problembehandlung:
- Wenn Sie einen nicht gesicherten Hub (Hub ohne Azure Firewall oder NVA) in Ihrem Virtual WAN haben, stellen Sie sicher, dass Verbindungen mit dem nicht gesicherten Hub an die defaultRouteTable-Tabelle der Hubs mit konfigurierter Routingabsicht weitergegeben werden. Wenn Weitergaben nicht auf die defaultRouteTable festgelegt sind, können Verbindungen mit dem gesicherten Hub keine Pakete an den nicht gesicherten Hub senden.
- Wenn Sie Internetroutingrichtlinien konfiguriert haben, stellen Sie sicher, dass die Einstellungen „Standardroute weitergeben“ oder „Internetsicherheit aktivieren“ für alle Verbindungen, welche die Standardroute 0.0.0.0/0 lernen sollen, auf WAHR festgelegt ist. Verbindungen, bei denen diese Einstellung auf FALSCH festgelegt ist, werden die Route 0.0.0.0/0 nicht erlernen, selbst wenn Internetroutingrichtlinien konfiguriert sind.
- Wenn Sie private Endpunkte verwenden, die in virtuellen Netzwerken bereitgestellt werden, die mit dem virtuellen Hub verbunden sind, umgeht der von lokalen Endpunkten kommende Datenverkehr, der für private Endpunkte in virtuellen Netzwerken bestimmt ist, die mit dem Virtual WAN-Hub verbunden sind, standardmäßig die Routingabsicht der Azure Firewall des nächsten Hops, des NVA oder SaaS. Dies führt jedoch zu einem asymmetrischen Routing (was zu Konnektivitätsverlusten zwischen lokalen und privaten Endpunkten führen kann), da private Endpunkte in virtuellen Spoke-Netzwerken lokalen Datenverkehr an die Firewall weiterleiten. Um die Routingsymmetrie sicherzustellen, aktivieren Sie Routingtabellen-Netzwerkrichtlinien für private Endpunkte in den Subnetzen, in denen private Endpunkte bereitgestellt werden. Die Konfiguration von /32-Routen, die privaten IP-Adressen des privaten Endpunkts im Textfeld „Privater Datenverkehr“ entsprechen, gewährleistet keine Datenverkehrssymmetrie, wenn auf dem Hub Richtlinien für privates Routing konfiguriert sind.
- Wenn Sie eine verschlüsselte ExpressRoute-Instanz mit privaten Routingrichtlinien verwenden, stellen Sie sicher, dass auf Ihrem Firewallgerät eine Regel konfiguriert ist, um Datenverkehr zwischen dem privaten IP-Tunnelendpunkt des Virtual WAN-Site-to-Site-VPN-Gateways und dem lokalen VPN-Gerät zuzulassen. ESP-Pakete (verschlüsselte äußere Pakete) sollten in Azure Firewall-Protokollen protokolliert werden. Weitere Informationen zu verschlüsselten ExpressRoute-Instanzen mit Routingabsicht finden Sie in der Dokumentation zu verschlüsselten ExpressRoute-Instanzen.

Problembehandlung bei Azure Firewall-Routingproblemen

Stellen Sie sicher, dass der Bereitstellungsstatus der Azure Firewall erfolgreich ist, bevor Sie versuchen, die Routingabsicht zu konfigurieren.
Wenn Sie in Ihren Branches/virtuellen Netzwerken Präfixe verwenden, die nicht IANA RFC1918 entsprechen, müssen Sie diese Präfixe im Textfeld „Private Präfixe“ angeben. Konfigurierte privaten Präfixe werden nicht automatisch an andere Hubs in der Virtual WAN-Instanz weitergegeben, die mit Routingabsicht konfiguriert wurde. Zum Sicherstellen der Konnektivität fügen Sie diese Präfixe dem Textfeld „Private Präfixe“ in jedem einzelnen Hub mit Routingabsicht hinzu.
Wenn Sie Nicht-RFC1918-Adressen als Teil des Textfelds Präfixe für privaten Datenverkehr in Firewall Manager angegeben haben, müssen Sie möglicherweise SNAT-Richtlinien für Ihre Firewall konfigurieren, um SNAT für nicht RFC1918 entsprechenden privaten Datenverkehr zu deaktivieren. Weitere Informationen finden Sie unter SNAT-Bereiche von Azure Firewall.
Konfigurieren und anzeigen der Azure Firewall-Protokolle, um die Problembehandlung und Analyse Ihres Netzwerkdatenverkehrs zu unterstützen. Weitere Informationen zur Einrichtung der Überwachung für Azure Firewall finden Sie unter Azure Firewall-Diagnosen. Eine Übersicht über die verschiedenen Arten von Firewallprotokollen finden Sie unter Azure Firewall-Protokolle und -Metriken.
Weitere Informationen zu Azure Firewall finden Sie in der Azure Firewall-Dokumentation.

Behandeln von Problemen mit virtuellen Netzwerkappliances

Stellen Sie sicher, dass der Bereitstellungsstatus des virtuellen Netzwerkgeräts erfolgreich ist, bevor Sie versuchen, die Routingabsicht zu konfigurieren.
Wenn Sie in Ihren lokal verbundenen oder virtuellen Netzwerken Präfixe verwenden, die nicht IANA RFC1918 entsprechen, müssen Sie diese Präfixe im Textfeld „Private Präfixe“ angeben. Konfigurierte privaten Präfixe werden nicht automatisch an andere Hubs in der Virtual WAN-Instanz weitergegeben, die mit Routingabsicht konfiguriert wurde. Zum Sicherstellen der Konnektivität fügen Sie diese Präfixe dem Textfeld „Private Präfixe“ in jedem einzelnen Hub mit Routingabsicht hinzu.
Wenn Sie Nicht-RFC1918-Adressen als Teil des Textfelds Präfixe für privaten Datenverkehr angegeben haben, müssen Sie möglicherweise SNAT-Richtlinien auf Ihrem NVA konfigurieren, um SNAT für bestimmten nicht RFC1918 entsprechenden privaten Datenverkehr zu deaktivieren.
Überprüfen Sie die NVA-Firewallprotokolle, um festzustellen, ob Datenverkehr von Ihren Firewallregeln gelöscht oder verweigert wird.
Wenden Sie sich an Ihren NVA-Anbieter, um weitere Unterstützung und Anleitungen zur Problembehandlung zu erhalten.

Problembehandlung für Software-as-a-Service

Stellen Sie sicher, dass der Bereitstellungsstatus der SaaS-Lösung erfolgreich ist, bevor Sie versuchen, die Routingabsicht zu konfigurieren.
Weitere Tipps zur Problembehandlung finden Sie im Abschnitt zur Problembehandlung in der Virtual WAN-Dokumentation oder in der NGFW-Dokumentation der Palo Alto Networks-Cloud.

Nächste Schritte

Weitere Informationen zum Routing für virtuelle Hubs finden Sie unter Informationen zum Routing virtueller Hubs. Weitere Informationen zu Virtual WAN finden Sie unter Häufig gestellte Fragen.

Freigeben über

Konfigurieren von Routingabsichten und Routingrichtlinien für den Virtual WAN-Hub

Hintergrund

Anwendungsfälle

Alle Virtual WAN-Hubs sind gesichert (bereitgestellt mit Azure Firewall, einem NVA oder einer SaaS-Lösung)

Bereitstellung sowohl gesicherter als auch regulärer Virtual WAN-Hubs

Bekannte Einschränkungen

Grenzwerte für den Adressraum des virtuellen Netzwerks

Überlegungen

Voraussetzungen

Rollbackstrategie

Statische Routen in defaultRouteTable

Azure Firewall Manager und Virtual WAN-Hubportal

Andere Methoden (PowerShell, REST, CLI)

Präfixankündigung für lokale Umgebungen

Internetroutingrichtlinie

Richtlinie für privates Routing

Wichtige Routingszenarien

Transitkonnektivität zwischen ExpressRoute-Leitungen mit Routingabsicht

Routingüberlegungen mit ExpressRoute

Verschlüsseltes ExpressRoute

Leistung für verschlüsselte ExpressRoute

Direkte Weiterleitung an NVA-Instanzen für Dual-Role-Konnektivität und Firewall-NVAs

Konfigurieren der Routingabsicht über das Azure-Portal

Konfigurieren von Routingabsichten und Routingrichtlinien über Azure Firewall Manager

Konfigurieren von Routingabsichten und Routingrichtlinien über das Virtual WAN-Portal

Konfigurieren der Routingabsicht mithilfe einer BICEP-Vorlage

Problembehandlung

Effektive Routen

Problembehandlung von Konfigurationsproblemen

Problembehandlung für den Datenpfad

Problembehandlung bei Azure Firewall-Routingproblemen

Behandeln von Problemen mit virtuellen Netzwerkappliances

Problembehandlung für Software-as-a-Service

Nächste Schritte

Feedback

Zusätzliche Ressourcen