Verwenden Sie die Azure Firewall, um eine Multihub- und Speichenstruktur weiterzuleiten.

Die Hub-and-Spoke-Topologie ist ein gängiges Netzwerkarchitekturmuster in Azure, das Netzwerkressourcen konsolidiert und Netzwerkdienste zentralisiert. Diese Topologie bietet Netzwerkkonnektivität und Sicherheit für virtuelle Netzwerke, die in verschiedenen Abonnements oder Mandanten bereitgestellt werden.

Sie können Hub-and-Spoke-Architekturen auf zwei Arten implementieren:

• Selbstverwaltete Hub-and-Spoke (traditionell): Sie behalten die volle Kontrolle über die virtuellen Hubnetzwerke und die Routingkonfiguration.
• Virtuelles WAN: Microsoft verwaltet die virtuellen Hubnetzwerke und vereinfacht die Verwaltung durch Features wie Routingabsichts- und Routingrichtlinien.

Dieser Artikel konzentriert sich auf self-managed Hub-and-Spoke-Topologien, in denen Sie vollständige Sichtbarkeit und Kontrolle über das virtuelle Hubnetzwerk und die Azure Firewall-Bereitstellung haben.

Sie können den Verwaltungsaufwand einer selbstverwalteten Hub-and-Spoke-Implementierung mithilfe von Azure Virtual Network Manager (AVNM) reduzieren. AVNM kann die Konfiguration von Azure Route Tables automatisieren, aber das allgemeine Design und die Verfahren ändern sich nicht im Vergleich zum manuellen Ansatz. Der Inhalt dieses Artikels gilt, ob Sie AVNM verwenden oder Ihre selbstverwaltete Hub-and-Spoke-Topologie manuell konfigurieren.

Eine Alternative zu Azure Route Tables in den virtuellen Speichennetzwerken besteht darin, Routen in Subnetze mit Azure Route Server einzufügen, wie in der Standardrouteinjektion in virtuellen Speichennetzwerken dokumentiert. Dieses Muster wird jedoch aufgrund der Komplexität, die sich aus der Interaktion zwischen Azure Route Server und VPN oder ExpressRoute virtual network gateways ergeben kann, nicht häufig verwendet.

In einem selbstverwalteten Hub-and-Spoke-Setup:

• Hub: Ein virtuelles Netzwerk, das als zentraler Konnektivitätspunkt zu Ihrem lokalen Netzwerk über VPN, ExpressRoute oder Software-Defined Wide Area Network (SD-WAN) dient. Netzwerksicherheitsgeräte wie Firewalls werden im virtuellen Hubnetzwerk bereitgestellt.
• Spokes: Virtuelle Netzwerke, die eine Peeringverbindung mit dem Hub herstellen und Ihre Workloads hosten.

Für Workloads, die sich über mehrere Regionen verteilen, stellen Sie in der Regel einen Hub pro Region bereit, um den Datenverkehr aus den Speichen in dieser Region zu aggregieren. Das folgende Diagramm zeigt eine Hub-and-Spoke-Architektur in zwei Regionen mit zwei virtuellen Spoke-Netzwerken in jeder Region.

Einzellregionale Hub-and-Spoke-Architektur

Um das Design mit mehreren Regionen zu verstehen, müssen Sie zunächst die Einzelregionenkonzepte verstehen. Das folgende Diagramm zeigt die Routingtabellenkonfiguration für die erste Region:

Berücksichtigen Sie die Routinganforderungen für jeden potenziellen Datenverkehrsfluss im Design mit einer Region, um die benutzerdefinierte Routenkonfiguration zu verstehen:

• Spoke-to-Spoke-Datenverkehr: Spokes sind nicht per Peering miteinander verbunden, und das Peering virtueller Netzwerke ist nicht transitiv. Jede Speiche weiß standardmäßig, wie sie zum virtuellen Hubnetzwerk routet, jedoch nicht zu anderen Speichen. Eine Route für 0.0.0.0/0, die auf alle Spoke-Subnetze angewendet wird, deckt den Spoke-to-Spoke-Datenverkehr ab.
• Spoke-to-Internet-Datenverkehr: Die Route 0.0.0.0/0 in der Spoke-Routingtabelle deckt auch den an das öffentliche Internet gesendeten Datenverkehr ab. Diese Route überschreibt standardmäßig die Systemroute, die in öffentlichen Subnetzen enthalten ist. Weitere Informationen finden Sie unter Standardzugriff in ausgehender Richtung in Azure.
• Internet-zu-Spoke-Datenverkehr: Der Datenverkehr vom Internet zum Spoke durchläuft in der Regel zuerst die Azure Firewall. Azure Firewall hat DNST-Regeln (Destination Network Address Translation) konfiguriert, wodurch auch die Quell-IP-Adresse (Source Network Address Translation oder SNAT) übersetzt wird. Die Spoke-Workloads sehen den Datenverkehr als aus dem Azure Firewall-Subnetz kommend an. Das Peering virtueller Netzwerke erstellt Systemrouten an den Hub (10.1.0.0/24), damit die Spokes wissen, wie Rückgabedatenverkehr geroutet werden soll.
• Datenverkehr zwischen lokaler Umgebung und Spoke sowie Datenverkehr zwischen Spoke und lokaler Umgebung: Betrachten Sie jede Richtung separat:
  • On-premises-zu-Spoke-Datenverkehr: Datenverkehr kommt vom lokalen Firmengelände zum VPN- oder ExpressRoute-Gateway. Mit dem Standardrouting in Azure wird eine Systemroute im GatewaySubnet (und anderen Subnetzen im virtuellen Hubnetzwerk) für jede Speichen erstellt. Sie müssen diese Systemrouten außer Kraft setzen und den nächsten Hop auf die private IP-Adresse der Azure-Firewall festlegen. In diesem Beispiel benötigen Sie zwei Routen in einer Routentabelle, die dem Gateway-Subnetz zugeordnet ist, eine für jede Speichen (10.1.1.0/24 und 10.1.2.0/24). Die Verwendung einer Zusammenfassung, zum Beispiel 10.1.0.0/16, die alle virtuellen Netzwerke umfasst, funktioniert nicht, da die von den virtuellen Netzwerkpeers in das Gateway-Subnetz eingefügten Systemrouten spezifischer sind (/24 im Vergleich zur /16 Zusammenfassung). Diese Routentabelle muss über die Umschaltoption "Gateway-Routen weiterleiten" verfügen (auf "Ja" festgelegt), andernfalls kann das Gatewayrouting unvorhersehbar werden.
  • Datenverkehr zwischen Spoke und lokaler Umgebung: Für die Peerings virtueller Netzwerke zwischen dem Hub und den Spokes muss Gatewaytransit zulassen auf der Hubseite und Remotegateways verwenden auf der Spoke-Seite aktiviert sein. Diese Einstellungen sind erforderlich, damit die VPN- und ExpressRoute-Gateways die Speichenpräfixe über das Border Gateway Protocol (BGP) für lokale Netzwerke ankündigen. Diese Einstellungen bewirken außerdem, dass die Spokes die Präfixe kennen, die standardmäßig von der lokalen Umgebung für Azure angekündigt werden. Da On-Premises-Präfixe spezifischer als die benutzerdefinierte Route 0.0.0.0/0 in der Speichenroutentabelle sind, könnte der Verkehr von den Speichen auf die lokale Umgebung standardmäßig die Firewall umgehen. Um diese Situation zu verhindern, legen Sie die Umschaltfläche Gatewayrouten verteilen in der Spoke-Routingtabelle auf Nein fest, sodass lokale Präfixe nicht erlernt werden und die Route 0.0.0.0/0 für den Datenverkehr zur lokalen Umgebung verwendet wird.

Sie können sowohl die mit den Spoke-Subnetzen verknüpfte Routentabelle als auch die mit dem Gateway-Subnetz verknüpfte Routentabelle mithilfe des Azure Virtual Network Managers verwalten, um den Verwaltungsaufwand zu reduzieren. Weitere Informationen finden Sie unter Verwenden der Azure-Firewall als nächsten Hop.

Workloads für Hub-Virtuelles Netzwerk

Wenn Sie Workloads im virtuellen Hubnetzwerk (z. B. Active Directory-Domänencontroller, DNS-Server oder andere gemeinsam genutzte Infrastruktur) bereitstellen, erhöht dies die Komplexität des Hub-and-Spoke-Designs. Wir empfehlen, dass Sie Workloads nicht im Hub platzieren und stattdessen in einem dedizierten Spoke für gemeinsame Dienste bereitstellen.

In diesem Abschnitt wird die konfiguration beschrieben, die für Hubworkloads erforderlich ist, damit Sie bewerten können, ob diese Komplexität für Ihre Anforderungen akzeptabel ist. Außerdem wird ein häufiger Fehler beschrieben, der asymmetrischen Datenverkehr und Paketabbrüche verursachen kann.

Das folgende Diagramm zeigt eine Einzelregion-Architektur mit einem Workload-Subnetz in einem virtuellen Hubnetzwerk.

Das wichtige Detail besteht darin, dass die benutzerdefinierten Routen, die sowohl im Gatewaysubnetz als auch in den Speichensubnetzen konfiguriert sind, für das spezifische Workload-Subnetz und nicht für das präfix für das gesamte virtuelle Hubnetzwerk definiert sind:

• Gateway-Subnetzkonfiguration: Das Konfigurieren einer Route im Gatewaysubnetz für das gesamte virtuelle Hubnetzwerk (10.1.0.0/24 in diesem Beispiel) setzt die Systemroute für das virtuelle Hubnetzwerk außer Kraft. Dies führt dazu, dass der Datenverkehr zwischen dem VPN- oder ExpressRoute-Gateway innerhalb des Subnetzs an die Firewall gesendet wird, wodurch der Gatewaybetrieb möglicherweise unterbrochen wird.
• Spoke-Subnetzkonfiguration: Die Konfiguration einer Route in den Spoke-Subnetzen für das gesamte virtuelle Hub-Netzwerk (10.1.0.0/24 in diesem Beispiel) setzt die durch das Peering mit dem virtuellen Hub-Netzwerk erstellte Systemroute außer Kraft. Der gesamte Datenverkehr, der an den Hub gesendet wird, wird an die Azure-Firewall gesendet, einschließlich des Datenverkehrs, der von der Azure Firewall selbst stammt, z. B. Internet-zu-Spoke-Datenverkehr, der über die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) geht. Diese Konfiguration führt asymmetrischen Datenverkehr ein und verursacht Paketabbrüche.

Überprüfung des Datenverkehrs zwischen Subnetzen

Im aktuellen Setup wird datenverkehr zwischen Speichen an die Firewall gesendet, aber der intra-spoke-Datenverkehr verbleibt innerhalb des virtuellen Speichennetzwerks und wird mithilfe von Netzwerksicherheitsgruppen gesteuert. Dieses Design betrachtet virtuelle Netzwerke als Sicherheitsgrenze: Die Firewall prüft nur den Datenverkehr, der ausgeht oder in ein virtuelles Netzwerk eintritt.

Um den Datenverkehr zwischen Subnetzen im gleichen virtuellen Speichennetzwerk zu prüfen, ändern Sie die Routentabelle, die den Speichensubnetzen zugeordnet ist, wie im folgenden Diagramm dargestellt:

Im vorherigen Diagramm werden zwei Speichensubnetze in jedem virtuellen Speichennetzwerk eingeführt, und die Routentabellen für die Speichen im virtuellen Netzwerk A2 werden beschrieben. Das Senden von Intersubnetzdatenverkehr an die Firewall erfordert, dass jedes Subnetz über eine separate Routentabelle verfügt, da die zu installierenden Routen in jedem Subnetz unterschiedlich sind.

Für Subnetz A21 benötigen Sie diese beiden zusätzlichen Routen:

• Route zu 10.1.2.0/24: Überschreibt die Systemroute für den Datenverkehr innerhalb des virtuellen Netzwerks. Ohne andere Routen wird der gesamte Verkehr innerhalb des virtuellen Netzwerks an die Azure Firewall gesendet, sogar der Datenverkehr zwischen virtuellen Maschinen im selben Subnetz.
• Route zu 10.1.2.0/26 mit nächstem Hop Virtuelles Netzwerk: Eine Ausnahme von der vorherigen Route, so dass der Datenverkehr innerhalb dieses spezifischen Subnetzes nicht an die Firewall gesendet wird, sondern lokal innerhalb des virtuellen Netzwerks geroutet wird. Diese Route ist spezifisch für jedes Subnetz. Deshalb benötigen Sie eine separate Routentabelle für jedes Subnetz.

SD-WAN Netzwerk-Virtual Appliances

Wenn Sie SD-WAN Virtual Appliances (NVAs) anstelle von VPN- oder ExpressRoute-Gateways verwenden, ist das Design ähnlich, wie im folgenden Diagramm dargestellt:

Es gibt verschiedene Möglichkeiten, SD-WAN NVAs in Azure zu integrieren. Weitere Informationen finden Sie unter SD-WAN Integration in Azure Hub-and-Spoke-Netzwerktopologien. Dieser Artikel zeigt die Integration mit Azure Route Server, einer der am häufigsten verwendeten Methoden zum Weiterleiten von Datenverkehr an SD-WAN Netzwerke. SD-WAN-NVAs kündigen die lokalen Präfixe über BGP an den Azure Route Server an. Azure Route Server fügt diese Präfixe in das Azure Firewall-Subnetz ein, sodass azure Firewall Routinginformationen für lokale Netzwerke enthält. Die Spokes erlernen die lokalen Präfixe nicht, da die Option „Gatewayrouten verteilen“ in der Spoke-Routingtabelle deaktiviert ist.

Wenn Sie das Präfix der einzelnen virtuellen Spoke-Netzwerke in der Routingtabelle für das NVA-Subnetz nicht konfigurieren möchten, können Sie die SD-WAN-NVAs in ihrem dedizierten virtuellen Netzwerk platzieren. Das virtuelle NVA-Netzwerk erlernt die Spoke-Präfixe nicht, da sie nicht direkt per Peering verbunden sind. Eine Zusammenfassungsroute wie im folgenden Diagramm dargestellt ist möglich:

Multiregion-Hub-and-Spoke-Architektur

Nachdem Sie verstanden haben, wie der Datenverkehr innerhalb einer einzelnen Hub-and-Spoke-Region funktioniert, ist die Erweiterung des Designs auf eine Architektur mit mehreren Regionen einfach. Das folgende Diagramm zeigt ein aktualisiertes Netzwerkdesign mit Hubs in zwei Regionen (A und B):

Die einzige Ergänzung zur Konfiguration sind die Routentabellen, die den Azure Firewall-Subnetzen in den einzelnen Regionen zugeordnet sind. Jedes virtuelle Hubnetzwerk kennt nur die Präfixe der direkt vernetzten virtuellen Netzwerke, daher gibt es kein Routing für die Präfixe der entfernten Speichen. Fügen Sie benutzerdefinierte Routen für jedes Azure Firewall-Subnetz hinzu, damit datenverkehr für jede Region an die entsprechende Azure-Firewall weitergeleitet wird.

In diesem Beispiel kann jede Region ganz einfach zusammengefasst werden:

• Region A enthält Präfixe in 10.1.0.0/16
• Region B enthält Präfixe in 10.2.0.0/16

Durch das Definieren von IP-Adressen in jeder Region, die einfach zusammengefasst werden, wird die Routingkonfiguration vereinfacht. Andernfalls müssen Sie für jeden Remote-Spoke eine Route erstellen.

Aktivieren Sie Verteilungsgatewayrouten in der Azure Firewall-Subnetzroutentabelle, damit die Firewall lokale Routen von VPN- und ExpressRoute-Gateways lernen kann.

Um die Verwaltung von benutzerdefinierten Routen in einer Umgebung mit mehreren Regionen zu vereinfachen, können Sie Azure Virtual Network Manager verwenden. Weitere Informationen finden Sie unter Verwalten von benutzerdefinierten Routen über mehrere Hub-and-Spoke-Topologien mit AVNM.

Nächste Schritte

• Erfahren Sie, wie Sie eine Azure Firewall bereitstellen und konfigurieren.