Migrieren zu Azure Virtual WAN

Mit Azure Virtual WAN können Unternehmen ihre globale Verbindungstopologie vereinfachen, um von der Skalierbarkeit des globalen Netzwerks von Microsoft zu profitieren. Dieser Artikel enthält technische Details für Unternehmen, die eine Migration von einer vorhandenen, kundenseitig verwalteten Hub-and-Spoke-Topologie zu einem Entwurf durchführen möchten, bei dem von Microsoft verwaltete Virtual WAN-Hubs zum Einsatz kommen.

Unter Architektur mit einem globalen Transitnetzwerk und Azure Virtual WAN werden die Vorteile hervorgehoben, die sich durch Azure Virtual WAN für Unternehmen ergeben, die ein auf die Cloud ausgerichtetes, modernes und globales Unternehmensnetzwerk einführen.

Abbildung: Azure Virtual WAN

Das Hub-and-Spoke-Konnektivitätsmodell des virtuellen Azure-Rechenzentrums wurde von Tausenden unserer Kunden eingeführt, um auf der Grundlage des standardmäßigen transitiven Routingverhaltens von Azure-Netzwerken einfache und skalierbare Cloudnetzwerke aufzubauen. Azure Virtual WAN baut auf diesen Konzepten auf und bietet neue Funktionen, die nicht nur globale Konnektivitätstopologien zwischen lokalen Standorten und Azure unterstützen, sondern Kunden zudem die Möglichkeit geben, die Skalierbarkeit des Microsoft-Netzwerks zur Erweiterung ihrer bestehenden globalen Netzwerke zu nutzen.

In diesem Artikel wird beschrieben, wie Sie eine vorhandene, vom Kunden verwaltete Hub-and-Spoke-Umgebung zu einer auf dem virtuellen Azure-WAN basierenden Topologie migrieren.

Szenario

Contoso ist eine globale Finanzorganisation mit Niederlassungen in Europa und Asien. Das Unternehmen plant, seine vorhandenen Anwendungen von einem lokalen Rechenzentrum nach Azure zu verschieben und hat einen auf der kundenseitig verwalteten Hub-and-Spoke-Architektur basierenden Entwurf ausgearbeitet, der regionale, virtuelle Hubnetzwerke für Hybridkonnektivität einschließt. Im Rahmen der Umstellung auf cloudbasierte Technologien wurde das Netzwerkteam mit der Optimierung der Konnektivität für die weitere Entwicklung des Unternehmens beauftragt.

Die folgende Abbildung zeigt eine allgemeine Übersicht über das vorhandene globale Netzwerk, einschließlich der Anbindung an mehrere Azure-Regionen.

Abbildung: Vorhandene Netzwerktopologie von Contoso

Aus der vorhandenen Netzwerktopologie lassen sich folgende Punkte ableiten:

• Eine Hub-and-Spoke-Topologie wird in mehreren Regionen verwendet, einschließlich ExpressRoute-Verbindungen zur Rückverbindung mit einem allgemeinen privaten WAN.

• Einige dieser Standorte verfügen außerdem über direkte VPN-Tunnel mit Azure, um eine Kommunikation mit Anwendungen zu ermöglichen, die in der Cloud gehostete werden.

Requirements (Anforderungen)

Das Netzwerkteam wurde mit der Bereitstellung eines globalen Netzwerkmodells beauftragt, das die Migration von Contoso in die Cloud unterstützen kann und eine Optimierung in Bezug auf Kosten, Skalierung und Leistung ermöglicht. Zusammengefasst müssen die folgenden Anforderungen erfüllt werden:

• Bereitstellung optimierter Pfade zu in der Cloud gehosteten Anwendungen sowohl für den Hauptstandort als auch für die Zweigstellen.
• Beseitigung der Abhängigkeit von vorhandenen lokalen Rechenzentren zur VPN-Terminierung bei gleichzeitiger Beibehaltung der folgenden Konnektivitätspfade:
  • Branch-to-VNET (B2V) : Mit dem VPN verbundene Niederlassungen müssen auf Anwendungen zugreifen können, die in der lokalen Azure-Region zur Cloud migriert wurden.
  • Branch-to-Hub-to-Hub-to-VNET (B2H2H2V) : Mit dem VPN verbundene Niederlassungen müssen auf Anwendungen zugreifen können, die in der Azure-Remoteregion zur Cloud migriert wurden.
  • Branch-to-Branch (B2B) : Regionale Niederlassungen mit VPN-Verbindung müssen untereinander und mit Haupt-/DC-Standorten mit ExpressRoute-Verbindung kommunizieren können.
  • Branch-to-Hub-to-Hub-to-Branch (B2H2H2B) : Global getrennte Niederlassungen mit VPN-Verbindung müssen untereinander und mit beliebigen Haupt-/DC-Standorten mit ExpressRoute-Verbindung kommunizieren können.
  • Branch-to-Internet (B2I) : Verbundene Standorte müssen mit dem Internet kommunizieren können. Dieser Datenverkehr muss gefiltert und protokolliert werden.
  • VNET-to-VNET (V2V) : Virtuelle Spoke-Netzwerke in derselben Region müssen miteinander kommunizieren können.
  • VNET-to-Hub-to-Hub-to-VNET (V2H2H2V) : Virtuelle Spoke-Netzwerke in unterschiedlichen Regionen müssen miteinander kommunizieren können.
• Contoso-Roamingbenutzer (Laptop und Telefon) müssen auf Unternehmensressourcen zugreifen können, wenn sie sich nicht im Unternehmensnetzwerk befinden.

Azure Virtual WAN-Architektur

Die folgende Abbildung zeigt eine allgemeine Übersicht über die aktualisierte Zieltopologie, in der die im vorherigen Abschnitt beschriebenen Anforderungen mit Azure Virtual WAN erfüllt wurden.

Abbildung: Azure Virtual WAN-Architektur

Zusammenfassung:

• Der Hauptstandort in Europa bleibt über ExpressRoute verbunden, der lokale DC wird vollständig zu Azure migriert und nun außer Betrieb genommen.
• DC und Hauptstandort in Asien bleiben mit dem privatem WAN verbunden. Ab sofort wird Azure Virtual WAN zur Erweiterung des lokalen Anbieternetzwerks und zur Bereitstellung globaler Konnektivität verwendet.
• Sowohl in der Azure-Region „Europa, Westen“ als auch in der Region „Asien, Südosten“ werden Azure Virtual WAN-Hubs eingesetzt, um Konnektivitätshubs für Geräte bereitzustellen, die über ExpressRoute und VPN verbunden sind.
• Hubs bieten außerdem VPN-Terminierung für Roamingbenutzer für mehrere Clienttypen. Die dabei verwendete OpenVPN-Konnektivität mit dem globalen Mesh-Netzwerk ermöglicht nicht nur den Zugriff auf Anwendungen, die zu Azure migriert wurden, sondern auch auf Ressourcen, die in der lokalen Umgebung verbleiben.
• Azure Virtual WAN stellt Internetkonnektivität für Ressourcen innerhalb eines virtuellen Netzwerks bereit.

Azure Virtual WAN stellt ebenso Internetkonnektivität für Remotestandorte bereit. Durch einen lokalen Internet-Breakout via Partnerintegration wird der Zugriff auf SaaS-Dienste wie Microsoft 365 optimiert.

Migrieren zu Virtual WAN

In diesem Abschnitt werden die verschiedenen Schritte für die Migration zu Azure Virtual WAN erläutert.

Schritt 1: Hub-and-Spoke vom Kunden verwaltet in einer einzelnen Region

Die folgende Abbildung zeigt die Topologie einer einzelnen Region für Contoso vor dem Rollout von Azure Virtual WAN:

Abbildung 1: Hub-and-Spoke manuell – Einzelregion

In Anlehnung an den Hub-and-Spoke-Ansatz umfasst das kundenseitig verwaltete virtuelle Hubnetzwerk verschiedene Funktionsblöcke:

• Gemeinsame Dienste (alle gemeinsamen Funktionen, die von mehreren Spokes benötigt werden). Beispiel: Contoso verwendet auf IaaS-VMs (Infrastructure-as-a-Service) Windows Server-Domänencontroller.
• IP-/Routingfirewalldienste werden über eine virtuelle Netzwerkappliance eines Drittanbieters bereitgestellt und ermöglichen ein Spoke-übergreifendes Layer-3-IP-Routing.
• Dienste für eingehenden/ausgehenden Internetdatenverkehr. Hierzu zählen beispielsweise Azure Application Gateway für eingehende HTTP-Anforderungen und Proxydienste von Drittanbietern, die auf VMs ausgeführt werden und den ausgehenden Internetdatenverkehr filtern.
• Das ExpressRoute- und VPN-Gateway für virtuelle Netzwerke sorgt für Konnektivität mit lokalen Netzwerken.

Schritt 2: Bereitstellen von Virtual WAN-Hubs

Stellen Sie in jeder Region ein Virtual WAN-Hub bereit. Richten Sie den Virtual WAN-Hub mit VPN- und ExpressRoute-Funktionen ein, wie in den folgenden Artikeln beschrieben:

• Tutorial: Erstellen einer Site-to-Site-Verbindung per Azure Virtual WAN
• Tutorial: Erstellen einer ExpressRoute-Zuordnung per Azure Virtual WAN

Abbildung 2: Migration von Hub-and-Spoke unter Kundenverwaltung zu Virtual WAN

Schritt 3: Verbinden von Remotestandorten (ExpressRoute und VPN) mit Virtual WAN

Verbinden Sie den Virtual WAN-Hub mit den vorhandenen ExpressRoute-Leitungen, und richten Sie über das Internet Site-to-Site-VPN-Verbindungen mit beliebigen Remotezweigstellen ein.

Abbildung 3: Migration von Hub-and-Spoke unter Kundenverwaltung zu Virtual WAN

An diesem Punkt empfangen lokale Netzwerkgeräte Routen, die dem IP-Adressraum entsprechen, der dem von Virtual WAN verwalteten Hub-VNet zugewiesen wurde. Per VPN-verbundene Remotezweigstellen sehen in dieser Phase zwei Pfade zu beliebigen vorhandenen Anwendungen in den virtuellen Spoke-Netzwerken. Diese Geräte müssen so konfiguriert werden, dass sie auch weiterhin den Tunnel zum kundenseitig verwalteten Hub nutzen können, um während der Übergangsphase ein symmetrisches Routing zu gewährleisten.

Schritt 4: Testen der Hybridkonnektivität über Virtual WAN

Bevor Sie den verwalteten Virtual WAN-Hub für Produktionskonnektivität nutzen, sollten Sie ein virtuelles Spoke-Netzwerk und eine Virtual WAN-VNet-Verbindung einrichten. Stellen Sie sicher, dass die Verbindungen mit dieser Testumgebung über ExpressRoute und Site-to-Site-VPN funktionieren, bevor Sie mit den nächsten Schritten fortfahren.

Abbildung 4: kundenverwaltete Migration von Hub-and-Spoke zu Virtual WAN

Zu diesem Zeitpunkt ist es wichtig zu erkennen, dass sowohl das ursprüngliche, kundenseitig verwaltete virtuelle Hubnetzwerk als auch der neue Virtual WAN-Hub mit derselben ExpressRoute-Verbindung verbunden sind. Dadurch entsteht ein Datenverkehrspfad, der verwendet werden kann, um Spokes in beiden Umgebungen für die Kommunikation zu aktivieren. Beispielsweise durchläuft der Datenverkehr von einem mit dem kundenseitig verwalteten virtuellen Hubnetzwerk verbundenen Spoke die MSEE-Geräte, die für die ExpressRoute-Verbindung verwendet werden. So werden alle über eine VNET-Verbindung mit dem neuen Virtual WAN-Hub verbundenen Spokes erreicht. Dies ermöglicht eine gestaffelte Migration von Spokes in Schritt 5.

Schritt 5: Umstellen der Konnektivität auf Virtual WAN-Hub

Abbildung 5: kundenverwaltete Migration von Hub-and-Spoke zu Virtual WAN

a: Löschen Sie die vorhandenen Peeringverbindungen zwischen den virtuellen Spoke-Netzwerken und dem alten kundenseitig verwalteten Hub. Der Zugriff auf Anwendungen in virtuellen Spoke-Netzwerken ist erst nach Abschluss der Schritte a bis c wieder möglich.

b. Verbinden Sie die virtuellen Spoke-Netzwerke über VNet-Verbindungen mit dem Virtual WAN-Hub.

c. Entfernen Sie alle benutzerdefinierten Routen (User-Defined Routes, UDR), die zuvor in den virtuellen Spoke-Netzwerken für die Spoke-to-Spoke-Kommunikation verwendet wurden. Dieser Pfad wird jetzt durch das dynamische Routing im Virtual WAN-Hub aktiviert.

d. Vorhandene ExpressRoute- und VPN-Gateways im kundenseitig verwalteten Hub werden nun außer Betrieb genommen, um die nächsten Schritte zu ermöglichen.

e. Verbinden Sie den alten kundenseitig verwalteten Hub (virtuelles Hubnetzwerk) über eine neue VNET-Verbindung mit dem Virtual WAN-Hub.

Schritt 6: Alter Hub wird zum Spoke für gemeinsame Dienste.

Wir haben nun unser Azure-Netzwerk überarbeitet, um den Virtual WAN-Hub zum zentralen Punkt in unserer neuen Topologie zu machen.

Figure 6: Customer-managed hub-and-spoke to Virtual WAN migration

Da der Virtual WAN-Hub eine verwaltete Entität ist und die Bereitstellung benutzerdefinierter Ressourcen wie z. B. VMs nicht zulässig ist, ist der Block für gemeinsame Dienste jetzt ein virtuelles Spoke-Netzwerk. Dieses Netzwerk hostet Funktionen wie den eingehenden Internetdatenverkehr über Azure Application Gateway oder eine virtuelle Netzwerkappliance. Der Datenverkehr zwischen der Umgebung für gemeinsame Dienste und virtuellen Back-End-Computern durchläuft nun den von Virtual WAN verwalteten Hub.

Schritt 7: Optimieren der lokalen Konnektivität zur vollständigen Nutzung von Virtual WAN

In diesem Punkt hat Contoso die Migration von Geschäftsanwendungen in die Microsoft Cloud weitgehend abgeschlossen, wobei nur noch wenige Legacyanwendungen auf dem lokalen DC verbleiben.

Abbildung 7: Migration von Hub-and-Spoke unter Kundenverwaltung zu Virtual WAN

Um die vollständige Funktionalität von Azure Virtual WAN nutzen zu können, entscheidet sich Contoso dafür, die zuvor verwendeten lokalen VPN-Verbindungen außer Betrieb zu nehmen. Alle Zweigstellen, die weiterhin auf Hauptstandort- oder DC-Netzwerke zugreifen, können das globale Microsoft-Netzwerk mithilfe des integrierten Transitroutings von Azure Virtual WAN durchqueren.

Endzustand von Architektur und Datenverkehrspfaden

Abbildung: Virtual WAN mit zwei Regionen

Dieser Abschnitt gibt anhand einiger Beispiele für Datenverkehrsflüsse einen Überblick darüber, wie diese Topologie den ursprünglichen Anforderungen entspricht.

Pfad 1

Pfad 1 zeigt den Datenverkehrsfluss von einer Zweigstelle mit S2S-VPN-Verbindung in Asien zum Azure-VNet in der Region „Asien, Südosten“.

Der Datenverkehr wird wie folgt weitergeleitet:

• Die Zweigstelle in Asien ist über resiliente S2S-BGP-fähige Tunnel mit dem Virtual WAN-Hub in der Region „Asien, Südosten“ verbunden.

• Der Virtual WAN-Hub in Asien leitet Datenverkehr lokal an das verbundene VNET weiter.

Pfad 2

Pfad 2 zeigt den Datenverkehrsfluss vom per ExpressRoute verbundenen Hauptstandort in Europa zum Azure-VNet in der Region „Asien, Südosten“.

Der Datenverkehr wird wie folgt weitergeleitet:

• Der Hauptstandort in Europa wird über eine ExpressRoute-Verbindung mit dem Virtual WAN-Hub in der Region „Europa, Westen“ verbunden.

• Die globale Hub-zu-Hub-Konnektivität von Virtual WAN ermöglicht den Transit des Datenverkehrs an ein in der Remoteregion verbundenes VNET.

Pfad 3

Pfad 3 zeigt den Datenverkehrsfluss vom lokalen, mit einem privaten WAN verbundenen Rechenzentrum in Asien zu einer europäischen Zweigstelle mit S2S-Verbindung.

Der Datenverkehr wird wie folgt weitergeleitet:

• Der DC in Asien ist mit einem Netzanbieter für das lokale private WAN verbunden.

• Die ExpressRoute-Verbindung ist lokal im privaten WAN terminiert, das mit dem Virtual WAN-Hub in der Region „Asien, Südosten“ verbunden ist.

• Die globale Hub-zu-Hub-Konnektivität von Virtual WAN ermöglicht den Transit des Datenverkehrs.

Pfad 4

Pfad 4 zeigt den Datenverkehrsfluss von einem Azure-VNet in der Region „Asien, Südosten“ zu einem Azure-VNet in der Region „Europa, Westen“.

Der Datenverkehr wird wie folgt weitergeleitet:

• Die globale Hub-to-Hub-Konnektivität von Virtual WAN ermöglicht einen nativen Transit für alle verbundenen Azure-VNETs, ohne dass eine weitere Benutzerkonfiguration erforderlich ist.

Pfad 5

Pfad 5 zeigt den Datenverkehrsfluss von Roaming-VPN-Benutzern (P2S) zu einem Azure-VNet in der Region „Europa, Westen“.

Der Datenverkehr wird wie folgt weitergeleitet:

• Laptop- und Mobilgerätebenutzer nutzen den OpenVPN-Client für eine transparente Konnektivität mit dem P2S-VPN-Gateway in der Region „Europa, Westen“.

• Der Virtual WAN-Hub in der Region „Europa, Westen“ leitet Datenverkehr lokal an das verbundene VNET weiter.

Sicherheits- und Richtliniensteuerung über Azure Firewall

Contoso hat nun die Konnektivität zwischen allen Zweigstellen und VNets gemäß den zuvor in diesem Artikel beschriebenen Anforderungen sichergestellt. Um die geltenden Anforderungen in Bezug auf Sicherheitssteuerung und Netzwerkisolierung zu erfüllen, muss das Unternehmen den Datenverkehr weiterhin über das Hubnetzwerk trennen und protokollieren. Bisher wurde diese Funktion von einer virtuellen Netzwerkappliance übernommen. Contoso möchte zudem die vorhandenen Proxydienste außer Betrieb nehmen und native Azure-Dienste für die Filterung des ausgehenden Internetdatenverkehrs nutzen.

Abbildung: Azure Firewall in Virtual WAN (geschützter virtueller Hub)

Die folgenden allgemeinen Schritte sind für die Einführung von Azure Firewall in den Virtual WAN-Hubs erforderlich, um einen einheitlichen Ausgangspunkt für die Richtliniensteuerung zu ermöglichen. Weitere Informationen zu diesem Vorgang und zu geschützten virtuellen Hubs finden Sie unter Dokumentation für Azure Firewall Manager.

1. Erstellen Sie eine Azure Firewall-Richtlinie.
2. Verknüpfen Sie die Firewallrichtlinie mit dem Azure Virtual WAN-Hub. Durch diesen Schritt kann der vorhandene Virtual WAN-Hub als geschützter virtueller Hub fungieren und die erforderlichen Azure Firewall-Ressourcen bereitstellen.

Die folgenden Pfade zeigen die Konnektivitätspfade, die durch die Verwendung von geschützten virtuellen Azure-Hubs aktiviert werden:

Pfad 6

Pfad 6 zeigt den sicheren Datenverkehrsfluss für VNets innerhalb derselben Region.

Der Datenverkehr wird wie folgt weitergeleitet:

• Virtuelle Netzwerke, die mit demselben geschützten virtuellen Hub verbunden sind, leiten nun Datenverkehr über Azure Firewall weiter.

• Azure Firewall kann eine Richtlinie auf diese Datenflüsse anwenden.

Pfad 7

Pfad 7 zeigt den Datenverkehrsfluss von einem Azure-VNet zum Internet oder Sicherheitsdienst eines Drittanbieters.

Der Datenverkehr wird wie folgt weitergeleitet:

• Virtuelle Netzwerke, die mit dem geschützten virtuellen Hub verbunden sind, können den Datenverkehr an öffentliche Ziele im Internet senden, indem sie den geschützten Hub als zentralen Punkt für den Internetzugang verwenden.

• Dieser Datenverkehr kann lokal mithilfe von Azure Firewall-FQDN-Regeln gefiltert oder zur Überprüfung an einen Sicherheitsdienst eines Drittanbieters gesendet werden.

Pfad 8

Pfad 8 zeigt den Datenfluss von der Zweigstelle zum Internet oder an den Sicherheitsdienst eines Drittanbieters.

Der Datenverkehr wird wie folgt weitergeleitet:

• Zweigstellen, die mit dem geschützten virtuellen Hub verbunden sind, können den Datenverkehr an öffentliche Ziele im Internet senden, indem sie den geschützten Hub als zentralen Punkt für den Internetzugang verwenden.

• Dieser Datenverkehr kann lokal mithilfe von Azure Firewall-FQDN-Regeln gefiltert oder zur Überprüfung an einen Sicherheitsdienst eines Drittanbieters gesendet werden.

Nächste Schritte

• Erfahren Sie mehr über Azure Virtual WAN.
• Konfigurieren von Virtual WAN für Azure NetApp Files