Verwenden eines Azure-VMware-Lösungsdesigns mit zwei Regionen, das keine Global Reach hat
In diesem Artikel werden die bewährten Methoden für Konnektivität, Datenverkehrsflüsse und hohe Verfügbarkeit beschrieben, wenn Sie Azure-VMware-Lösung in zwei Regionen bereitstellen und sicheres Virtual Azure-WAN mit Routingabsicht verwenden. Es bietet Anleitungen zur Verwendung dieses Designs ohne Global Reach. In diesem Artikel wird Virtual WAN mit Routingabsichtstopologie für private Azure-VMware-Lösung-Clouds, lokale Standorte und Azure-native Ressourcen beschrieben. 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.
Verwenden eines sicheren virtuellen WAN-Designs mit zwei Regionen ohne Global Reach
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 zwei Regionen verfügt über ein Virtual WAN-Instanz und zwei Hubs. Jede Region verfügt über einen Hub.
Jeder Hub verfügt über eine eigene Azure Firewall-Instanz, wodurch sie Virtual WAN-Hubs sicher machen.
Die sicheren Virtual WAN-Hubs haben Routingabsichten aktiviert.
Dieses Szenario enthält auch die folgenden Komponenten:
Jede Region verfügt über eine eigene private Azure-VMware-Lösung-Cloud und ein virtuelles Azure-Netzwerk.
Eine lokaler Standort stellt eine Verbindung mit beiden Regionen bereit.
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 Azure 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 Cloud-Verbindung mit Azure-VMware-Lösung mit seinem lokalen regionalen Hub |
| E | Lokale Konnektivität über ExpressRoute zu beiden regionalen Hubs |
| Interhub | Logische Interhub-Verbindung zwischen zwei Hubs, die unter demselben Virtual WAN bereitgestellt werden |
Sicherer Virtual WAN-Datenverkehrsflüsse in zwei Regionen
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 private Azure-VMware-Lösung-Clouds.
In der folgenden Tabelle werden die Topologiekonnektivität im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 1 | Azure-VMware-Lösung-Cloud Region 1 | Virtuelles Netzwerk 1 | Ja, über die Hub 1-Firewall |
| 2 | Azure-VMware-Lösung-Cloud Region 1 | Lokal | Ja, über die Hub 1-Firewall |
| 3 | Azure-VMware-Lösung-Cloud Region 1 | Virtuelles Netzwerk 2 | Ja, über die Hub 1-Firewall und dann über die Hub 2-Firewall |
| 4 | Azure-VMware-Lösung-Cloud Region 1 | Azure-VMware-Lösung-Cloud Region 2 | Ja, über die Hub 1-Firewall und dann über die Hub 2-Firewall |
| 5 | Azure-VMware-Lösung-Cloud Region 2 | Virtuelles Netzwerk 1 | Ja, über die Hub 2-Firewall und dann über die Hub 1-Firewall |
| 6 | Azure-VMware-Lösung-Cloud Region 2 | Virtuelles Netzwerk 2 | Ja, über die Hub 2-Firewall |
| 7 | Azure-VMware-Lösung-Cloud Region 2 | Lokal | Ja, über die Hub 2-Firewall |
Jede private Azure VMware-Lösung-Cloud stellt über ExpressRoute-Verbindung D eine Verbindung mit dem Hub bereit.
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 beiden Hubs herstellen. Beide private Azure-VMware-Lösung-Clouds lernen keine spezifischen Routen aus lokalen Netzwerken kennen.
Um den Datenverkehr zurück zu lokalen Netzwerken zu leiten, verwendet Azure-VMware-Lösung die standardmäßigen RFC 1918-Adressen, die er über die Verbindung D vom lokalen regionalen Hub lernt. Dieser Datenverkehr wird durch die lokale regionale 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 einer privaten Azure-VMware-Lösung-Cloud zu virtuellen Netzwerken wechselt, übergibt die Hubfirewall.
Lokale Konnektivität und Datenverkehrsfluss
Das folgende Diagramm zeigt Datenverkehrsflüsse für die lokale Konnektivität.
In der folgenden Tabelle werden die Topologiekonnektivität im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 2 | Lokal | Azure-VMware-Lösung-Cloud Region 1 | Ja, über die Hub 1-Firewall |
| 7 | Lokal | Azure-VMware-Lösung-Cloud Region 2 | Ja, über die Hub 2-Firewall |
| 8 | Lokal | Virtuelles Netzwerk 1 | Ja, über die Hub 1-Firewall |
| 9 | Lokal | Virtuelles Netzwerk 2 | Ja, über die Hub 2-Firewall |
Der lokale Standort stellt über ExpressRoute-Verbindung E eine Verbindung zu beiden Hubs her.
Wenn Sie die ExpressRoute-zu-ExpressRoute-Transitivität für sichere Hubs aktivieren und Routingabsichten aktivieren, sendet jeder sichere Hub die standardmäßigen RFC 1918-Adressen (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) über die lokale Verbindung E. Zusätzlich zu den standardmäßigen RFC 1918-Adressen erfahren Lokale spezifischere Routen von virtuellen Azure-Netzwerken und Zweignetzwerken, z. B. S2S VPN, P2S VPN und SD-WAN, die eine Verbindung mit beiden Hubs herstellen.
Lokal werden die spezifischen Routen für private Azure-VMware-Lösung-Clouds nicht gelernt. Lokal lernen die standardmäßigen RFC 1918-Adressen von beiden Hubs über die Verbindung E kennen. Lokale Routen an private Azure-VMware-Lösung-Clouds über die standardmäßigen RFC 1918-Adressen, die sie über die Verbindung E lernen.
Hinweis
Sie müssen auf beiden Hubs bestimmte Routen hinzufügen. Wenn Sie keine bestimmten Routen auf den Hubs hinzufügen, können Sie suboptimales Routing einführen, da lokal das Routing mit gleichen Kosten (Multi-Path, ECMP) zwischen den E-Verbindungen für Datenverkehr verwendet wird, der an eine private Azure-VMware-Lösung-Cloud geleitet wird. Daher kann Datenverkehr zwischen der lokalen und einer privaten Azure-VMware-Lösung-Cloud Latenz, Leistungsprobleme oder Paketverluste auftreten.
Wenn Sie eine spezifischere Route an die lokale Bereitstellung ankündigen möchten, geben Sie diese Präfixe im Feld Private Datenverkehrspräfixe des Routingabsichtsfeatures an. Weitere Informationen finden Sie unter Konfigurieren von Routingabsichten und -richtlinien über das Virtual WAN-Portal. Sie müssen eine zusammengefasste Route hinzufügen, die sowohl Ihren Azure-VMware-Lösung /22-Block als auch Ihre Azure-VMware-Lösung-Subnetze umfasst. Wenn Sie dasselbe Präfix oder ein spezifisches Präfix anstelle einer Zusammenfassungsroute hinzufügen, führen Sie Routingprobleme in der Azure-Umgebung ein. Fügen Sie nur zusammengefasste Routen in das Feld Private Datenverkehrspräfixe ein.
Wie im Diagramm dargestellt, umfasst die private Azure-VMware-Lösung Cloud 1 Workload-Subnetze von 10.10.0.0/24 bis 10.10.7.0/24. Auf Hub 1 wird die Zusammenfassungsroute 10.10.0.0/21 zu privaten Verkehrspräfixen hinzugefügt, da sie alle acht Subnetze umfasst. Darüber hinaus wird auf Hub 1 die Zusammenfassungsroute 10.150.0.0/22 zu privaten Datenverkehrspräfixen hinzugefügt, um den Azure-VMware-Lösung Management-Block abzudecken. Zusammenfassungsrouten 10.10.0.0/21 und 10.150.0.0/22 werden über die Verbindung E vor Ort angekündigt, sodass lokal eine spezifischere Route statt 10.0.0.0/8 vorhanden ist.
Die private Azure-VMware-Lösung Cloud 2 umfasst Workload-Subnetze von 10.20.0.0/24 bis 10.20.7.0/24. Auf Hub 2 wird die Zusammenfassungsroute 10.20.0.0/21 zu privaten Verkehrspräfixen hinzugefügt, da sie alle acht Subnetze umfasst. Darüber hinaus wird auf Hub 2 die Zusammenfassungsroute 10.250.0.0/22 zu privaten Datenverkehrspräfixen hinzugefügt, um den Azure-VMware-Lösung Management-Block abzudecken. Zusammenfassungsrouten 10.20.0.0/21 und 10.250.0.0/22 werden über die Verbindung E an lokale Standorte, sodass lokal eine spezifischere Route statt 10.0.0.0/8 vorhanden ist.
Sie können den gesamten Azure-VMware-Lösung-Management /22-Block im Feld Private Datenverkehrspräfixe hinzufügen, da Azure-VMware-Lösung den genauen /22-Block nicht zurück zu Azure ankündigen. Azure-VMware-Lösung kündigt spezifischere Routen an.
Wenn Sie die ExpressRoute-zu-ExpressRoute-Transitivität auf dem Hub aktivieren, sendet sie die standardmäßigen RFC 1918-Adressen an Ihr lokales Netzwerk. Geben Sie nicht die genauen RFC 1918-Präfixe zurück zu Azure an. Die gleichen genauen Routen können Routingprobleme in Azure verursachen. 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 Datenverkehrsflüsse für Azure virtuellen Netzwerke.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 1 | Virtuelles Netzwerk 1 | Azure-VMware-Lösung-Cloud Region 1 | Ja, über die Hub 1-Firewall |
| 3 | Virtuelles Netzwerk 2 | Azure-VMware-Lösung-Cloud Region 1 | Ja, über die Hub 2-Firewall und dann über die Hub 1-Firewall |
| 5 | Virtuelles Netzwerk 1 | Azure-VMware-Lösung-Cloud Region 2 | Ja, über die Hub 1-Firewall, dann über die Hub 2-Firewall |
| 6 | Virtuelles Netzwerk 2 | Azure-VMware-Lösung-Cloud Region 2 | Ja, über die Hub 2-Firewall |
| 8 | Virtuelles Netzwerk 1 | Lokal | Ja, über die Hub 1-Firewall |
| 9 | Virtuelles Netzwerk 2 | Lokal | Ja, über die Hub 2-Firewall |
| 10 | Virtuelles Netzwerk 1 | Virtuelles Netzwerk 2 | Ja, über die Hub 1-Firewall und dann über die Hub 2-Firewall |
| 10 | Virtuelles Netzwerk 2 | Virtuelles Netzwerk 1 | Ja, über die Hub 2-Firewall und dann über die Hub 1-Firewall |
Jedes virtuelle Netzwerk ist direkt mit seinem regionalen Hub verbunden.
Das Diagramm zeigt, wie alle Azure-nativen Ressourcen in beiden virtuellen Netzwerken ihre effektiven Routen lernen. Wenn Sie Routingabsicht aktivieren, senden Hub 1 und Hub 2 die standardmäßigen RFC 1918-Adressen an ihre virtuellen Peering-Netzwerke. Azure-native Ressourcen in den virtuellen Netzwerken lernen keine spezifischen Routen von außerhalb ihres virtuellen Netzwerks kennen.
Wenn Sie Routingabsichten aktivieren, lernen alle Ressourcen im virtuellen Netzwerk die standardmäßige RFC 1918-Adresse kennen und verwenden ihre regionale Hubfirewall als nächsten Hop. Private Azure-VMware-Lösung-Clouds kommunizieren über die Verbindung D über ihre lokale regionale Hubfirewall miteinander. Von dort aus durchqueren sie den Virtual WAN-Interhub und werden an der standortübergreifenden Hubfirewall überprüft. Private Azure-VMware-Lösung-Clouds kommunizieren auch über die lokale Verbindung D über ihre lokale regionale Hubfirewall. Der gesamte Datenverkehr, der in die virtuellen Netzwerke ein- und aus ihnen austritt, durchläuft die Firewalls ihrer regionalen Hubs.
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 beiden Regionen 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 Virtual WAN-Design mit dualer 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 Routingabsichten für sichere Hubs aktivieren, wird RFC 1918 für direkt verbundene virtuelle Netzwerke 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 Routingabsichten aktivieren, können Sie eine Standardroute aus beiden Hubfirewalls generieren. Diese Standardroute kündigt ihre direkt verbundenen virtuellen Netzwerke und seine direkt verbundene Azure-VMware-Lösung an.
Azure-VMware-Lösung und virtuelle Netzwerk-Internetkonnektivität
Das folgende Diagramm zeigt Datenverkehrsflüsse für private Azure-VMware-Lösung-Clouds und virtuelle Netzwerke.
In der folgenden Tabelle wird der Datenverkehrsfluss im vorherigen Diagramm beschrieben.
| Datenverkehrsflussnummer | Quelle | Ziel | Prüft die sichere Virtual WAN-Hubfirewall diesen Datenverkehr? |
|---|---|---|---|
| 11 | Azure-VMware-Lösung-Cloud Region 1 | Dem Internet | Ja, über die Hub 1-Firewall |
| 12 | Virtuelles Netzwerk 2 | Dem Internet | Ja, über die Hub 2-Firewall |
| 13 | Virtuelles Netzwerk 1 | Dem Internet | Ja, über die Hub 1-Firewall |
| 14 | Azure-VMware-Lösung-Cloud Region 2 | Dem Internet | Ja, über die Hub 2-Firewall |
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 von Virtual WAN an die direkt verbundene Azure VMware-Lösung verteilt wird, müssen Sie die Verteilung der Standardroute auf Ihren Azure VMware-Lösung ExpressRoute-Schaltkreisen aktivieren. Weitere Informationen finden Sie unter Standardroute 0.0.0.0/0 an Endpunkte bekannt geben.
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, um das Lernen der Standardroute auszuschließen. Ein BGP-Filter fügt eine zusätzliche Schutzebene hinzu und stellt sicher, dass ihre Konfiguration sich nicht auf die lokale Internetverbindung auswirkt.
Wenn Sie die Routingabsicht für den Internetzugriff aktivieren, generieren beide regionalen Hubs eine Standardroute und geben diese an ihre Hub-Peer-virtuellen Netzwerkverbindungen bekannt. Beachten Sie, dass in den Netzwerkschnittstellenkarten (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. Die Standardroute wird nicht über den Interhub-Link über regionale Hubs angekündigt. Daher verwenden virtuelle Netzwerke ihren lokalen regionalen Hub für den Internetzugriff und verfügen nicht über eine Backup-Internetverbindung zum regionsübergreifenden Hub.
Ausfallsicherheit des Internetzugriffs für Azure-VMware-Lösung
Wenn Sie Global Reach nicht in einem Design mit zwei Regionen verwenden, verfügt die ausgehende Internetverbindung nicht über Redundanz, da jede private Azure VMware-Lösung-Cloud die Standardroute vom lokalen regionalen Hub lernt und nicht direkt mit seinem regionsübegreifenden Hub verbunden ist. Wenn sich ein regionaler Ausfall auf den lokalen regionalen Hub auswirkt, verwenden Sie eine der folgenden manuellen Konfigurationen, um Internetredundanz zu erzielen.
Option 1:
Verwenden Sie diese Option nur für ausgehenden Internetzugriff. Verwenden Sie während eines lokalen regionalen Ausfalls, wenn Sie ausgehenden Internetzugriff für Ihre Azure-VMware-Lösung Workload benötigen, Azure-VMware-Lösung verwalteten SNAT. Diese Lösung bietet einfachen und schnellen Zugriff. Weitere Informationen finden Sie unter Aktivieren von verwaltetem SNAT für Azure-VMware-Lösung-Workloads.
Option 2:
Verwenden Sie diese Option für den eingehenden und ausgehenden Internetzugriff. Wenn Sie während eines lokalen regionalen Ausfalls sowohl eingehenden als auch ausgehenden Internetzugriff für Ihre Azure-VMware-Lösung-Cloud benötigen, verwenden Sie die folgende Methode.
Entfernen Sie die Verbindung, die von Azure-VMware-Lösung zu Ihrem lokalen regionalen Hub (Verbindung D in den Diagrammen) wechselt.
Wählen Sie im Azure-Portal Azure-VMware-Lösung aus, und entfernen Sie den Autorisierungsschlüssel, den Sie für die Verbindung D erstellt haben.
Erstellen Sie eine neue Verbindung mit dem regionalen Hub.
Um eingehenden Datenverkehr zu verarbeiten, sollten Sie Azure Front Door oder Azure Traffic Manager verwenden, um regionale hohe Verfügbarkeit aufrechtzuerhalten.
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. |