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

  • Artikel

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 (Punkt-zu-Site-VPN, Site-zu-Site-VPN, ExpressRoute, Virtual Network und virtuelle Netzwerkgerät) Datenverkehr über ein Azure Firewall , virtuelles Firewall-Netzwerkgerät der nächsten Generation (NGFW-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 eine Routingrichtlinie für Internetdatenverkehr auf einem Virtual WAN-Hub konfiguriert ist, werden alle Branchverbindungen (Remote-VPN (Punkt-zu-Site-VPN), Site-zu-Site-VPN und ExpressRoute) und Virtual Network-Verbindungen mit diesem Virtual WAN-Hub den internetgebundenen Datenverkehr an die Azure Firewall, den Drittanbieter für Sicherheit, das virtuelle Netzwerkgerät oder die SaaS-Lösung weiterleiten, wie als Teil der Routingrichtlinie festgelegt.

    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.

Screenshot showing architecture with two secured hubs.

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.

Screenshot showing architecture with one secured hub one normal hub.

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

  • Die Routingabsicht ist derzeit in Azure public verfügbar. Microsoft Azure operated by 21Vianet und Azure Government befinden sich derzeit in der Entwicklungsphase.
  • Die Routingabsicht vereinfacht das Routing, indem Zuordnungen und Weitergaben in Routingtabellen für alle Verbindungen (Virtual Network, Site-zu-Site-VPN, Punkt-zu-Punkt-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.
    • 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.
    • 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.

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

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.

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.

Screenshot showing VPN site on-premises device tunnel IP address.

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

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 die umfassende Paketüberprüfung für Datenverkehr zwischen den Endpunkten des VPN-Tunnels. 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.

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

  1. Navigieren Sie zu dem Virtual WAN-Hub, für den Sie Routingrichtlinien konfigurieren möchten.

  2. 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. Screenshot showing how to modify secured hub settings.

  3. Wählen Sie im Menü den Hub aus, für den Sie Ihre Routingrichtlinien konfigurieren möchten.

  4. Wählen Sie Sicherheitskonfiguration unter Einstellungen aus.

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

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

    Screenshot showing how to configure routing policies.

  7. 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 Fertig aus.

    Screenshot showing how to edit private traffic prefixes.

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

  9. Wählen Sie Speichern aus.

  10. Wiederholen Sie die Schritte 2 bis 8 für andere geschützte Virtual WAN-Hubs, für die Sie Routingrichtlinien konfigurieren möchten.

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

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

  2. Unter Routing die Option Routingrichtlinien auswählen.

    Screenshot showing how to navigate to routing policies.

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

    Screenshot showing how to configure NVA private routing policies.

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

    Screenshot showing how to configure additional private prefixes for NVA routing policies.

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

    Screenshot showing how to configure public routing policies for NVA.

  6. Zum Anwenden Ihrer Routingabsicht- und Routing-Richtlinienkonfiguration auf Speichern klicken.

    Screenshot showing how to save routing policies configurations.

  7. Wiederholen Sie dies für alle Hubs, für die Sie Routing-Richtlinien konfigurieren möchten.

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

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.

Screenshot showing effective routes for defaultRouteTable.

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.

Screenshot showing effective routes for Azure Firewall.

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

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.