Hub-Spoke-Netzwerktopologie in Azure

Network Watcher
Firewall
Virtual Network
Bastion
VPN Gateway

In dieser Referenzarchitektur wird eine Hub-Spoke-Topologie in Azure erläutert. Das virtuelle Hub-Netzwerk fungiert als zentraler Konnektivitätspunkt zu vielen virtuellen Spoke-Netzwerken. Der Hub kann auch als Konnektivitätspunkt zu Ihren lokalen Netzwerken verwendet werden. Die virtuellen Spoke-Netzwerke stellen eine Peeringverbindung mit dem Hub her und können zur Isolierung von Workloads verwendet werden.

Aufbau

Hub-spoke topology in Azure

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Architektur umfasst die folgenden Komponenten:

Virtuelles Hub-Netzwerk: Das virtuelle Hub-Netzwerk ist der zentrale Konnektivitätspunkt mit Ihrem lokalen Netzwerk. Ein Ort, an dem Dienste gehostet werden, die von den verschiedenen Workloads, die in den virtuellen Spoke-Netzwerken gehostet werden, genutzt werden können.

Virtuelle Spoke-Netzwerke: Virtuelle Spoke-Netzwerke können verwendet werden, um Workloads in ihren eigenen virtuellen Netzwerken zu isolieren, die getrennt von anderen Spokes verwaltet werden. Jede Workload kann mehrere Schichten umfassen, wobei mehrere Subnetze über Azure Load Balancer verbunden sind.

Peering virtueller Netzwerke: Zwei virtuelle Netzwerke können über eine Peeringverbindung miteinander verbunden werden. Peeringverbindungen sind nicht-transitive Verbindungen zwischen virtuellen Netzwerken mit geringen Wartezeiten. Sobald eine Peeringverbindung hergestellt wurde, tauschen die virtuellen Netzwerke ohne Einsatz eines Routers Datenverkehr über den Azure-Backbone aus.

Bastionhost Mit Azure Bastion können Sie über Ihren Browser und das Azure-Portal eine sichere Verbindung mit einem virtuellen Computer herstellen. Ein Azure Bastion-Host wird innerhalb eines Azure Virtual Network bereitgestellt und kann auf virtuelle Computer im virtuellen Netzwerk (VNet) oder auf virtuelle Computer in VNets mit Peering zugreifen.

Azure Firewall: Azure Firewall ist eine verwaltete Firewall, die als Dienst eingesetzt wird. Die Firewallinstanz befindet sich in einem eigenen Subnetz.

VPN-Gateway für ein virtuelles Netzwerk oder ExpressRoute-Gateway: Über das Gateway für virtuelle Netzwerke kann das virtuelle Netzwerk zur Konnektivität mit Ihrem lokalen Netzwerk eine Verbindung mit dem VPN-Gerät oder eine ExpressRoute-Verbindung herstellen. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit einem Microsoft Azure Virtual Network.

VPN-Gerät: Ein Gerät oder ein Dienst, das bzw. der externe Konnektivität mit dem lokalen Netzwerk bereitstellt. Bei dem VPN-Gerät kann es sich um ein Hardwaregerät oder eine Softwarelösung wie den Routing- und RAS-Dienst (RRAS) unter Windows Server 2012 handeln. Weitere Informationen finden Sie unter Informationen zu VPN-Geräten für VPN Gateway-Verbindungen zwischen Standorten.

Szenariodetails

Zu den Vorteilen der Verwendung einer Hub-and-Spoke-Konfiguration gehören Kosteneinsparungen, die Überwindung von Grenzwerten für Abonnements und die Isolierung von Workloads.

Mögliche Anwendungsfälle

Typische Einsatzmöglichkeiten für diese Architektur sind:

  • Workloads, die in verschiedenen Umgebungen wie Entwicklungs-, Test- und Produktionsumgebungen eingesetzt werden und gemeinsame Dienste wie DNS, IDS, NTP oder AD DS erfordern Gemeinsame Dienste werden im virtuellen Hubnetzwerk platziert, während die einzelnen Umgebungen in einem Spoke bereitgestellt werden, um die Isolation beizubehalten.
  • Workloads, bei denen keine Konnektivität untereinander bestehen muss, die jedoch Zugriff auf gemeinsame Dienste erfordern.
  • Unternehmen, die auf eine zentrale Steuerung von Sicherheitsmechanismen (z.B. eine Firewall im Hub als DMZ) und eine getrennte Verwaltung von Workloads in den einzelnen Spokes angewiesen sind

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarien. Sofern Sie keine besonderen Anforderungen haben, die Vorrang haben, sollten Sie diese Empfehlungen befolgen.

Ressourcengruppen

Die in diesem Dokument enthaltene Beispiellösung verwendet eine einzelne Azure-Ressourcengruppe. In der Praxis können der Hub und die einzelnen Spokes in verschiedenen Ressourcengruppen und sogar in verschiedenen Abonnements implementiert werden. Wenn Sie eine Peerverbindung zwischen virtuellen Netzwerken in verschiedenen Abonnements herstellen, können beide Abonnements demselben oder einem anderen Azure Active Directory-Mandanten zugeordnet sein. Diese Flexibilität ermöglicht nicht nur eine dezentralisierte Verwaltung der einzelnen Workloads, sondern auch die Verwaltung gemeinsamer Dienste im Hub.

Virtuelles Netzwerk und GatewaySubnet

Erstellen Sie ein Subnetz mit dem Namen GatewaySubnet mit dem Adressbereich „/27“. Das virtuelle Netzwerkgateway erfordert dieses Subnetz. Durch Zuweisung von 32 Adressen zu diesem Subnetz wird eine künftige Überschreitung von Beschränkungen der Gatewaygröße verhindert.

Weitere Informationen zum Einrichten des Gateways finden Sie abhängig von Ihrem Verbindungstyp in den folgenden Referenzarchitekturen:

Um eine höhere Verfügbarkeit zu erzielen, können Sie ExpressRoute mit einem VPN für Failoverzwecke kombinieren. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit Azure unter Verwendung von ExpressRoute mit VPN-Failover.

Eine Hub-Spoke-Topologie kann auch ohne Gateway verwendet werden, wenn keine Konnektivität mit Ihrem lokalen Netzwerk erforderlich ist.

Peering in virtuellen Netzwerken

Beim Peering virtueller Netzwerke wird eine nicht-transitive Beziehung zwischen zwei virtuellen Netzwerken hergestellt. Wenn Sie eine Verbindung zwischen Spokes herstellen möchten, sollten Sie eventuell eine separate Peeringverbindung zwischen diesen Spokes herstellen.

Angenommen, es muss zwischen mehreren Spokes eine Verbindung hergestellt werden. In diesem Fall werden die möglichen Peeringverbindungen schnell zur Neige gehen, da die Anzahl der Peerings virtueller Netzwerke pro virtuelles Netzwerk begrenzt ist. Weitere Informationen finden Sie unter Grenzwerte für Netzwerke. In diesem Szenario sollten Sie die Verwendung von benutzerdefinierten Routen (User Defined Routes, UDRs) in Erwägung ziehen, um zu erzwingen, dass der für einen Spoke vorgesehene Datenverkehr an Azure Firewall oder ein virtuelles Netzwerkgerät gesendet wird, die als Router im Hub fungiert. Durch diese Änderung können die Spokes miteinander verbunden werden.

Sie können Spokes auch für die Kommunikation mit Remotenetzwerken über das Hubgateway konfigurieren. Damit der Gatewaydatenverkehr zwischen den Spokes und dem Hub weitergeleitet und eine Verbindung mit Remotenetzwerken hergestellt werden kann, müssen Sie folgende Schritte durchführen:

  • Konfigurieren Sie die Peeringverbindung im Hub so, dass Gatewaytransit zugelassen wird.
  • Konfigurieren Sie die Peeringverbindung in den einzelnen Spokes so, dass Remotegateways verwendet werden.
  • Konfigurieren Sie alle Peeringverbindungen so, dass weitergeleiteter Datenverkehr zugelassen wird.

Weitere Informationen finden Sie unter Erstellen von VNet-Peerings.

Konnektivität zwischen Spokes

Wenn Sie Konnektivität zwischen Spokes benötigen, sollten Sie den Einsatz einer Azure Firewall oder eines anderen virtuellen Netzwerkgeräts in Betracht ziehen. Erstellen Sie dann Routen, um den Verkehr vom Spoke an die Firewall oder das virtuelle Netzwerkgerät weiterzuleiten, das dann an den zweiten Spoke weiterleiten kann. In diesem Szenario müssen Sie die Peeringverbindungen dahingehend konfigurieren, dass weitergeleiteter Verkehr zugelassen wird.

Routing between spokes using Azure Firewall

Laden Sie eine Visio-Datei dieser Architektur herunter.

Sie können auch ein VPN-Gateway verwenden, um Datenverkehr zwischen Spokes weiterzuleiten. Diese Auswahl wirkt sich jedoch auf die Wartezeit und den Durchsatz aus. Weitere Informationen zur Konfiguration finden Sie unter Konfigurieren des VPN-Gatewaytransits für ein Peering virtueller Netzwerke.

Berücksichtigen Sie die Dienste, die im Hub gemeinsam genutzt werden, um sicherzustellen, dass sich der Hub für eine größere Anzahl von Spokes skalieren lässt. Wenn Ihr Hub beispielsweise Firewalldienste bereitstellt, sollten Sie beim Hinzufügen mehrerer Spokes die Bandbreitenbeschränkungen Ihrer Firewalllösung berücksichtigen. Es wird empfohlen, einige dieser gemeinsamen Dienste auf eine zweite Hubebene zu verlagern.

Überlegungen

Verwaltung

Verwenden Sie Azure Virtual Network Manager (AVNM), um neue Hub-and-Spoke-Topologien von virtuellen Netzwerken (bzw. für vorhandene ein Onboarding durchzuführen) für die zentrale Verwaltung von Konnektivitäts- und Sicherheitskontrollen zu erstellen.

AVNM stellt sicher, dass Ihre Hub-and-Spoke-Netzwerktopologien für ein großes zukünftiges Wachstum in mehreren Abonnements, Verwaltungsgruppen und Regionen vorbereitet sind. Sehen Sie sich folgendes Beispielszenarien an:

  • Die Demokratisierung der Verwaltung virtueller Spoke-Netzwerke an die Gruppen einer Organisation, z. B. Geschäftsbereiche oder Anwendungsteams, was zu einer großen Anzahl von Anforderungen an die Regeln für Konnektivität und Netzwerksicherheit zwischen VNets führt.
  • Die Standardisierung mehrerer Hub-and-Spoke-Replikatarchitekturen in mehreren Azure-Regionen, um einen globalen Speicherbedarf für Anwendungen zu gewährleisten.

Die Erkennbarkeit der gewünschten virtuellen Netzwerke, die über AVNM verwaltet werden sollen, kann mithilfe der Funktion Bereiche definiert werden. Dieses Feature ermöglicht Flexibilität für eine gewünschte Anzahl von AVNM-Ressourceninstanzen, wodurch die weitere Demokratisierung der Verwaltung für Gruppen von VNets ermöglicht wird.

VNets in Abonnements, Verwaltungsgruppen oder Regionen unter demselben Azure AD-Mandanten können in Netzwerkgruppen gruppiert werden, um die Einheitlichkeit der erwarteten Konnektivitäts- und Netzwerkregeln sicherzustellen. Das Onboarding virtueller Netzwerke kann über dynamische oder statische Mitgliedschaften automatisch oder manuell in der Netzwerkgruppe durchgeführt werden.

Spoke-VNets in derselben Netzwerkgruppe können miteinander verbunden werden, indem VNet-Peering über die direkte Konnektivitätsfunktion von AVNM aktiviert wird. Um die Funktionen für Spokes in verschiedenen Regionen so zu erweitern, dass sie über direkte Konnektivität verfügen, verwenden Sie das Feature globales Mesh, das das Erstellen globaler VNet-Peerings erleichtert. Siehe nachstehendes Beispieldiagramm:

Diagram showing spoke direct connectivity.

Darüber hinaus können VNets zur Sicherstellung einer Baselinegruppe von Sicherheitsregeln innerhalb derselben Netzwerkgruppe den Sicherheitsadministratorregeln zugeordnet werden. Sicherheitsadministratorregeln werden vor NSG-Regeln ausgewertet und verfügen über dieselbe Art von NSGs, mit Unterstützung für Priorisierung, Diensttags und L3-L4-Protokolle.

Schließlich können Sie zur Erleichterung eines kontrollierten Rollouts von Änderungen an Netzwerkgruppen, Konnektivität und Sicherheitsregeln die Funktion Bereitstellungen von AVNM verwenden, um die Breaking Changes dieser Konfigurationen sicher in die Hub-and-Spoke-Umgebungen freizugeben.

Weitere Informationen zu den ersten Schritten finden Sie unter Erstellen einer Hub-and-Spoke-Topologie mit Azure Virtual Network Manager.

Überlegungen zur Verwendung

Beachten Sie bei der Bereitstellung und Verwaltung von Hub-and-Spoke-Netzwerken folgende Informationen.

Netzwerküberwachung

Verwenden Sie Azure Network Watcher zur Überwachung und Problembehandlung der Netzwerkkomponenten. Tools wie Traffic Analytics zeigen Ihnen die Systeme in Ihren virtuellen Netzwerken, die den meisten Traffic generieren. Dann können Sie Engpässe visuell erkennen, bevor sie zu Problemen ausarten. Der Netzwerkleistungs-Manager ist das richtige Tool zum Überwachen der Informationen zu Microsoft ExpressRoute-Leitungen. Die VPN-Diagnose ist ein weiteres Tool für die Problembehandlung von Site-to-Site-VPN-Verbindungen, die Ihre Anwendungen mit lokalen Benutzern verbinden.

Weitere Informationen finden Sie unter Azure Network Watcher.

Kostenoptimierung

Beachten Sie bei der Bereitstellung und Verwaltung von Hub-and-Spoke-Netzwerken die folgenden kostenbezogenen Punkte.

Azure Firewall

In dieser Architektur wird eine Azure Firewall im Hub-Netzwerk bereitgestellt. Wenn sie als freigegebene Lösung verwendet und von mehreren Workloads genutzt wird, kann eine Azure Firewall im Vergleich zu anderen virtuellen Netzwerkgeräten zwischen 30 und 50 % einsparen. Weitere Informationen finden Sie unter Azure Firewall im Vergleich zum virtuellen Netzwerkgerät.

Peering in virtuellen Netzwerken

Sie können das Peering virtueller Netzwerke nutzen, um Datenverkehr zwischen virtuellen Netzwerken über private IP-Adressen weiterzuleiten. Hier sind einige Punkte aufgeführt:

  • Eingehender und ausgehender Datenverkehr wird an beiden Enden der mittels Peering verknüpften Netzwerke in Rechnung gestellt.
  • Unterschiedliche Zonen verfügen über unterschiedliche Übertragungsraten.

Bei einer Datenübertragung aus einem virtuellen Netzwerk in Zone 1 in ein anderes virtuelles Netzwerk in Zone 2 fällt beispielsweise für Zone 1 die Gebühr für die ausgehende Übertragung und für Zone 2 die Gebühr für die eingehende Übertragung an. Weitere Informationen finden Sie unter Virtual Network – Preise.

Bereitstellen dieses Szenarios

Diese Bereitstellung umfasst ein virtuelles Hub-Netzwerk und zwei Spokes mit Peering. Außerdem werden eine Azure Firewall und ein Azure Bastion-Host bereitgestellt. Optional kann die Bereitstellung auch virtuelle Computer im ersten Spoke-Netzwerk und ein VPN-Gateway umfassen.

Verwenden Sie den folgenden Befehl, um eine Ressourcengruppe für die Bereitstellung zu erstellen. Klicken Sie auf die Schaltfläche Testen, um eine eingebettete Shell zu verwenden.

az group create --name hub-spoke --location eastus

Führen Sie den folgenden Befehl aus, um die Hub-and-Spoke-Netzwerkkonfiguration, VNet-Peerings zwischen Hub und Spoke und einen Bastionhost bereitzustellen. Geben Sie nach entsprechender Aufforderung einen Benutzernamen und das Kennwort ein. Diese Werte können verwendet werden, um auf den virtuellen Computer im Spoke-Netzwerk zuzugreifen.

az deployment group create --resource-group hub-spoke \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den ARM-Vorlagen (Azure Resource Manager), die für die Bereitstellung dieser Lösung verwendet werden.

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

Erkunden Sie die folgenden verwandten Architekturen: