Verwenden eines Azure-VMware-Lösungsdesigns mit einer Region, das keine Global Reach hat
In diesem Artikel werden bewährte Methoden für die Azure-VMware-Lösung in einer einzelnen Region beschrieben, wenn Sie sicheres Azure Virtual WAN mit Routingabsicht verwenden. Es bietet Empfehlungen für Konnektivität und Datenverkehrsfluss für sicheres Virtual WAN mit Routingabsicht. In diesem Artikel wird die Topologie für Designs in privaten Azure VMware-Lösung-Clouds, lokalen Websites und Azure-nativen Ressourcen beschrieben, wenn Sie Azure ExpressRoute Global Reach nicht verwenden. Die Implementierung und Konfiguration eines sicheren Virtual WAN mit Routingabsicht geht über den Umfang dieses Artikels hinaus.
Wenn Sie eine Region verwenden, die keine Global Reach unterstützt oder wenn Sie über eine Sicherheitsanforderung verfügen, um den Datenverkehr zwischen Azure-VMware-Lösung und lokaler Umgebung in der Hubfirewall zu prüfen, müssen Sie ein Supportticket öffnen, um die ExpressRoute-zu-ExpressRoute-Transitivität zu aktivieren. Virtual WAN unterstützt die Transitivität von ExpressRoute-zu-ExpressRoute standardmäßig nicht. Weitere Informationen finden Sie unter Transitkonnektivität zwischen ExpressRoute-Schaltungen mit Routingabsicht.
Sicheres Virtual WAN ohne Global Reach verwenden
Nur die Virtual WAN-Standard-SKU unterstützt sicheres Virtual WAN mit Routingabsicht. Verwenden Sie sicheres Virtual WAN mit Routing, um den gesamten Internetdatenverkehr und privaten Netzwerkdatenverkehr (RFC 1918) an eine Sicherheitslösung wie Azure Firewall, eine nicht von Microsoft stammende virtuelle Nezwerkappliance (NVA) oder eine SaaS-Lösung (Software as a Service) zu senden.
Der Hub dieses Szenarios hat die folgende Konfiguration:
Das Netzwerk mit einer einzelnen Region verfügt über eine virtuelle WAN-Instanz und einen Hub.
Der Hub verfügt über eine Azure Firewall-Instanz, die es zu einem sicheren Virtual WAN-Hub macht.
Der sichere Virtual WAN-Hub hat Routingabsichten aktiviert.
Dieses Szenario enthält auch die folgenden Komponenten:
Eine einzelne Region verfügt über eine eigene private Azure-VMware-Lösung-Cloud und ein virtuelles Azure-Netzwerk.
Ein lokaler Standort stellt eine Verbindung mit dem Hub her.
Hinweis
Wenn Sie Nicht-RFC 1918-Präfixe in Ihren verbundenen lokalen Ressourcen, virtuellen Netzwerken oder Azure-VMware-Lösung verwenden, geben Sie diese Präfixe im Feld Private Datenverkehrspräfixe des Routingabsichtsfeatures an. Geben Sie zusammengefasste Routen in das Feld Private Datenverkehrspräfixe ein, um Ihren Bereich abzudecken. Geben Sie nicht den genauen Bereich ein, der Virtual WAN angibt, da diese Spezifikation zu Routingproblemen führen kann. Wenn der ExpressRoute-Schaltkreis beispielsweise den Wert 192.0.2.0/24 von der lokalen Bereitstellung angibt, geben Sie einen /23 Classless Inter-Domain Routing (CIDR)-Bereich oder größer ein, z. B. 192.0.2.0/23. Weitere Informationen finden Sie unter Konfigurieren von Routingabsichten und -richtlinien über das Virtual WAN-Portal.
Hinweis
Wenn Sie Azure-VMware-Lösung mit sicheren VIrtual WAN-Hubs konfigurieren, legen Sie die Einstellungsoption Hubrouting auf "AS Path " fest, um optimale Routingergebnisse auf dem Hub sicherzustellen. Weitere Informationen finden Sie unter Routingpräferenz für virtuelle Hubs.
Die folgende Diagramm zeigt ein Beispiel für dieses Szenario:
In der folgenden Tabelle werden die Topologiekonnektivität im vorherigen Diagramm beschrieben.
| Verbindung | Beschreibung |
|---|---|
| D | Private, cloudverwaltete ExpressRoute-Verbindung zum Hub von Azure-VMware-Lösung |
| E | Lokale ExpressRoute-Verbindung zum Hub |
Datenverkehrsflüsse für Virtual WAN mit einer Region ohne Global Reach
In den folgenden Abschnitten werden Datenverkehrsflüsse und Konnektivität für Azure-VMware-Lösun, lokale Umgebungen, virtuelle Azure-Netzwerke und das Internet beschrieben.
Konnektivität und Datenverkehrsflüsse in der privaten Azure-VMware-Lösung-Cloud
Das folgende Diagramm zeigt Datenverkehrsflüsse für eine private Azure-VMware-Lösung-Cloud.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 1 | Azure-VMware-Lösung-Cloud | Virtuelles Netzwerk | Ja |
| 2 | Azure-VMware-Lösung-Cloud | Lokal | Ja |
Die private Azure-VMware Lösung-Cloud verfügt über eine ExpressRoute-Verbindung mit dem Hub (Verbindung D).
Wenn Sie ExpressRoute-zu-ExpressRoute-Transitivität auf dem sicheren Hub aktivieren und Routingabsicht aktivieren, sendet der sichere Hub die standardmäßigen RFC 1918-Adressen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) über die Verbindung D an Azure-VMware-Lösung. Zusätzlich zu den standardmäßigen RFC 1918-Adressen erfahren Azure-VMware-Lösung spezifischere Routen von virtuellen Azure-Netzwerken und Zweignetzwerken, z. B. S2S VPN, P2S VPN und SD-WAN, die eine Verbindung mit dem Hub herstellen. Azure-VMware-Lösung lernt keine spezifischen Routen aus lokalen Netzwerken. Um Den Datenverkehr zurück zu lokalen Netzwerken zu leiten, verwendet Azure-VMware-Lösung die standardmäßigen RFC 1918-Adressen, die es von der Verbindung D lernt. Dieser Datenverkehr wird durch die Hubfirewall weitergeleitet. Die Hubfirewall verwendet die spezifischen Routen für lokale Netzwerke, um den Datenverkehr über die Verbindung E an die Ziele weiterzuleiten. Datenverkehr, der von Azure-VMware-Lösung an virtuelle Netzwerke geht, durchläuft die Hub-Firewall.
Lokale Konnektivität und Datenverkehrsfluss
Das folgende Diagramm zeigt Datenverkehrsflüsse für die lokale Konnektivität.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 3 | Lokal | Azure-VMware-Lösung-Cloud | Ja |
| 4 | Lokal | Virtuelles Netzwerk | Ja |
Der lokale Standort stellt über ExpressRoute-Verbindung E eine Verbindung zum Hub her.
Wenn Sie die Transitivität von ExpressRoute zu ExpressRoute auf dem sicheren Hub aktivieren und die Routingabsicht aktivieren, sendet der sichere Hub die Standard-RFC-1918-Adressen über die VerbindungE an die lokale Adresse. Zusätzlich zu den standardmäßigen RFC 1918-Adressen lernt die lokale Umgebung spezifischere Routen von virtuellen Azure-Netzwerken und Zweigstellennetzwerken, die eine Verbindung zum Hub herstellen. Vor Ort werden keine spezifischen Routen aus Azure-VMware-Lösung gelernt. Um den Datenverkehr zurück zu Azure-WMware-Lösung-Netzwerken zu leiten, verwendet Azure-VMware-Lösung die standardmäßigen RFC 1918-Adressen, die es von der Verbindung E lernt. Dieser Datenverkehr wird durch die Hubfirewall weitergeleitet. Die Hubfirewall verwendet die spezifischen Routen für Azure-WMware-Lösung-Netzwerke, um den Datenverkehr über die Verbindung D an die Ziele weiterzuleiten. Der Datenverkehr vom lokalen Netzwerk zu virtuellen Netzwerken durchläuft die Hub-Firewall.
Wenn Sie die ExpressRoute-zu-ExpressRoute-Transitivität auf dem Hub aktivieren, sendet sie die standardmäßigen RFC 1918-Adressen an Ihr lokales Netzwerk. Daher sollten Sie nicht die genauen RFC 1918-Präfixe zurück zu Azure bewerben. Die Werbung für dieselben genauen Routen verursacht Routingprobleme innerhalb von Azure. Stattdessen sollten Sie spezifischere Routen zurück zu Azure für Ihre lokalen Netzwerke bewerben.
Hinweis
Wenn Sie die standardmäßigen RFC 1918-Adressen von der lokalen Bereitstellung zu Azure bewerben und diese Vorgehensweise fortsetzen möchten, müssen Sie jeden RFC 1918-Bereich in zwei gleiche Unterbereiche aufteilen und diese Unterbereiche wieder in Azure bewerben. Die Unterbereiche sind 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17 und 192.168.128.0/17.
Konnektivität und Datenverkehrsfluss des virtuellen Azure-Netzwerks
Das folgende Diagramm zeigt den Datenverkehr für die virtuelle Azure-Netzwerkkonnektivität.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 5 | Virtuelles Netzwerk | Azure-VMware-Lösung-Cloud | Ja |
| 6 | Virtuelles Netzwerk | Lokal | Ja |
In diesem Szenario werden die virtuellen Netzwerkspeers direkt an den Hub übertragen. Das Diagramm zeigt, wie Azure-native Ressourcen im virtuellen Netzwerk ihre Routen lernen. Ein sicherer Hub mit aktivierter Routingabsicht sendet die standardmäßigen RFC 1918-Adressen an virtuelle Peer-Netzwerke. Azure-native Ressourcen im virtuellen Netzwerk lernen keine spezifischen Routen von außerhalb ihres virtuellen Netzwerks kennen. Wenn Sie die Routingabsicht aktivieren, verfügen alle Ressourcen im virtuellen Netzwerk über die Standardadresse RFC 1918 und verwenden die Hub-Firewall als nächsten Hop. Der gesamte Datenverkehr, der in die virtuellen Netzwerke wechselt und beendet, übergibt die Hubfirewall.
Internetkonnektivität
In diesem Abschnitt wird beschrieben, wie Sie eine Internetverbindung für Azure-native Ressourcen in virtuellen Netzwerken und private Azure-VMware-Lösung-Clouds in einer Region bereitstellen. Weitere Informationen finden Sie unter Überlegungen zur Gestaltung von Internetkonnektivität. Sie können die folgenden Optionen verwenden, um eine Internetverbindung mit Azure-VMware-Lösung bereitzustellen.
- Option 1: In Azure gehosteter Internetdienst
- Option 2: Von Azure-VMware-Lösung verwaltete Source Network Address Translation (SNAT)
- Option 3: Öffentliche IPv4-Adresse von Azure für den NSX-T Data Center Edge
Ein sicheres Virtual WAN-Design mit einer Region mit Routingabsicht unterstützt alle Optionen, wir empfehlen jedoch Option 1. Das Szenario weiter unten in diesem Artikel verwendet Option 1, um eine Internetverbindung bereitzustellen. Option 1 eignet sich am besten für sicheres Virtual WAN, da es einfach zu prüfen, bereitzustellen und zu verwalten ist.
Wenn Sie die Routingabsicht für den sicheren Hub aktivieren, wird RFC 1918 für alle virtuellen Peernetzwerke angekündigt. Sie können aber auch eine Standardroute 0.0.0.0/0 für die Internetverbindung mit nachgelagerten Ressourcen ankündigen. Wenn Sie Routingabsicht verwenden, können Sie eine Standardroute aus der Hubfirewall generieren. Diese Standardroute kündigt Ihr virtuelles Netzwerk und Azure-VMware-Lösung an.
Azure-VMware-Lösung und virtuelle Netzwerk-Internetkonnektivität
Wenn Sie die Routingabsicht für Internetdatenverkehr aktivieren, wird standardmäßig der sichere Virtual WAN-Hub nicht für die Standardroute über ExpressRoute-Schaltkreise angekündigt. Um sicherzustellen, dass die Standardroute vom Virtual WAN an Azure-VMware-Lösung weitergegeben wird, müssen Sie die Standardroutenweiterleitung in Ihren Azure-VMware-Lösung ExpressRoute-Schaltkreisen aktivieren. Weitere Informationen finden Sie unter Standardroute 0.0.0.0/0 an Endpunkte bekannt geben.
Das folgende Diagramm zeigt Datenverkehrsflüsse für virtuelle Netzwerke und Azure-VMware-Lösung-Internetverbindung.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 7 | Virtuelles Netzwerk | Dem Internet | Ja |
| 8 | Azure-VMware-Lösung-Cloud | Dem Internet | Ja |
Nachdem Sie die Standardroutenverteilung aktiviert haben, kündigt die Verbindung D die Standardroute 0.0.0.0/0 vom Hub an. Aktivieren Sie diese Einstellung nicht für lokale ExpressRoute-Schaltkreise. Es wird empfohlen, einen BGP-Filter (Border Gateway Protocol) auf Ihrem lokalen Gerät zu implementieren. Ein BGP-Filter verhindert, dass Ressourcen versehentlich die Standardroute lernen, eine zusätzliche Vorsichtsebene hinzufügen und sicherstellen können, dass Ihre Konfiguration sich nicht auf die lokale Internetverbindung auswirkt.
Wenn Sie die Routingabsicht für den Internetzugriff aktivieren, wird die vom sicheren Virtual WAN-Hub generierte Standardroute automatisch den über den Hub verbundenen virtuellen Netzwerkverbindungen bekannt gegeben. Beachten Sie, dass in den NICs der virtuellen Maschinen im virtuellen Netzwerk der nächste Hop 0.0.0.0/0 die Hubfirewall ist. Um den nächsten Hop zu finden, wählen Sie Effektive Routen in der NIC aus.
Verwenden von VMware HCX Mobility Optimized Networking (MON) ohne Global Reach
Sie können HCX Mobility Optimized Networking (MON) aktivieren, wenn Sie HCX-Netzwerkerweiterung verwenden. MON bietet in bestimmten Szenarien ein optimales Routing des Datenverkehrs, um zu verhindern, dass sich Netzwerke überlappen oder Schleifen zwischen den lokalen und cloudbasierten Ressourcen in erweiterten Netzwerken durchlaufen.
Ausgehender Datenverkehr von Azure-VMware-Lösung
Wenn Sie MON für ein bestimmtes erweitertes Netzwerk und einen virtuellen Computer aktivieren, ändert sich der Datenverkehrsfluss. Nachdem Sie MON implementiert haben, wird der Datenverkehr vom virtuellen Computer nicht wieder in eine lokale Schleife zurückgesendet. Stattdessen wird der IPSec-Tunnel der Netzwerkerweiterung umgangen. Der Datenverkehr für die virtuelle Maschine verlässt das Azure-VMware-Lösung NSX-T Tier-1-Gateway, geht zum NSX-T Tier-0-Gateway und dann zum Virtual WAN.
Eingehender Datenverkehr zu Azure-VMware-Lösung
Wenn Sie MON für ein bestimmtes erweitertes Netzwerk und einen virtuellen Computer aktivieren, führen Sie die folgenden Änderungen ein. Von der Azure VMware-Lösung NSX-T fügt MON eine /32-Hostroute zurück zum Virtual WAN ein. Virtual WAN kündigt diese /32-Route zurück zu lokalen, virtuellen Netzwerken und Zweignetzwerken an. Diese /32-Hostroute stellt sicher, dass Datenverkehr von lokalen, virtuellen Netzwerken und Zweignetzwerken den IPSec-Tunnel der Netzwerkerweiterung nicht verwendet, wenn der Datenverkehr an den MON-fähigen virtuellen Computer wechselt. Der Datenverkehr aus Quellnetzwerken wechselt direkt zum MON-fähigen virtuellen Computer, da er die Route /32 lernt.
HCX MON-Einschränkung für sicheres Virtual WAN ohne Global Reach
Wenn Sie ExpressRoute-zu-ExpressRoute-Transitivität auf dem sicheren Hub aktivieren und Routingabsicht aktivieren, sendet der sichere Hub die standardmäßigen RFC 1918-Adressen an lokale und Azure-VMware-Lösung. Zusätzlich zu den standardmäßigen RFC 1918-Adressen erfahren sowohl lokale als auch Azure-VMware-Lösung spezifischere Routen von virtuellen Azure-Netzwerken und Zweignetzwerken, die eine Verbindung mit dem Hub herstellen.
Lokale Netzwerke lernen jedoch keine spezifischen Routen aus der Azure-VMware-Lösung kennen, und Die Azure-VMware-Lösung lernt keine spezifischen Routen aus lokalen Netzwerken. Stattdessen basieren beide Umgebungen auf den standardmäßigen RFC 1918-Adressen, um das Weiterleiten aneinander über die Hubfirewall zu erleichtern. Daher werden spezifischere Routen, z. B. MON-Hostrouten, nicht von Azure-VMware-Lösung ExpressRoute an den lokalen ExpressRoute-Schaltkreis angekündigt. Das Gegenteil ist auch der Fall. Die Unfähigkeit, bestimmte Routen zu erlernen, führt zu asymmetrischen Datenverkehrsflüssen. Der Datenverkehr verlässt die Azure-VMware-Lösung über das NSX-T Tier-0-Gateway, der lokale Datenverkehr kehrt jedoch über den Network Extension IPSec-Tunnel zurück.
Korrigieren der Datenverkehrsasymmetrie
Um die Datenverkehrsasymmetrie zu korrigieren, müssen Sie die MON-Richtlinienrouten anpassen. MON-Richtlinienrouten bestimmen, welcher Datenverkehr über eine L2-Erweiterung zum lokalen Gateway zurückgeht. Sie entscheiden auch, welcher Datenverkehr über das Azure-VMware-Lösung Tier-0-Gateway erfolgt.
Wenn eine Ziel-IP übereinstimmt und Sie sie in der MON-Richtlinienkonfiguration aufZulassen setzen, werden zwei Aktionen ausgeführt. Zunächst identifiziert das System das Paket. Zweitens sendet das System das Paket über die Netzwerkerweiterungs-Appliance an das lokale Gateway.
Wenn eine Ziel-IP nicht übereinstimmt oder Sie sie in der MON-Richtlinie auf Ablehnen setzen, sendet das System das Paket zum Routing an das Azure-VMware-Lösung Tier-0-Gateway.
In der folgenden Tabelle werden HCX-Richtlinienrouten beschrieben.
| Network | An Peer umleiten | Hinweis |
|---|---|---|
| Adressraum des virtuellen Azure-Netzwerks | Verweigern | Fügen Sie explizit die Adressbereiche für alle virtuellen Netzwerke ein. Datenverkehr, der für Azure vorgesehen ist, leitet ausgehend über die Azure-VMware-Lösung aus und kehrt nicht zum lokalen Netzwerk zurück. |
| Standardmäßige RFC 1918-Adressplätze | Zulassen | Fügen Sie die standardmäßigen RFC 1918-Adressen hinzu. Diese Konfiguration stellt sicher, dass jeder Datenverkehr, der nicht den vorherigen Kriterien entspricht, zurück zum lokalen Netzwerk umgeleitet wird. Wenn Ihr lokales Setup Adressen verwendet, die nicht Teil von RFC 1918 sind, müssen Sie diese Bereiche explizit einschließen. |
| Adressraum: 0.0.0.0/0 | Verweigern | Adressen, die RFC 1918 nicht abdecken, z. B. Internetroutable-IPs oder Datenverkehr, der nicht mit den angegebenen Einträgen übereinstimmt, beenden Sie direkt über die Azure-VMware-Lösung und leiten Sie nicht zurück zum lokalen Netzwerk. |