Spoke-to-Spoke Netzwerke

Azure Firewall

Azure Virtual Network

Azure Virtual WAN

Azure VPN Gateway

Azure ExpressRoute

Bei den gängigsten Netzwerkdesignmustern in Azure werden virtuelle Hub-and-Spoke-Netzwerktopologien in einer oder mehreren Azure-Regionen erstellt, die optional über Azure ExpressRoute oder Site-to-Site-VPN-Tunnel (Virtual Private Network) über das öffentliche Internet mit lokalen Netzwerken verbunden sind.

Die meisten Entwurfsleitfäden konzentrieren sich auf den Anwendungsdatenverkehr zu diesen virtuellen Netzwerken von Benutzern entweder in internen, lokalen Netzwerken oder aus dem Internet (was die Branche normalerweise den Nord-Süd-Datenverkehr bezeichnet, da sie häufig durch vertikale Linien in Netzwerkdiagrammen dargestellt wird). Dieser Artikel befasst sich mit verschiedenen Mustern, die für den Ost-West-Verkehr verfügbar sind. Das heißt, die Kommunikation fließt zwischen Workloads, die in virtuellen Azure-Netzwerken bereitgestellt werden, entweder innerhalb einer Region oder in verschiedenen Regionen.

Um die Leistung, Skalierbarkeit und Ausfallsicherheit Ihrer Anwendungen, die in Azure ausgeführt werden, zu gewährleisten, müssen Sie sicherstellen, dass Ihr Netzwerk die Anforderungen für den Datenverkehr von Ost nach West erfüllt.

Mögliche Anwendungsfälle

Der Spoke-to-Spoke-Datenverkehr kann in verschiedenen Szenarien wichtig sein:

• Verschiedene Ebenen einer Anwendung befinden sich in separaten virtuellen Netzwerken. Beispielsweise kommunizieren Umkreisnetzwerkserver (auch als DMZ-Server bezeichnet) in einem Umkreis-virtuellen Netzwerk mit Anwendungsdiensten in einem internen virtuellen Netzwerk.
• Anwendungsworkloads in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) müssen Daten untereinander replizieren.
• Verschiedene Anwendungen oder Microservices müssen miteinander kommunizieren.
• Datenbanken müssen Daten überregional replizieren, um die Geschäftskontinuität im Falle eines Notfalls zu gewährleisten.
• Die Benutzer befinden sich in den virtuellen Azure-Netzwerken. Sie verwenden z. B. Azure Virtual Desktop.

Muster und Topologien für die Inter-Spoke-Kommunikation

Es gibt zwei Haupttopologien, die Sie in Azure-Designs verwenden können, die über mehrere virtuelle Netzwerke hinweg bestehen: selbstverwaltete Hubs und Speichen und Azure Virtual WAN. In einer virtuellen WAN-Umgebung verwaltet Microsoft die virtuellen Hubnetzwerke und alles darin. In einer selbstverwalteten Hub-and-Spoke-Umgebung verwalten Sie das virtuelle Hubnetzwerk.

Virtuelle WAN- und selbstverwaltete Hub- und Speichentopologien sind beispiele für Architekturen, in denen die Workloads in virtuellen Speichennetzwerken ausgeführt werden und die Konnektivität mit lokalen Netzwerken in einem virtuellen Hubnetzwerk zentralisiert wird. So viele der in diesem Artikel erläuterten Konzepte gelten sowohl für self-managed Hub-and-Spoke- als auch für virtuelle WAN-Designs.

Es gibt zwei Hauptmuster für die Verbindung von virtuellen Spoke-Netzwerken untereinander:

• Direkt miteinander verbundene Spoke-Instanzen. Peerings virtueller Netzwerke oder VPN-Tunnel werden zwischen den virtuellen Spoke-Netzwerken erstellt, um eine direkte Konnektivität zu ermöglichen, ohne das virtuelle Hubnetzwerk zu durchqueren.
• Spokes kommunizieren über ein Netzwerkgerät. Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zum Virtual WAN oder zu einem virtuellen Hubnetzwerk. Eine Appliance leitet den Datenverkehr von Spoke zu Spoke weiter. Die Appliance kann von Microsoft (wie bei Virtual WAN) oder von Ihnen selbst verwaltet werden.

Muster 1: Direkt miteinander verbundene Spoke-Instanzen.

Direkte Verbindungen zwischen Spokes bieten in der Regel einen besseren Durchsatz, eine kürzere Wartezeit und eine bessere Skalierbarkeit als Verbindungen, die über ein virtuelles Netzwerkgerät (NVA) über einen Hub verlaufen. Das Senden von Datenverkehr über NVAs kann zu zusätzlichen Wartezeiten führen, wenn die NVAs in einer anderen Verfügbarkeitszone liegen und mindestens zwei Peerings virtueller Netzwerke durchlaufen werden müssen, wenn der Datenverkehr über den Hub gesendet wird. Es gibt mehrere Möglichkeiten, zwei virtuelle Spoke-Netzwerke direkt miteinander zu verbinden: Peering virtueller Netzwerke, Azure Virtual Network Manager und VPN-Tunnel.

• Virtuelles Netzwerk-Peering. Die Vorteile direkter virtueller Netzwerk-Peerings gegenüber Speichen sind:

  • Geringere Kosten, da weniger Hops für das Peering virtueller Netzwerke erforderlich sind.
  • Bessere Leistung, da der Datenverkehr kein Netzwerkgerät durchlaufen muss, das Wartezeiten oder potenzielle Engpässe verursacht.

  Andere Szenarien umfassen mandantenübergreifende Konnektivität. Es kann jedoch sein, dass Sie den Datenverkehr zwischen virtuellen Spoke-Netzwerken überprüfen müssen, was es erforderlich machen könnte, den Datenverkehr über zentralisierte Netzwerkgeräte im virtuellen Hubnetzwerk zu leiten.

• Subnetz-Peering. Ähnlich wie beim virtuellen Netzwerk-Peering, aber Subnetz-Peering ermöglicht eine genauere Granularität, indem angegeben wird, welche Subnetze an beiden Seiten des Peerings miteinander kommunizieren dürfen.

• Azure Virtual Network Manager. Zusätzlich zu den Vorteilen, die virtuelle Netzwerk-Peering bietet, bietet Azure Virtual Network Manager einen Verwaltungsdienst, mit dem Sie virtuelle Netzwerkumgebungen verwalten und konnektivitätsübergreifend erstellen können. Mithilfe von Azure Virtual Network Manager können Sie drei Arten von Topologien über Abonnements hinweg erstellen, sowohl für bestehende als auch für neue virtuelle Netzwerke:

  • Hub-and-Spoke mit Spokes, die nicht miteinander verbunden sind.

  • Hub-and-Spoke mit Spokes, die direkt miteinander verbunden sind, ohne Hop in der Mitte.

  • Eine vermaschte Gruppe von virtuellen Netzwerken, die miteinander verbunden sind.

    

    Laden Sie alle Visio-Diagramme in diesem Artikel herunter.

    Wenn Sie eine Hub-and-Spoke-Topologie mit Azure Virtual Network Manager erstellen, in der Speichen miteinander verbunden sind, werden direkte Verbindungen zwischen virtuellen Speichennetzwerken in derselben Netzwerkgruppe automatisch bidirektional erstellt. Mithilfe von Azure Virtual Network Manager können Sie virtuelle Spoke-Netzwerke statisch oder dynamisch zu Mitgliedern einer bestimmten Netzwerkgruppe machen, die automatisch die Konnektivität für ein beliebiges virtuelles Netzwerk erstellt.

    Sie können mehrere Netzwerkgruppen erstellen, um Cluster von virtuellen Spoke-Netzwerken von der direkten Konnektivität zu isolieren. Jede Netzwerkgruppe bietet dieselbe Region und die Unterstützung mehrerer Regionen für Spoke-to-Spoke-Konnektivität. Achten Sie darauf, unter den maximalen Grenzwerten für Azure Virtual Network Manager zu bleiben, die in den häufig gestellten Fragen zu Azure Virtual Network Manager beschrieben werden.

• VPN-Tunnel, die virtuelle Netzwerke verbinden. Sie können VPN-Dienste so konfigurieren, dass virtuelle Speichennetzwerke direkt über Microsoft VPN-Gateways oder VPN-NVAs von Drittanbietern verbunden werden. Der Vorteil dieser Option ist, dass virtuelle Spoke-Netzwerke über kommerzielle und Sovereign Clouds innerhalb desselben Cloudanbieters oder über cloudanbieterübergreifende Konnektivität verbunden sind. Wenn in jedem virtuellen Spoke-Netzwerk softwaredefinierte Wide Area Network-NVAs (SD-WAN) vorhanden sind, kann diese Konfiguration außerdem die Verwendung der Steuerungsebene und der Featuregruppe des Drittanbieters zur Verwaltung der virtuellen Netzwerkkonnektivität erleichtern.

  Diese Option kann Ihnen auch dabei helfen, complianceanforderungen für die Verschlüsselung von Datenverkehr über virtuelle Netzwerke in einem einzigen Azure-Rechenzentrum zu erfüllen, das noch nicht von der MACsec-Verschlüsselung bereitgestellt wird. Diese Option bringt jedoch aufgrund der Bandbreitenbegrenzungen von IPsec-Tunneln (1,25 Gbit/s pro Tunnel) und der Entwurfseinschränkungen, dass VNET-Gateways sowohl in virtuellen Hub- als auch Spoke-Netzwerken vorhanden sein müssen, eine Reihe von Herausforderungen mit sich: Wenn das virtuelle Spoke-Netzwerk über ein VNET-Gateway verfügt, kann es nicht mit der Virtual WAN-Instanz verbunden werden oder das VNET-Gateway eines Hubs verwenden, um die Verbindung mit lokalen Netzwerken herzustellen.

Muster 1a: Einzelner Bereich

Unabhängig von der Technologie, die Sie verwenden, um virtuelle Spoke-Netzwerke miteinander zu verbinden, würden die Netzwerktopologien für eine einzelne Region wie folgt aussehen:

Muster 1b: Mehrere Regionen

Entwürfe, die alle virtuellen Spoke-Netzwerke miteinander verbinden, können auch auf mehrere Regionen ausgeweitet werden. In dieser Topologie ist Azure Virtual Network Manager sogar noch wichtiger, um den Verwaltungsaufwand für die Pflege der erforderlichen großen Anzahl von Verbindungen zu reduzieren.

Hinweis

Wenn Sie virtuelle Spoke-Netzwerke direkt verbinden, entweder in einer oder in mehreren Regionen, sollten Sie dies für virtuelle Spoke-Netzwerke in derselben Umgebung vornehmen. Verbinden Sie z. B. ein virtuelles Spoke-Entwicklungsnetzwerk mit einem anderen virtuellen Spoke-Entwicklungsnetzwerk. Vermeiden Sie es jedoch, ein virtuelles Spoke-Entwicklungsnetzwerk mit einem virtuellen Spoke-Produktionsnetzwerk zu verbinden.

Wenn Sie virtuelle Spoke-Netzwerke in einer vollständig vermaschten Topologie direkt miteinander verbinden, müssen Sie die potenziell hohe Anzahl der erforderlichen Peerings virtueller Netzwerke berücksichtigen. Das folgende Diagramm veranschaulicht dieses Problem. In diesem Szenario wird Azure Virtual Network Manager dringend empfohlen, sodass Sie automatisch virtuelle Netzwerkverbindungen erstellen können.

Muster 2: Spoke-Kommunikation über ein Netzwerkgerät

Anstatt virtuelle Spoke-Netzwerke direkt miteinander zu verbinden, können Sie Netzwerkgeräte zur Weiterleitung des Datenverkehrs zwischen Spokes verwenden. Netzwerkgeräte bieten zusätzliche Dienste im Netzwerk wie eingehende Paketuntersuchung und Segmentierung oder Überwachung des Datenverkehrs, können aber Wartezeiten und Leistungsengpässe verursachen, wenn sie nicht richtig dimensioniert sind. Diese Geräte befinden sich in der Regel in einem virtuellen Hubnetzwerk, mit dem die Spokes verbunden sind. Es gibt mehrere Möglichkeiten, ein Netzwerkgerät zur Weiterleitung des Datenverkehrs zwischen Spokes zu verwenden:

• Virtual WAN-Hubrouter. Virtual WAN, das vollständig von Microsoft verwaltet wird, enthält einen virtuellen Router, der den Datenverkehr von Spokes aufnimmt und ihn entweder an ein anderes virtuelles Netzwerk weiterleitet, das mit Virtual WAN verbunden ist, oder an lokale Netzwerke über ExpressRoute oder Site-to-Site- oder Point-to-Site-VPN-Tunnel. Der virtuelle WAN-Router skaliert automatisch nach oben und unten, sodass Sie nur sicherstellen müssen, dass das Datenverkehrsvolumen zwischen Speichen innerhalb der Virtual WAN-Grenzen bleibt.

• Azure Firewall.Azure Firewall ist eine Netzwerk-Appliance, die von Microsoft verwaltet wird und in virtuellen Hubnetzwerken bereitgestellt werden kann, die Sie verwalten oder in virtuellen WAN-Hubs. Es kann IP-Pakete weiterleiten, sie untersuchen und Regeln zur Segmentierung des Datenverkehrs anwenden, die in Richtlinien definiert sind. Sie bietet die automatische Skalierung bis zu den Azure Firewall-Grenzwerten , sodass sie nicht zu einem Engpass wird. Beachten Sie, dass Azure Firewall nur bei Verwendung von Virtual WAN sofortige Funktionen für mehrere Regionen bietet. Ohne Virtual WAN müssen Sie benutzerdefinierte Routen implementieren, um eine regionsübergreifende Spoke-to-Spoke-Kommunikation zu erreichen.

• Virtuelle Netzwerkgeräte von Drittanbietern. Wenn Sie es vorziehen, ein virtuelles Gerät eines Microsoft-Partners für das Routing und die Segmentierung des Netzwerks zu verwenden, können Sie virtuelle Netzwerkgeräte entweder in einer Hub-and-Spoke- oder einer Virtual WAN-Topologie bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von hochverwendenden NVAs oder NVAs in einem virtuellen WAN-Hub. Sie müssen sicher sein, dass das virtuelle Netzwerkgerät die Bandbreite unterstützt, die von der Inter-Spoke-Kommunikation generiert wird.

• Azure VPN-Gateway. Sie können ein Azure VPN-Gateway als nächsten Hoptyp einer benutzerdefinierten Route verwenden, aber Microsoft empfiehlt nicht, virtuelle VPN-Netzwerkgateways zum Routen von Spoke-to-Spoke-Datenverkehr zu verwenden. Diese Geräte sind für die Verschlüsselung von Datenverkehr zu lokalen Standorten oder VPN-Benutzern konzipiert. Es gibt z. B. keine Garantie für die Bandbreite zwischen Spokes, die ein VPN-Gateway weiterleiten kann.

• ExpressRoute. In bestimmten Konfigurationen kann ein ExpressRoute-Gateway Routen ankündigen, die eine Spoke-to-Spoke-Kommunikation anziehen und den Datenverkehr an den Microsoft Edge-Router senden, wo er an den Zielspoke weitergeleitet wird. Dieses Muster wird manchmal als ExpressRoute-Haarpinning bezeichnet und muss explizit aktiviert werden, indem sie die Anweisungen unter "Aktivieren oder Deaktivieren von VNet zu VNet" oder "VNet" zum virtuellen WAN-Datenverkehr über ExpressRoute befolgen. Microsoft rät dringend von diesem Szenario ab, da es zu Wartezeiten führt, da der Datenverkehr zum Microsoft-Backbone-Edge und zurück gesendet wird. Darüber hinaus empfiehlt Microsoft diesen Ansatz aufgrund des Single Point of Failure und des hohen Auswirkungsgrads nicht. Dieses Szenario bringt auch mehrere Probleme mit sich, da es die ExpressRoute-Infrastruktur (das Gateway und die physischen Router) zusätzlich belastet. Dieser zusätzliche Druck kann zu Paketverlusten führen.

In self-managed Hub-and-Spoke-Netzwerkdesigns mit zentralisierten NVAs wird die Appliance in der Regel im Hub platziert. Peerings virtueller Netzwerke zwischen virtuellen Hub-and-Spoke-Netzwerken müssen manuell oder automatisch mit Azure Virtual Network Manager erstellt werden:

• Manuelle virtuelle Netzwerk-Peerings oder Subnetz-Peerings. Dieser Ansatz ist ausreichend, wenn Sie über eine geringe Anzahl von virtuellen Spoke-Netzwerken verfügen, aber er erzeugt einen Verwaltungsmehraufwand im großen Stil.

• Azure Virtual Network Manager. Wie bereits erwähnt, bietet Azure Virtual Network Manager Features zum Verwalten virtueller Netzwerkumgebungen und Peerings im großen Maßstab. Peeringkonfigurationen zwischen virtuellen Hub-and-Spoke-Netzwerken werden automatisch bidirektional für Netzwerkgruppen konfiguriert.

  Azure Virtual Network Manager bietet die Möglichkeit, speichen virtuelle Netzwerkmitgliedschaften statisch oder dynamisch einer bestimmten Netzwerkgruppe hinzuzufügen, wodurch automatisch die Peeringverbindung für neue Mitglieder erstellt wird. Virtuelle Speichennetzwerke in Netzwerkgruppen können die Hub-VPN- oder ExpressRoute-Gateways für die Konnektivität verwenden. Achten Sie darauf, unter den maximalen Grenzwerten für Azure Virtual Network Manager zu bleiben.

Muster 2a: Einzelner Bereich

Das folgende Diagramm zeigt eine Hub-and-Spoke-Topologie für eine einzelne Region, bei der der Datenverkehr zwischen den Spokes durch eine Azure-Firewall geleitet wird, die im virtuellen Hubnetzwerk bereitgestellt wird. Der Datenverkehr wird über benutzerdefinierte Routen, die auf die Spoke-Subnetze angewendet werden, an das zentrale Gerät im Hub weitergeleitet.

Unter bestimmten Umständen kann es aus Gründen der Skalierbarkeit von Vorteil sein, die virtuellen Geräte für das Netzwerk, die den Spoke-to-Spoke- und den Internetdatenverkehr abwickeln, zu trennen. Sie können diese Trennung erreichen, indem Sie wie folgt vorgehen:

• Optimieren Sie die Routentabellen in den Speichen, um private Adressen (die über eine Route für RFC 1918-Präfixe verfügen) an eine NVA zu senden, die für Azure-to-Azure- und Azure-to-on-lokalen Datenverkehr (auch ost-west-Datenverkehr genannt) verantwortlich ist.
• Die Optimierung des Datenverkehrs aus dem Internet (der die Route 0.0.0.0/0 aufweist) zu einer zweiten NVA. Dieser NVA ist für Den Azure-zu-Internet-Datenverkehr verantwortlich (auch als Nord-Süd-Datenverkehr bezeichnet).

Auf der folgenden Abbildung wird diese Konfiguration veranschaulicht:

Hinweis

Die Azure-Firewall erfordert, dass nur eine Azure Firewall-Ressource in einem virtuellen Netzwerk bereitgestellt werden kann. Daher ist für zusätzliche Azure Firewall-Ressourcen ein separates virtuelles Hubnetzwerk erforderlich. Für NVA-Szenarien können Sie ein einziges virtuelles Hubnetzwerk für weitere NVA-Bereitstellungen verwenden.

Muster 2b: Mehrere Regionen

Sie können dieselbe Konfiguration auf mehrere Regionen erweitern. Beispielsweise sollten Sie in einem selbstverwalteten Hub-and-Spoke-Design, das Azure Firewall verwendet, zusätzliche Routentabellen auf die Azure Firewall-Subnetze in jedem Hub für die Speichen in der Remoteregion anwenden. Diese Konfiguration stellt sicher, dass der Datenverkehr zwischen den Azure-Firewalls in jedem virtuellen Hubnetzwerk weitergeleitet werden kann. Der regionsübergreifende Datenverkehr zwischen virtuellen Spoke-Netzwerken durchläuft dann beide Azure-Firewalls. Weitere Informationen finden Sie unter Azure Firewall zum Weiterleiten einer Multi-Hub- und Speichentopologie:

Die Entwurfsvariante mit separaten Azure-Firewalls oder virtuellen Netzwerkgeräten für den Nord-Süd- und Ost-West-Datenverkehr ist auch in einer Hub-and-Spoke-Topologie für mehrere Regionen möglich:

Hinweis

Die Azure-Firewall erfordert, dass nur eine Azure Firewall-Ressource in einem virtuellen Netzwerk bereitgestellt werden kann. Daher ist für zusätzliche Azure Firewall-Ressourcen ein separates virtuelles Hubnetzwerk erforderlich. Für NVA-Szenarien können Sie ein einziges virtuelles Hubnetzwerk für weitere NVA-Bereitstellungen verwenden.

Virtual WAN erstellt eine ähnliche Topologie und übernimmt die Routingkomplexität. Dies gilt sowohl für die Hubs (die von Microsoft verwaltet werden) als auch für die Spokes (wo Routen eingeschleust werden können und nicht manuell in Routingtabellen definiert werden müssen). So muss der Netzwerkadministrator nur die virtuellen Spoke-Netzwerke mit einem virtuellen WAN-Hub verbinden und sich nicht um die Weiterleitung des Datenverkehrs zwischen den Regionen kümmern.

Gemischte Muster

Einige Situationen erfordern möglicherweise einen Hybridansatz, der die beiden zuvor beschriebenen Muster kombiniert. In diesem Fall muss der Datenverkehr zwischen bestimmten Speichen über direkte Verbindungen gehen, aber die restlichen Speichen kommunizieren über eine zentrale Netzwerk-Appliance. Beispielsweise können Sie in einer virtuellen WAN-Umgebung zwei bestimmte Spokes, die eine hohe Bandbreite und eine geringe Wartezeit erfordern, direkt miteinander verbinden. Ein anderes Szenario betrifft virtuelle Spoke-Netzwerke, die Teil einer einzelnen Umgebung sind. Sie können z. B. zulassen, dass ein virtuelles Spoke-Entwicklungsnetzwerk direkt mit einem anderen virtuellen Spoke-Entwicklungsnetzwerk verbunden wird, aber die Workloads für Entwicklung und Produktion müssen über das zentrale Gerät kommunizieren.

Ein weiteres gängiges Muster umfasst das Verbinden von Speichen in einer Region über direkte virtuelle Netzwerk-Peerings oder mit Azure Virtual Network Manager verbundene Gruppen, ermöglicht jedoch den interregionalen Datenverkehr über NVAs hinweg. Die Hauptmotivation für dieses Modell besteht in der Regel darin, die Anzahl der Peerings virtueller Netzwerke in der Architektur zu reduzieren. Im Vergleich zum ersten Modell (direkte Konnektivität zwischen Spokes) besteht ein Nachteil dieses Modells jedoch darin, dass es mehr Peering virtueller Netzwerke für den Datenverkehr zwischen den Regionen gibt. Diese Hops erhöhen die Kosten, da mehrere Peerings virtueller Netzwerke durchquert werden müssen. Ein weiterer Nachteil ist die zusätzliche Belastung der Hub-NVAs, um den gesamten regionsübergreifenden Datenverkehr zu ermöglichen.

Die gleichen Entwürfe sind auch für Virtual WAN anwendbar. Eine Überlegung ist jedoch, dass die direkte Konnektivität zwischen virtuellen Spoke-Netzwerken manuell direkt zwischen den virtuellen Netzwerken und nicht über die Virtual WAN-Ressource konfiguriert werden muss. Azure Virtual Network Manager unterstützt derzeit keine Architekturen, die auf Virtual WAN basieren. Beispiel:

Hinweis

Bei gemischten Ansätzen ist es wichtig zu verstehen, dass die direkte Konnektivität über virtuelle Netzwerk-Peering Systemrouten für seine virtuellen Netzwerke verteilt, die häufig spezifischer sind als benutzerdefinierte Routen, die über Routentabellen konfiguriert sind. Daher wird der Peeringpfad für virtuelle Netzwerke gegenüber benutzerdefinierten Routen bevorzugt, die der längsten Route mit Präfixüberstimmung folgen.

In weniger häufigen Szenarien, wenn es sowohl eine Systemroute als auch eine benutzerdefinierte Route mit demselben Adresspräfix gibt, hat die benutzerdefinierte Route jedoch Vorrang vor Systemrouten (die automatisch durch Peering virtueller Netzwerke erstellt werden). Dieses Verhalten führt dazu, dass der Datenverkehr im virtuellen Netzwerk von Spoke-to-Spoke durch das virtuelle Netzwerk des Hubs verläuft, selbst wenn eine direkte Verbindung über Peering besteht.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Jay Li | Senior Product Manager
• Jose Moreno | Principal Customer Engineer
• Alejandra Palacios | Senior Azure Infrastructure Customer Engineer

Andere Mitwirkende:

• Mick Alberts | Technischer Autor
• Mohammed Hassan | Haupt-PM-Manager
• Andrea Michael | Programm-Manager
• Yasukuni Morishima | Customer Engineer II
• Jithin PP| Wartungstechniker

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Cloud Adoption Framework: Zielzonen-Netzwerktopologie und Konnektivität
• Virtuelles Netzwerk-Peering
• Azure Virtual Network Manager
• Virtuelles WAN
• Azure Firewall
• Sichere Netzwerkkonnektivität in Azure
• Einführung in virtuelle Azure-Netzwerke

Zugehörige Ressourcen

• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN
• Herkömmliche Azure-Netzwerktopologie

Bei den gängigsten Netzwerkdesignmustern in Azure werden virtuelle Hub-and-Spoke-Netzwerktopologien in einer oder mehreren Azure-Regionen erstellt, die optional über Azure ExpressRoute oder Site-to-Site-VPN-Tunnel (Virtual Private Network) über das öffentliche Internet mit lokalen Netzwerken verbunden sind.

Die meisten Entwurfsleitfäden konzentrieren sich auf den Anwendungsdatenverkehr zu diesen virtuellen Netzwerken von Benutzern entweder in internen, lokalen Netzwerken oder aus dem Internet (was die Branche normalerweise den Nord-Süd-Datenverkehr bezeichnet, da sie häufig durch vertikale Linien in Netzwerkdiagrammen dargestellt wird). Dieser Artikel befasst sich mit verschiedenen Mustern, die für den Ost-West-Verkehr verfügbar sind. Das heißt, die Kommunikation fließt zwischen Workloads, die in virtuellen Azure-Netzwerken bereitgestellt werden, entweder innerhalb einer Region oder in verschiedenen Regionen.

Um die Leistung, Skalierbarkeit und Ausfallsicherheit Ihrer Anwendungen, die in Azure ausgeführt werden, zu gewährleisten, müssen Sie sicherstellen, dass Ihr Netzwerk die Anforderungen für den Datenverkehr von Ost nach West erfüllt.

Mögliche Anwendungsfälle

Der Spoke-to-Spoke-Datenverkehr kann in verschiedenen Szenarien wichtig sein:

• Verschiedene Ebenen einer Anwendung befinden sich in separaten virtuellen Netzwerken. Beispielsweise kommunizieren Umkreisnetzwerkserver (auch als DMZ-Server bezeichnet) in einem Umkreis-virtuellen Netzwerk mit Anwendungsdiensten in einem internen virtuellen Netzwerk.
• Anwendungsworkloads in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) müssen Daten untereinander replizieren.
• Verschiedene Anwendungen oder Microservices müssen miteinander kommunizieren.
• Datenbanken müssen Daten überregional replizieren, um die Geschäftskontinuität im Falle eines Notfalls zu gewährleisten.
• Die Benutzer befinden sich in den virtuellen Azure-Netzwerken. Sie verwenden z. B. Azure Virtual Desktop.

Muster und Topologien für die Inter-Spoke-Kommunikation

Es gibt zwei Haupttopologien, die Sie in Azure-Designs verwenden können, die über mehrere virtuelle Netzwerke hinweg bestehen: selbstverwaltete Hubs und Speichen und Azure Virtual WAN. In einer virtuellen WAN-Umgebung verwaltet Microsoft die virtuellen Hubnetzwerke und alles darin. In einer selbstverwalteten Hub-and-Spoke-Umgebung verwalten Sie das virtuelle Hubnetzwerk.

Virtuelle WAN- und selbstverwaltete Hub- und Speichentopologien sind beispiele für Architekturen, in denen die Workloads in virtuellen Speichennetzwerken ausgeführt werden und die Konnektivität mit lokalen Netzwerken in einem virtuellen Hubnetzwerk zentralisiert wird. So viele der in diesem Artikel erläuterten Konzepte gelten sowohl für self-managed Hub-and-Spoke- als auch für virtuelle WAN-Designs.

Es gibt zwei Hauptmuster für die Verbindung von virtuellen Spoke-Netzwerken untereinander:

• Direkt miteinander verbundene Spoke-Instanzen. Peerings virtueller Netzwerke oder VPN-Tunnel werden zwischen den virtuellen Spoke-Netzwerken erstellt, um eine direkte Konnektivität zu ermöglichen, ohne das virtuelle Hubnetzwerk zu durchqueren.
• Spokes kommunizieren über ein Netzwerkgerät. Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zum Virtual WAN oder zu einem virtuellen Hubnetzwerk. Eine Appliance leitet den Datenverkehr von Spoke zu Spoke weiter. Die Appliance kann von Microsoft (wie bei Virtual WAN) oder von Ihnen selbst verwaltet werden.

Muster 1: Direkt miteinander verbundene Spoke-Instanzen.

Direkte Verbindungen zwischen Spokes bieten in der Regel einen besseren Durchsatz, eine kürzere Wartezeit und eine bessere Skalierbarkeit als Verbindungen, die über ein virtuelles Netzwerkgerät (NVA) über einen Hub verlaufen. Das Senden von Datenverkehr über NVAs kann zu zusätzlichen Wartezeiten führen, wenn die NVAs in einer anderen Verfügbarkeitszone liegen und mindestens zwei Peerings virtueller Netzwerke durchlaufen werden müssen, wenn der Datenverkehr über den Hub gesendet wird. Es gibt mehrere Möglichkeiten, zwei virtuelle Spoke-Netzwerke direkt miteinander zu verbinden: Peering virtueller Netzwerke, Azure Virtual Network Manager und VPN-Tunnel.

• Virtuelles Netzwerk-Peering. Die Vorteile direkter virtueller Netzwerk-Peerings gegenüber Speichen sind:

  • Geringere Kosten, da weniger Hops für das Peering virtueller Netzwerke erforderlich sind.
  • Bessere Leistung, da der Datenverkehr kein Netzwerkgerät durchlaufen muss, das Wartezeiten oder potenzielle Engpässe verursacht.

  Andere Szenarien umfassen mandantenübergreifende Konnektivität. Es kann jedoch sein, dass Sie den Datenverkehr zwischen virtuellen Spoke-Netzwerken überprüfen müssen, was es erforderlich machen könnte, den Datenverkehr über zentralisierte Netzwerkgeräte im virtuellen Hubnetzwerk zu leiten.

• Subnetz-Peering. Ähnlich wie beim virtuellen Netzwerk-Peering, aber Subnetz-Peering ermöglicht eine genauere Granularität, indem angegeben wird, welche Subnetze an beiden Seiten des Peerings miteinander kommunizieren dürfen.

• Azure Virtual Network Manager. Zusätzlich zu den Vorteilen, die virtuelle Netzwerk-Peering bietet, bietet Azure Virtual Network Manager einen Verwaltungsdienst, mit dem Sie virtuelle Netzwerkumgebungen verwalten und konnektivitätsübergreifend erstellen können. Mithilfe von Azure Virtual Network Manager können Sie drei Arten von Topologien über Abonnements hinweg erstellen, sowohl für bestehende als auch für neue virtuelle Netzwerke:

  • Hub-and-Spoke mit Spokes, die nicht miteinander verbunden sind.

  • Hub-and-Spoke mit Spokes, die direkt miteinander verbunden sind, ohne Hop in der Mitte.

  • Eine vermaschte Gruppe von virtuellen Netzwerken, die miteinander verbunden sind.

    

    Laden Sie alle Visio-Diagramme in diesem Artikel herunter.

    Wenn Sie eine Hub-and-Spoke-Topologie mit Azure Virtual Network Manager erstellen, in der Speichen miteinander verbunden sind, werden direkte Verbindungen zwischen virtuellen Speichennetzwerken in derselben Netzwerkgruppe automatisch bidirektional erstellt. Mithilfe von Azure Virtual Network Manager können Sie virtuelle Spoke-Netzwerke statisch oder dynamisch zu Mitgliedern einer bestimmten Netzwerkgruppe machen, die automatisch die Konnektivität für ein beliebiges virtuelles Netzwerk erstellt.

    Sie können mehrere Netzwerkgruppen erstellen, um Cluster von virtuellen Spoke-Netzwerken von der direkten Konnektivität zu isolieren. Jede Netzwerkgruppe bietet dieselbe Region und die Unterstützung mehrerer Regionen für Spoke-to-Spoke-Konnektivität. Achten Sie darauf, unter den maximalen Grenzwerten für Azure Virtual Network Manager zu bleiben, die in den häufig gestellten Fragen zu Azure Virtual Network Manager beschrieben werden.

• VPN-Tunnel, die virtuelle Netzwerke verbinden. Sie können VPN-Dienste so konfigurieren, dass virtuelle Speichennetzwerke direkt über Microsoft VPN-Gateways oder VPN-NVAs von Drittanbietern verbunden werden. Der Vorteil dieser Option ist, dass virtuelle Spoke-Netzwerke über kommerzielle und Sovereign Clouds innerhalb desselben Cloudanbieters oder über cloudanbieterübergreifende Konnektivität verbunden sind. Wenn in jedem virtuellen Spoke-Netzwerk softwaredefinierte Wide Area Network-NVAs (SD-WAN) vorhanden sind, kann diese Konfiguration außerdem die Verwendung der Steuerungsebene und der Featuregruppe des Drittanbieters zur Verwaltung der virtuellen Netzwerkkonnektivität erleichtern.

  Diese Option kann Ihnen auch dabei helfen, complianceanforderungen für die Verschlüsselung von Datenverkehr über virtuelle Netzwerke in einem einzigen Azure-Rechenzentrum zu erfüllen, das noch nicht von der MACsec-Verschlüsselung bereitgestellt wird. Diese Option bringt jedoch aufgrund der Bandbreitenbegrenzungen von IPsec-Tunneln (1,25 Gbit/s pro Tunnel) und der Entwurfseinschränkungen, dass VNET-Gateways sowohl in virtuellen Hub- als auch Spoke-Netzwerken vorhanden sein müssen, eine Reihe von Herausforderungen mit sich: Wenn das virtuelle Spoke-Netzwerk über ein VNET-Gateway verfügt, kann es nicht mit der Virtual WAN-Instanz verbunden werden oder das VNET-Gateway eines Hubs verwenden, um die Verbindung mit lokalen Netzwerken herzustellen.

Muster 1a: Einzelner Bereich

Unabhängig von der Technologie, die Sie verwenden, um virtuelle Spoke-Netzwerke miteinander zu verbinden, würden die Netzwerktopologien für eine einzelne Region wie folgt aussehen:

Muster 1b: Mehrere Regionen

Entwürfe, die alle virtuellen Spoke-Netzwerke miteinander verbinden, können auch auf mehrere Regionen ausgeweitet werden. In dieser Topologie ist Azure Virtual Network Manager sogar noch wichtiger, um den Verwaltungsaufwand für die Pflege der erforderlichen großen Anzahl von Verbindungen zu reduzieren.

Hinweis

Wenn Sie virtuelle Spoke-Netzwerke direkt verbinden, entweder in einer oder in mehreren Regionen, sollten Sie dies für virtuelle Spoke-Netzwerke in derselben Umgebung vornehmen. Verbinden Sie z. B. ein virtuelles Spoke-Entwicklungsnetzwerk mit einem anderen virtuellen Spoke-Entwicklungsnetzwerk. Vermeiden Sie es jedoch, ein virtuelles Spoke-Entwicklungsnetzwerk mit einem virtuellen Spoke-Produktionsnetzwerk zu verbinden.

Wenn Sie virtuelle Spoke-Netzwerke in einer vollständig vermaschten Topologie direkt miteinander verbinden, müssen Sie die potenziell hohe Anzahl der erforderlichen Peerings virtueller Netzwerke berücksichtigen. Das folgende Diagramm veranschaulicht dieses Problem. In diesem Szenario wird Azure Virtual Network Manager dringend empfohlen, sodass Sie automatisch virtuelle Netzwerkverbindungen erstellen können.

Muster 2: Spoke-Kommunikation über ein Netzwerkgerät

Anstatt virtuelle Spoke-Netzwerke direkt miteinander zu verbinden, können Sie Netzwerkgeräte zur Weiterleitung des Datenverkehrs zwischen Spokes verwenden. Netzwerkgeräte bieten zusätzliche Dienste im Netzwerk wie eingehende Paketuntersuchung und Segmentierung oder Überwachung des Datenverkehrs, können aber Wartezeiten und Leistungsengpässe verursachen, wenn sie nicht richtig dimensioniert sind. Diese Geräte befinden sich in der Regel in einem virtuellen Hubnetzwerk, mit dem die Spokes verbunden sind. Es gibt mehrere Möglichkeiten, ein Netzwerkgerät zur Weiterleitung des Datenverkehrs zwischen Spokes zu verwenden:

• Virtual WAN-Hubrouter. Virtual WAN, das vollständig von Microsoft verwaltet wird, enthält einen virtuellen Router, der den Datenverkehr von Spokes aufnimmt und ihn entweder an ein anderes virtuelles Netzwerk weiterleitet, das mit Virtual WAN verbunden ist, oder an lokale Netzwerke über ExpressRoute oder Site-to-Site- oder Point-to-Site-VPN-Tunnel. Der virtuelle WAN-Router skaliert automatisch nach oben und unten, sodass Sie nur sicherstellen müssen, dass das Datenverkehrsvolumen zwischen Speichen innerhalb der Virtual WAN-Grenzen bleibt.

• Azure Firewall.Azure Firewall ist eine Netzwerk-Appliance, die von Microsoft verwaltet wird und in virtuellen Hubnetzwerken bereitgestellt werden kann, die Sie verwalten oder in virtuellen WAN-Hubs. Es kann IP-Pakete weiterleiten, sie untersuchen und Regeln zur Segmentierung des Datenverkehrs anwenden, die in Richtlinien definiert sind. Sie bietet die automatische Skalierung bis zu den Azure Firewall-Grenzwerten , sodass sie nicht zu einem Engpass wird. Beachten Sie, dass Azure Firewall nur bei Verwendung von Virtual WAN sofortige Funktionen für mehrere Regionen bietet. Ohne Virtual WAN müssen Sie benutzerdefinierte Routen implementieren, um eine regionsübergreifende Spoke-to-Spoke-Kommunikation zu erreichen.

• Virtuelle Netzwerkgeräte von Drittanbietern. Wenn Sie es vorziehen, ein virtuelles Gerät eines Microsoft-Partners für das Routing und die Segmentierung des Netzwerks zu verwenden, können Sie virtuelle Netzwerkgeräte entweder in einer Hub-and-Spoke- oder einer Virtual WAN-Topologie bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von hochverwendenden NVAs oder NVAs in einem virtuellen WAN-Hub. Sie müssen sicher sein, dass das virtuelle Netzwerkgerät die Bandbreite unterstützt, die von der Inter-Spoke-Kommunikation generiert wird.

• Azure VPN-Gateway. Sie können ein Azure VPN-Gateway als nächsten Hoptyp einer benutzerdefinierten Route verwenden, aber Microsoft empfiehlt nicht, virtuelle VPN-Netzwerkgateways zum Routen von Spoke-to-Spoke-Datenverkehr zu verwenden. Diese Geräte sind für die Verschlüsselung von Datenverkehr zu lokalen Standorten oder VPN-Benutzern konzipiert. Es gibt z. B. keine Garantie für die Bandbreite zwischen Spokes, die ein VPN-Gateway weiterleiten kann.

• ExpressRoute. In bestimmten Konfigurationen kann ein ExpressRoute-Gateway Routen ankündigen, die eine Spoke-to-Spoke-Kommunikation anziehen und den Datenverkehr an den Microsoft Edge-Router senden, wo er an den Zielspoke weitergeleitet wird. Dieses Muster wird manchmal als ExpressRoute-Haarpinning bezeichnet und muss explizit aktiviert werden, indem sie die Anweisungen unter "Aktivieren oder Deaktivieren von VNet zu VNet" oder "VNet" zum virtuellen WAN-Datenverkehr über ExpressRoute befolgen. Microsoft rät dringend von diesem Szenario ab, da es zu Wartezeiten führt, da der Datenverkehr zum Microsoft-Backbone-Edge und zurück gesendet wird. Darüber hinaus empfiehlt Microsoft diesen Ansatz aufgrund des Single Point of Failure und des hohen Auswirkungsgrads nicht. Dieses Szenario bringt auch mehrere Probleme mit sich, da es die ExpressRoute-Infrastruktur (das Gateway und die physischen Router) zusätzlich belastet. Dieser zusätzliche Druck kann zu Paketverlusten führen.

In self-managed Hub-and-Spoke-Netzwerkdesigns mit zentralisierten NVAs wird die Appliance in der Regel im Hub platziert. Peerings virtueller Netzwerke zwischen virtuellen Hub-and-Spoke-Netzwerken müssen manuell oder automatisch mit Azure Virtual Network Manager erstellt werden:

• Manuelle virtuelle Netzwerk-Peerings oder Subnetz-Peerings. Dieser Ansatz ist ausreichend, wenn Sie über eine geringe Anzahl von virtuellen Spoke-Netzwerken verfügen, aber er erzeugt einen Verwaltungsmehraufwand im großen Stil.

• Azure Virtual Network Manager. Wie bereits erwähnt, bietet Azure Virtual Network Manager Features zum Verwalten virtueller Netzwerkumgebungen und Peerings im großen Maßstab. Peeringkonfigurationen zwischen virtuellen Hub-and-Spoke-Netzwerken werden automatisch bidirektional für Netzwerkgruppen konfiguriert.

  Azure Virtual Network Manager bietet die Möglichkeit, speichen virtuelle Netzwerkmitgliedschaften statisch oder dynamisch einer bestimmten Netzwerkgruppe hinzuzufügen, wodurch automatisch die Peeringverbindung für neue Mitglieder erstellt wird. Virtuelle Speichennetzwerke in Netzwerkgruppen können die Hub-VPN- oder ExpressRoute-Gateways für die Konnektivität verwenden. Achten Sie darauf, unter den maximalen Grenzwerten für Azure Virtual Network Manager zu bleiben.

Muster 2a: Einzelner Bereich

Das folgende Diagramm zeigt eine Hub-and-Spoke-Topologie für eine einzelne Region, bei der der Datenverkehr zwischen den Spokes durch eine Azure-Firewall geleitet wird, die im virtuellen Hubnetzwerk bereitgestellt wird. Der Datenverkehr wird über benutzerdefinierte Routen, die auf die Spoke-Subnetze angewendet werden, an das zentrale Gerät im Hub weitergeleitet.

Unter bestimmten Umständen kann es aus Gründen der Skalierbarkeit von Vorteil sein, die virtuellen Geräte für das Netzwerk, die den Spoke-to-Spoke- und den Internetdatenverkehr abwickeln, zu trennen. Sie können diese Trennung erreichen, indem Sie wie folgt vorgehen:

• Optimieren Sie die Routentabellen in den Speichen, um private Adressen (die über eine Route für RFC 1918-Präfixe verfügen) an eine NVA zu senden, die für Azure-to-Azure- und Azure-to-on-lokalen Datenverkehr (auch ost-west-Datenverkehr genannt) verantwortlich ist.
• Die Optimierung des Datenverkehrs aus dem Internet (der die Route 0.0.0.0/0 aufweist) zu einer zweiten NVA. Dieser NVA ist für Den Azure-zu-Internet-Datenverkehr verantwortlich (auch als Nord-Süd-Datenverkehr bezeichnet).

Auf der folgenden Abbildung wird diese Konfiguration veranschaulicht:

Hinweis

Die Azure-Firewall erfordert, dass nur eine Azure Firewall-Ressource in einem virtuellen Netzwerk bereitgestellt werden kann. Daher ist für zusätzliche Azure Firewall-Ressourcen ein separates virtuelles Hubnetzwerk erforderlich. Für NVA-Szenarien können Sie ein einziges virtuelles Hubnetzwerk für weitere NVA-Bereitstellungen verwenden.

Muster 2b: Mehrere Regionen

Sie können dieselbe Konfiguration auf mehrere Regionen erweitern. Beispielsweise sollten Sie in einem selbstverwalteten Hub-and-Spoke-Design, das Azure Firewall verwendet, zusätzliche Routentabellen auf die Azure Firewall-Subnetze in jedem Hub für die Speichen in der Remoteregion anwenden. Diese Konfiguration stellt sicher, dass der Datenverkehr zwischen den Azure-Firewalls in jedem virtuellen Hubnetzwerk weitergeleitet werden kann. Der regionsübergreifende Datenverkehr zwischen virtuellen Spoke-Netzwerken durchläuft dann beide Azure-Firewalls. Weitere Informationen finden Sie unter Azure Firewall zum Weiterleiten einer Multi-Hub- und Speichentopologie:

Die Entwurfsvariante mit separaten Azure-Firewalls oder virtuellen Netzwerkgeräten für den Nord-Süd- und Ost-West-Datenverkehr ist auch in einer Hub-and-Spoke-Topologie für mehrere Regionen möglich:

Hinweis

Die Azure-Firewall erfordert, dass nur eine Azure Firewall-Ressource in einem virtuellen Netzwerk bereitgestellt werden kann. Daher ist für zusätzliche Azure Firewall-Ressourcen ein separates virtuelles Hubnetzwerk erforderlich. Für NVA-Szenarien können Sie ein einziges virtuelles Hubnetzwerk für weitere NVA-Bereitstellungen verwenden.

Virtual WAN erstellt eine ähnliche Topologie und übernimmt die Routingkomplexität. Dies gilt sowohl für die Hubs (die von Microsoft verwaltet werden) als auch für die Spokes (wo Routen eingeschleust werden können und nicht manuell in Routingtabellen definiert werden müssen). So muss der Netzwerkadministrator nur die virtuellen Spoke-Netzwerke mit einem virtuellen WAN-Hub verbinden und sich nicht um die Weiterleitung des Datenverkehrs zwischen den Regionen kümmern.

Gemischte Muster

Einige Situationen erfordern möglicherweise einen Hybridansatz, der die beiden zuvor beschriebenen Muster kombiniert. In diesem Fall muss der Datenverkehr zwischen bestimmten Speichen über direkte Verbindungen gehen, aber die restlichen Speichen kommunizieren über eine zentrale Netzwerk-Appliance. Beispielsweise können Sie in einer virtuellen WAN-Umgebung zwei bestimmte Spokes, die eine hohe Bandbreite und eine geringe Wartezeit erfordern, direkt miteinander verbinden. Ein anderes Szenario betrifft virtuelle Spoke-Netzwerke, die Teil einer einzelnen Umgebung sind. Sie können z. B. zulassen, dass ein virtuelles Spoke-Entwicklungsnetzwerk direkt mit einem anderen virtuellen Spoke-Entwicklungsnetzwerk verbunden wird, aber die Workloads für Entwicklung und Produktion müssen über das zentrale Gerät kommunizieren.

Ein weiteres gängiges Muster umfasst das Verbinden von Speichen in einer Region über direkte virtuelle Netzwerk-Peerings oder mit Azure Virtual Network Manager verbundene Gruppen, ermöglicht jedoch den interregionalen Datenverkehr über NVAs hinweg. Die Hauptmotivation für dieses Modell besteht in der Regel darin, die Anzahl der Peerings virtueller Netzwerke in der Architektur zu reduzieren. Im Vergleich zum ersten Modell (direkte Konnektivität zwischen Spokes) besteht ein Nachteil dieses Modells jedoch darin, dass es mehr Peering virtueller Netzwerke für den Datenverkehr zwischen den Regionen gibt. Diese Hops erhöhen die Kosten, da mehrere Peerings virtueller Netzwerke durchquert werden müssen. Ein weiterer Nachteil ist die zusätzliche Belastung der Hub-NVAs, um den gesamten regionsübergreifenden Datenverkehr zu ermöglichen.

Die gleichen Entwürfe sind auch für Virtual WAN anwendbar. Eine Überlegung ist jedoch, dass die direkte Konnektivität zwischen virtuellen Spoke-Netzwerken manuell direkt zwischen den virtuellen Netzwerken und nicht über die Virtual WAN-Ressource konfiguriert werden muss. Azure Virtual Network Manager unterstützt derzeit keine Architekturen, die auf Virtual WAN basieren. Beispiel:

Hinweis

Bei gemischten Ansätzen ist es wichtig zu verstehen, dass die direkte Konnektivität über virtuelle Netzwerk-Peering Systemrouten für seine virtuellen Netzwerke verteilt, die häufig spezifischer sind als benutzerdefinierte Routen, die über Routentabellen konfiguriert sind. Daher wird der Peeringpfad für virtuelle Netzwerke gegenüber benutzerdefinierten Routen bevorzugt, die der längsten Route mit Präfixüberstimmung folgen.

In weniger häufigen Szenarien, wenn es sowohl eine Systemroute als auch eine benutzerdefinierte Route mit demselben Adresspräfix gibt, hat die benutzerdefinierte Route jedoch Vorrang vor Systemrouten (die automatisch durch Peering virtueller Netzwerke erstellt werden). Dieses Verhalten führt dazu, dass der Datenverkehr im virtuellen Netzwerk von Spoke-to-Spoke durch das virtuelle Netzwerk des Hubs verläuft, selbst wenn eine direkte Verbindung über Peering besteht.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Jay Li | Senior Product Manager
• Jose Moreno | Principal Customer Engineer
• Alejandra Palacios | Senior Azure Infrastructure Customer Engineer

Andere Mitwirkende:

• Mick Alberts | Technischer Autor
• Mohammed Hassan | Haupt-PM-Manager
• Andrea Michael | Programm-Manager
• Yasukuni Morishima | Customer Engineer II
• Jithin PP| Wartungstechniker

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Cloud Adoption Framework: Zielzonen-Netzwerktopologie und Konnektivität
• Virtuelles Netzwerk-Peering
• Azure Virtual Network Manager
• Virtuelles WAN
• Azure Firewall
• Sichere Netzwerkkonnektivität in Azure
• Einführung in virtuelle Azure-Netzwerke

Zugehörige Ressourcen

• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN
• Herkömmliche Azure-Netzwerktopologie