Architektur mit einem globalen Transitnetzwerk und Azure Virtual WAN
Moderne Unternehmen erfordern überall Verbindungen zwischen umfassend verteilten Anwendungen, Daten und Benutzern in der Cloud und lokal. Die Architektur mit einem globalen Transitnetzwerk wird von Unternehmen eingesetzt, um den cloudzentrischen IT-Fußabdruck moderner, globaler Unternehmen zu konsolidieren, zu vernetzen und zu steuern.
Die Architektur mit einem globalen Transitnetzwerk basiert auf einem klassischen Hub-and-Spoke-Konnektivitätsmodell, bei dem der in der Cloud gehostete Netzwerkhub Übertragungsverbindungen zwischen Endpunkten ermöglicht, die sich in unterschiedlichen Spokes befinden.
In diesem Modell kann eine Spoke Folgendes sein:
- ein virtuelles Netzwerk (VNET)
- eine physische Zweigstelle
- ein Remotebenutzer
- Internet
Abbildung 1: Globales Hub-and-Spoke-Transitnetzwerk
In Abbildung 1 sehen Sie den logischen Aufbau des globalen Transitnetzwerks, bei dem geografisch verteilte Benutzer, physische Standorte und virtuelle Netzwerke über einen in der Cloud gehosteten Netzwerkhub miteinander verbunden sind. Durch diese Architektur sind logische Transitverbindungen mit einem Hop zwischen den Netzwerkendpunkten möglich.
Globales Transitnetzwerk mit Virtual WAN
Azure Virtual WAN ist ein von Microsoft verwalteter Cloudnetzwerkdienst. Alle Netzwerkkomponenten, aus denen dieser Dienst besteht, werden von Microsoft gehostet und verwaltet. Weitere Informationen zu Virtual WAN finden Sie im Artikel mit der Übersicht über Virtual WAN.
Durch Azure Virtual WAN wird eine Architektur mit einem globalen Transitnetzwerk ermöglicht, da überall N:M-Verbindungen zwischen global verteilten Sätzen von Cloudworkloads in VNets, Zweigstellen, SaaS- und PaaS-Anwendungen und Benutzern möglich sind.
Abbildung 2: Globales Transitnetzwerk und Virtual WAN
In der Azure Virtual WAN-Architektur werden virtuelle WAN-Hubs in Azure-Regionen bereitgestellt, an die Sie Zweigstellen, VNets und Remotebenutzer anbinden können. Die physischen Zweigstellen werden über Premium oder Standard ExpressRoute oder Site-to-Site-VPNs mit dem Hub verbunden, VNets werden über VNet-Verbindungen mit dem Hub verbunden und Remotebenutzer können über ein Benutzer-VPN (Point-to-Site-VPN) direkt eine Verbindung mit dem Hub herstellen. Virtual WAN unterstützt auch regionsübergreifende VNet-Verbindungen, wobei ein VNet in einer Region mit einem Virtual WAN-Hub in einer anderen Region verbunden werden kann.
Sie können ein virtuelles WAN erstellen, indem Sie einen einzelnen Virtual WAN-Hub in der Region erstellen, in der sich die meisten Spokes (Zweigstellen, VNets, Benutzer) befinden. Stellen Sie anschließend eine Verbindung der Spokes, die sich in einer anderen Region befinden, zum Hub her. Dies ist eine gute Möglichkeit, wenn der Fußabdruck eines Unternehmens größtenteils in einer Region mit wenigen Remote-Spokes liegt.
Hub-zu-Hub-Verbindungen
Der Cloudfußabdruck eines Unternehmens kann sich über mehrere Cloudregionen erstrecken. Diese Architektur ist optimal (in Bezug auf die Latenz) für den Cloudzugriff in einer Region geeignet, die möglichst nah am physischen Standort des Unternehmens und an den Benutzern liegt. Einer der wichtigsten Faktoren für eine Architektur mit einem globalen Transitnetzwerk ist die Möglichkeit regionsübergreifender Verbindungen zwischen allen Cloud- und lokalen Netzwerkendpunkten. Das bedeutet, dass der Datenverkehr einer Zweigstelle, die in einer bestimmten Region mit der Cloud verbunden ist, eine Zweigstelle oder ein VNet in einer anderen Region über eine Hub-zu-Hub-Konnektivität, die durch das Azure Global Network ermöglicht wird, erreichen kann.
Abbildung 3: Regionsübergreifende Virtual WAN-Verbindungen
Wenn mehrere Hubs in einem einzelnen virtuellen WAN aktiviert sind, werden die Hubs automatisch über Hub-zu-Hub-Verbindungen miteinander verbunden, wodurch eine globale Konnektivität zwischen Zweigstellen und VNets ermöglicht wird, die über mehrere Regionen verteilt sind.
Die Hubs sind darüber hinaus zwar alle Teil desselben virtuellen WAN, können aber unterschiedlichen regionalen Zugriffs- und Sicherheitsrichtlinien unterliegen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Sicherheits- und Richtliniensteuerung.
N:n-Verbindungen
Durch die Architektur mit einem globalen Transitnetzwerk sind N:M-Verbindungen über Virtual WAN-Hubs möglich. Diese Architektur macht vollständig vermaschte oder teilweise vermaschte Verbindungen zwischen Spokes, deren Aufbau und Wartung komplexer ist, überflüssig bzw. minimiert deren Notwendigkeit. Zusätzlich kann die Routingsteuerung in Hub-and-Spoke-Modellen im Vergleich zu vermaschten Netzwerken einfacher konfiguriert und gewartet werden.
Durch N:M-Verbindungen (im Kontext einer globalen Architektur) können Unternehmen mit global verteilten Benutzern, Zweigstellen, Rechenzentren, VNets und Anwendungen über einen Transithub Verbindungen miteinander herstellen. Azure Virtual WAN fungiert als globales Transitsystem.
Abbildung 4: Datenverkehrspfade in Azure Virtual WAN
Azure Virtual WAN unterstützt die folgenden globalen Transitverbindungsarten. Die Buchstaben in Klammern entsprechen den Buchstaben in Abbildung 4.
- Zweigstelle-zu-VNET (a)
- Zweigstelle-zu-Zweigstelle (b)
- ExpressRoute Global Reach und Virtual WAN
- Remotebenutzer-zu-VNET (c)
- Remotebenutzer-zu-Zweigstelle (d)
- VNet-zu-VNet (e)
- Zweigstelle-zu-Hub-Hub-zu-Zweigstelle (f)
- Zweigstelle-zu-Hub-Hub-zu-VNet (g)
- VNet-zu-Hub-Hub-zu-VNet (h)
Zweigstelle-zu-VNet (a) und Zweigstelle-zu-VNet, regionsübergreifend (g)
Pfade zwischen Zweigstellen und VNETs werden primär von Azure Virtual WAN unterstützt. Mit diesem Pfad können Sie Zweigstellen mit Azure-IaaS-Unternehmensworkloads vernetzen, die in Azure-VNETs bereitgestellt wurden. Zweigstellen können über ExpressRoute oder ein Site-to-Site-VPN mit einem virtuellen WAN vernetzt werden. Der Datenverkehr wird an VNets übertragen, die mit den Virtual WAN-Hubs über VNet-Verbindungen verbunden sind. Ein expliziter Gatewaytransit ist für Virtual WAN nicht erforderlich, da Virtual WAN den Gatewaytransit an Zweigstellen automatisch ermöglicht. Informationen zum Herstellen einer Verbindung zwischen einem SD-WAN-CPE und einem Virtual WAN finden Sie im Artikel Virtual WAN-Partner.
ExpressRoute Global Reach und Virtual WAN
ExpressRoute ist eine private und zuverlässige Möglichkeit, Ihre lokalen Netzwerke mit der Microsoft Cloud zu verbinden. Virtual WAN unterstützt ExpressRoute-Leitungsverbindungen. Die folgenden ExpressRoute-Leitungs-SKUs können mit Virtual WAN verbunden werden: Lokal, Standard und Premium.
Es gibt zwei Optionen zum Aktivieren von ExpressRoute zur ExpressRoute-Transitkonnektivität bei Verwendung von Azure Virtual WAN:
Sie können ExpressRoute zu ExpressRoute-Transitkonnektivität aktivieren, indem Sie ExpressRoute Global Reach auf Ihren ExpressRoute-Schaltkreisen aktivieren. Global Reach ist ein ExpressRoute-Add-On-Feature, mit dem Sie ExpressRoute-Schaltkreise an verschiedenen Peeringstandorten miteinander verknüpfen können, um ein privates Netzwerk zu erstellen. ExpressRoute-zu-ExpressRoute-Transitverbindungen zwischen Schaltkreisen mit dem Add-on Global Reach werden nicht über den virtuellen WAN-Hub geleitet, da Global Reach einen optimaleren Pfad über das globale Backbone ermöglicht.
Sie können das Routingabsichtsfeature mit Richtlinien für privates Datenverkehrsrouting verwenden, um die ExpressRoute-Transitkonnektivität über eine sicherheitsrelevante Appliance zu aktivieren, die im virtuellen WAN-Hub bereitgestellt wird. Für diese Option ist kein Global Reach erforderlich. Weitere Informationen finden Sie im Abschnitt ExpressRoute in der Dokumentation zur Routingabsicht.
Zweigstelle-zu-Zweigstelle (b) und Zweigstelle-zu-Zweigstelle, regionsübergreifend (f)
Zweigstellen können mit einem Azure Virtual WAN-Hub über ExpressRoute-Leitungen und/oder Site-to-Site-VPN-Verbindungen verbunden sein. Sie können die Zweigstellen mit einem Virtual WAN-Hub verbinden, der sich in einer Region befindet, die der Zweigstelle am nächsten ist.
Durch diese Option können Unternehmen den Azure-Backbone zum Verbinden von Zweigstellen verwenden. Diese Funktion ist zwar verfügbar, Sie sollten aber dennoch die Vorteile der Verbindung von Zweigstellen über Azure Virtual WAN mit den Vorteilen eines privaten WAN vergleichen.
Hinweis
Das Deaktivieren von Branch-to-Branch-Konnektivität im virtuellen WAN bzw. virtuellen WAN kann so konfiguriert werden, dass Branch-to-Branch-Konnektivität deaktiviert wird. Durch diese Konfiguration wird die Weitergabe von Routen zwischen durch VPN (S2S und P2S) und Express Route verbundenen Standorten blockiert. Diese Konfiguration wirkt sich nicht auf Branch-zu-VNET und VNET-zu-VNET-Routenweitergabe und die Konnektivität aus. So konfigurieren Sie diese Einstellung im Azure-Portal: Wählen Sie im Menü „Virtual WAN-Konfiguration“ die Einstellung „Branch-to-Branch – deaktiviert“ aus.
Remotebenutzer-zu-VNET (c)
Sie können direkten, sicheren Remotezugriff auf Azure über eine Point-to-Site-Verbindung zwischen einem Remotebenutzerclient und einem virtuellen WAN ermöglichen. Remotebenutzer eines Unternehmens müssen so nicht mehr mühsam eine Verbindung über ein Unternehmens-VPN herstellen.
Remotebenutzer-zu-Zweigstelle (d)
Mit dem Remotebenutzer-zu-Zweigstelle-Pfad können Remotebenutzer, die über eine Point-to-Site-Verbindung mit Azure verbunden sind, auf lokale Workloads und Anwendungen über die Cloud zugreifen. Durch diesen Pfad können Remotebenutzer flexibel auf Workloads zugreifen, die in Azure oder lokal bereitgestellt wurden. Unternehmen können in Azure Virtual WAN einen zentralen, cloudbasierten, sicheren Remotezugriffsdienst verfügbar machen.
VNet-zu-VNet-Transit (e) und VNet-zu-VNet, regionsübergreifend (h)
Der VNet-zu-VNet-Transit ermöglicht Verbindungen zwischen VNets, um mehrschichtige Anwendungen zu verbinden, die in mehreren VNets implementiert wurden. Optional können Sie VNets über VNet Peering miteinander verbinden. Dies ist u. U. für einige Szenarien geeignet, in denen kein Transit über den VWAN-Hub erforderlich ist.
Erzwingen von Tunneln und Standardrouten
Erzwungene Tunnel können aktiviert werden, indem die aktivierte Standardroute für eine VPN-, ExpressRoute- oder virtuelle Netzwerkverbindung in Virtual WAN konfiguriert wird.
Ein virtueller Hub gibt eine erlernte Standardroute an eine Verbindung vom Typ „Virtuelles Netzwerk“, „Site-to-Site-VPN“ oder „ExpressRoute“ weiter, wenn das aktivierte Standardflag für die Verbindung auf „Aktiviert“ festgelegt ist.
Dieses Flag ist sichtbar, wenn der Benutzer eine VNET-Verbindung, eine VPN-Verbindung oder eine ExpressRoute-Verbindung bearbeitet. Das Flag ist standardmäßig deaktiviert, wenn für eine Site oder eine ExpressRoute-Leitung eine Verbindung mit einem Hub besteht. Es ist standardmäßig aktiviert, wenn eine VNET-Verbindung hinzugefügt wird, um ein VNET mit einem virtuellen Hub zu verbinden. Der Ursprung der Standardroute liegt nicht auf dem Virtual WAN-Hub. Sie wird weitergegeben, wenn sie dem Virtual WAN-Hub bereits bekannt ist, weil darin eine Firewall bereitgestellt wurde, oder wenn für eine andere verbundene Site die Tunnelerzwingung aktiviert ist.
Sicherheits- und Richtliniensteuerung
Die Azure Virtual WAN-Hubs verbinden alle Netzwerkendpunkte über das hybride Netzwerk und können u. U. den gesamten Transitnetzwerkdatenverkehr sehen. Virtual WAN-Hubs können in Secure Virtual Hubs konvertiert werden, indem eine Bump-in-the-Wire-Sicherheitslösung im Hub bereitgestellt wird. Sie können Azure Firewall bereitstellen und virtuelle Firewallnetzwerkgeräte der nächsten Generation oder Sicherheitssoftware-as-a-Service (SaaS) in Virtual WAN Hubs auswählen, um die cloudbasierte Sicherheits-, Zugriffs- und Richtliniensteuerung zu ermöglichen. Sie können Virtual WAN konfigurieren, um Datenverkehr mithilfe der Virtual Hub Routing-Absicht an Sicherheitslösungen im Hub weiterzuleiten.
Die Orchestrierung von Azure Firewalls in virtuellen WAN-Hubs kann mit Azure Firewall Manager durchgeführt werden. Azure Firewall Manager stellt Funktionen zum Verwalten und Skalieren der Sicherheit für globale Transitnetzwerke zur Verfügung. Azure Firewall Manager bietet die Möglichkeit, Routing, globale Richtlinienverwaltung und erweiterte Internetsicherheitsdienste über Drittanbieter zusammen mit der Azure Firewall zentral zu verwalten.
Weitere Informationen zum Bereitstellen und Orchestrieren virtueller Firewall-Netzwerkgeräte der nächsten Generation im Virtual WAN-Hub finden Sie unter Integrierte virtuelle Netzwerkgeräte im virtuellen Hub. Weitere Informationen zu SaaS-Sicherheitslösungen, die im Virtual WAN-Hub bereitgestellt werden können, finden Sie unter Software-as-a-Service.
Abbildung 5: Geschützter virtueller Hub mit Azure Firewall
Virtual WAN unterstützt die folgenden globalen sicheren Transitverbindungsarten. Das Diagramm und die Datenverkehrsmuster in diesem Abschnitt beschreiben zwar Azure Firewall-Anwendungsfälle, aber dieselben Datenverkehrsmuster werden für virtuelle Netzwerkgeräte und SaaS-Sicherheitslösungen, die im Hub bereitgestellt werden, unterstützt. Die Buchstaben in Klammern entsprechen den Buchstaben in Abbildung 5.
- Geschützter Branch-zu-VNet-Transit (c)
- Geschützter Branch-zu-VNet-Transit über virtuelle Hubs (g), unterstützt mit Routingabsicht
- Geschützter VNet-zu-VNet-Transit (e)
- Geschützter VNet-zu-VNet-Transit über virtuelle Hubs (h), unterstützt mit Routingabsicht
- Geschützter Branch-zu-Branch-Transit (b), unterstützt mit Routingabsicht
- Geschützter Branch-zu-Branch-Transit über virtuelle Hubs (f), unterstützt mit Routingabsicht
- VNet-zu-Internet oder Sicherheitsdienst von Drittanbietern (i)
- Zweigstelle-zu-Internet oder Sicherheitsdienst von Drittanbietern (j)
Geschützter VNet-zu-VNet-Transit (e), regionsübergreifender geschützter VNet-zu-VNet-Transit (h)
Der geschützte VNet-zu-VNet-Transit ermöglicht es VNets, sich über Sicherheitsappliances (Azure Firewall, ausgewählte NVA und SaaS), die im Virtual WAN-Hub bereitgestellt sind, miteinander zu verbinden.
VNet-zu-Internet oder Sicherheitsdienst von Drittanbietern (i)
VNet-zu-Internet ermöglicht es virtuellen Netzwerken, sich über Sicherheitsappliances (Azure Firewall, ausgewählte NVA und SaaS) im virtuellen WAN-Hub mit dem Internet zu verbinden. Datenverkehr über unterstützte Sicherheitsdienste von Drittanbietern fließt nicht durch eine Sicherheitsappliance und wird direkt an den Sicherheitsdienst eines Drittanbieters weitergeleitet. Sie können den Vnet-zu-Internet-Pfad über einen unterstützten Sicherheitsdienst eines Drittanbieters mit Azure Firewall Manager konfigurieren.
Zweigstelle-zu-Internet oder Sicherheitsdienst von Drittanbietern (j)
Zweigstelle-zu-Internet ermöglicht es Zweigstellen, sich über die Azure Firewall im virtuellen WAN-Hub mit dem Internet zu verbinden. Datenverkehr über unterstützte Sicherheitsdienste von Drittanbietern fließt nicht durch eine Sicherheitsappliance und wird direkt an den Sicherheitsdienst eines Drittanbieters weitergeleitet. Sie können den Zweigstelle-zu-Internet-Pfad über einen unterstützten Sicherheitsdienst eines Drittanbieters mit Azure Firewall Manager konfigurieren.
Geschützter Branch-zu-Branch-Transit, regionsübergreifender geschützter Branch-zu-Branch-Transit (b), (f)
Zweigstellen können mit einem geschützten virtuellen Hub mit Azure Firewall über ExpressRoute-Leitungen und/oder Site-to-Site-VPN-Verbindungen verbunden sein. Sie können die Zweigstellen mit einem Virtual WAN-Hub verbinden, der sich in einer Region befindet, die der Zweigstelle am nächsten ist. Das Konfigurieren von Routingabsicht auf Virtual WAN-Hubs ermöglicht die Untersuchung von Branch-zu-Branch-Datenverkehr im selbem Hub oder zwischen Hubs/Regionen durch Sicherheitsappliances (Azure Firewall, ausgewählte NVA und SaaS), die im Virtual WAN-Hub bereitgestellt sind.
Durch diese Option können Unternehmen den Azure-Backbone zum Verbinden von Zweigstellen verwenden. Diese Funktion ist zwar verfügbar, Sie sollten aber dennoch die Vorteile der Verbindung von Zweigstellen über Azure Virtual WAN mit den Vorteilen eines privaten WAN vergleichen.
Geschützter Branch-zu-VNet-Transit (c), regionsübergreifender geschützter Branch-zu-VNet-Transit (g)
Der geschützte Branch-zu-VNet-Transit ermöglicht die Kommunikation von Branches mit virtuellen Netzwerken in der gleichen Region wie der virtuelle WAN-Hub sowie mit einem anderen virtuellen Netzwerk, das mit einem anderen virtuellen WAN-Hub in einer anderen Region verbunden ist (Untersuchung von Datenverkehr zwischen Hubs nur mit Routingabsicht unterstützt).
Wie aktiviere ich die Standardroute (0.0.0.0/0) in einem geschützten virtuellen Hub?
Azure Firewall, das in einem virtuellen WAN-Hub (geschützter virtueller Hub) bereitgestellt wird, kann als Standardrouter zum Internet oder zum vertrauenswürdigen Sicherheitsanbieter für alle Zweigstellen (verbunden über VPN oder ExpressRoute), virtuelle Spoke-Netzwerke und Benutzer (verbunden über P2S VPN) konfiguriert werden. Diese Konfiguration muss mithilfe von Azure Firewall Manager durchgeführt werden. Weitere Informationen finden Sie unter „Weiterleiten des Datenverkehrs an Ihren Hub zum Konfigurieren sämtlichen Datenverkehrs von Zweigstellen (einschließlich Benutzer)“ sowie unter „Virtuelle Netzwerke zum Internet über die Azure Firewall“.
Dies ist eine zweistufige Konfiguration:
Konfigurieren Sie das Routing des Internetdatenverkehrs über das Menü für die geschützte virtuelle Hubrouteneinstellung. Konfigurieren Sie virtuelle Netzwerke und Zweigstellen, die Datenverkehr über die Firewall an das Internet senden können.
Konfigurieren Sie, welche Verbindungen (Vnet und Branch) den Datenverkehr ins Internet (0.0.0.0/0) über die Azure Firewall im Hub oder über den vertrauenswürdigen Sicherheitsanbieter weiterleiten können. Dieser Schritt stellt sicher, dass die Standardroute an ausgewählte Zweigstellen und virtuelle Netzwerke weitergegeben wird, die über die Verbindungen an den Virtual WAN-Hub angefügt sind.
Erzwingen des Tunnelns von Datenverkehr zu einer lokalen Firewall in einem geschützten virtuellen Hub
Wenn der virtuelle Hub bereits eine Standardroute (über BGP) von einer der Zweigstellen (VPN- oder ER-Standorte) erhalten hat, wird diese Standardroute durch die Standardroute überschrieben, die aus der Azure Firewall Manager-Einstellung erhalten wurde. In diesem Fall wird der gesamte Datenverkehr, der von virtuellen Netzwerken und Zweigstellen, die für das Internet bestimmt sind, in den Hub gelangt, an die Azure Firewall oder den vertrauenswürdigen Sicherheitsanbieter weitergeleitet.
Hinweis
Derzeit gibt es keine Möglichkeit, für Internetdatenverkehr, der von virtuellen Netzwerken, Zweigstellen oder Benutzern stammt, die lokale Firewall oder Azure Firewall-Instanz (und den vertrauenswürdigen Sicherheitsanbieter) auszuwählen. Die Standardroute, die aus der Azure Firewall Manager-Einstellung übernommen wurde, wird immer der Standardroute vorgezogen, die aus einer der Zweigstellen übernommen wurde.
Nächste Schritte
Erstellen Sie eine Verbindung mit Virtual WAN und stellen Sie die Azure Firewall in VWAN-Hubs bereit.