Ein globales Filialnetz benötigt einen Hub? Erstelle Virtual WAN

CloudTrips hat ein Hub-VNet manuell erstellt. Wenn ein Unternehmen jedoch viele Filialen und Azure-Regionen hinzufügt, wird der separate Betrieb von Gateways, Peerings, Routen und Hubs zunehmend aufwendig.

WAN steht für Wide Area Network (Weitverkehrsnetz): ein Netzwerk, das Standorte über Städte, Länder oder Regionen hinweg verbindet. Azure Virtual WAN ist ein verwalteter Netzwerkdienst, der Azure-VNets, Filialnetze, Remote-Benutzer und ExpressRoute Circuits über von Microsoft verwaltete Hubs verbindet. Ein Virtual Hub ist ein verwaltetes regionales VNet mit integriertem Router. Anders als das normale CloudTrips-Hub-VNet kann sein Router transitive Konnektivität zwischen verbundenen Spokes bereitstellen.

Dieser Trip erstellt ein temporäres Standard Virtual WAN, einen Virtual Hub und zwei Test-VNets in verschiedenen Regionen. Danach wird geprüft, dass der Hub beide VNet-Präfixe lernt. Dafür sind weder physische Filiale, VPN-Gerät, ExpressRoute Provider, Azure Firewall noch VM erforderlich.

Dieser Trip baut auf folgendem Trip auf: Spoke-Netzwerke benötigen einen zentralen Hub? Konfiguriere ein Hub-Spoke-Netzwerk.

Die beiden Hub-Modelle vergleichen

Der vorhandene CloudTrips-Hub wird vom Kunden verwaltet:

Normal hub VNet
  -> you create the VNet, peerings, gateway, routes, and shared services
  -> spoke-to-spoke routing is not automatic

Das neue Lab verwendet einen von Microsoft verwalteten Hub:

Standard Virtual WAN
  -> Microsoft manages the virtual hub and router
  -> connected VNets propagate routes through the hub
  -> multiple regional hubs can form a managed global transit network

Die Virtual-WAN-Ressource ist der globale Container. Jeder Virtual Hub gehört weiterhin zu einer Azure-Region. Ein globales Design erstellt normalerweise Hubs in den Regionen, in denen Filialen und Workloads Konnektivität benötigen.

Temporäres Lab planen

Verwende eine eigene Ressourcengruppe, damit alle kostenpflichtigen Lab-Ressourcen gemeinsam entfernt werden können:

Resource group: rg-cloudtrips-vwan-test-weu
Virtual WAN: vwan-cloudtrips-test
Virtual WAN type: Standard

Virtual hub: vhub-cloudtrips-test-weu
Hub region: West Europe
Hub private address space: 10.70.0.0/23

West Europe VNet: vnet-cloudtrips-vwan-app-test-weu
Address space: 10.71.0.0/16
Subnet: snet-workload (10.71.1.0/24)

North Europe VNet: vnet-cloudtrips-vwan-services-test-neu
Address space: 10.72.0.0/16
Subnet: snet-workload (10.72.1.0/24)

Keiner dieser Bereiche überschneidet sich mit den vorhandenen CloudTrips-Netzwerken. Der /23-Hubbereich reserviert 512 Adressen für die von Microsoft verwaltete Hubinfrastruktur und zukünftige Gateway- oder Sicherheitsdienste. Subnetze in einem Virtual-WAN-Hub werden nicht selbst erstellt.

Ein Virtual Hub wird nach seiner Erstellung auch dann abgerechnet, wenn er kein VPN- oder ExpressRoute Gateway enthält. Schließe Prüfung und Bereinigung in derselben Lab-Sitzung ab.

Standard Virtual WAN erstellen

Suche im Azure-Portal nach Virtual WANs, öffne den Dienst und wähle Create.

Konfiguriere auf Basics:

Subscription: CloudTrips TEST
Resource group: Create new - rg-cloudtrips-vwan-test-weu
Resource group location: West Europe
Name: vwan-cloudtrips-test
Type: Standard

Verwende Standard, weil Basic nur Site-to-Site-VPN-Szenarien unterstützt. Standard bietet den für diese Übung benötigten VNet-zu-VNet-Transit und das verwaltete Routing. Ein Standard Virtual WAN kann später um weitere Konnektivitätsdienste erweitert, aber nicht auf Basic zurückgestuft werden.

Wähle Review + create und danach Create.

Verwalteten Virtual Hub erstellen

Öffne vwan-cloudtrips-test, wähle Connectivity > Hubs und danach New Hub.

Konfiguriere auf Basics:

Region: West Europe
Name: vhub-cloudtrips-test-weu
Hub private address space: 10.70.0.0/23
Virtual hub capacity: Keep the smallest available capacity
Hub routing preference: ExpressRoute

Belasse Hub routing preference auf ExpressRoute. Diese Einstellung ist nur eine Regel für die Routenauswahl: Wenn der Hub später dasselbe Präfix des Unternehmensnetzwerks sowohl über ExpressRoute als auch über VPN lernt, bevorzugt er den ExpressRoute-Pfad. In diesem Trip wird dadurch keine ExpressRoute-Verbindung erstellt oder vorausgesetzt.

Konfiguriere weder Site-to-Site-VPN, Point-to-Site-VPN, ExpressRoute, Azure Firewall noch eine Partner-Network-Appliance. Erstelle den leeren Hub und warte, bis Provisionierungs- und Routingstatus bereit sind. Die Hubbereitstellung kann mehrere Minuten dauern.

Zwei temporäre Spoke-VNets erstellen

Erstelle in Cloud Shell zwei VNets ohne Gateways, Route Server, Peerings oder Workloads:

az network vnet create \
  --resource-group rg-cloudtrips-vwan-test-weu \
  --name vnet-cloudtrips-vwan-app-test-weu \
  --location westeurope \
  --address-prefixes 10.71.0.0/16 \
  --subnet-name snet-workload \
  --subnet-prefixes 10.71.1.0/24

az network vnet create \
  --resource-group rg-cloudtrips-vwan-test-weu \
  --name vnet-cloudtrips-vwan-services-test-neu \
  --location northeurope \
  --address-prefixes 10.72.0.0/16 \
  --subnet-name snet-workload \
  --subnet-prefixes 10.72.1.0/24

Ein VNet kann nur mit einem Virtual-WAN-Hub verbunden sein. Ein verbundenes VNet darf kein eigenes VPN Gateway, ExpressRoute Gateway oder Route Server enthalten. Dieser Trip verwendet deshalb zwei neue, leere VNets, anstatt Peerings, Routen oder Workloads in den vorhandenen CloudTrips-Netzwerken zu ändern. Die Test-VNets können anschließend sicher gelöscht werden.

Beide VNets mit dem Hub verbinden

Öffne vwan-cloudtrips-test und wähle Connectivity > Virtual network connections > Add connection.

Erstelle die erste Verbindung:

Connection name: conn-vhub-to-vwan-app-test-weu
Hubs: vhub-cloudtrips-test-weu
Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-vwan-test-weu
Virtual network: vnet-cloudtrips-vwan-app-test-weu
Propagate to none: No
Associate Route Table: defaultRouteTable
Propagate to labels: Default
Bypass Next Hop IP for workloads within this VNet: No

Füge keine statischen Routen hinzu. Erstelle die Verbindung und wiederhole den Vorgang mit:

Connection name: conn-vhub-to-vwan-services-test-neu
Virtual network: vnet-cloudtrips-vwan-services-test-neu

Behalte dieselbe Standardroutingkonfiguration bei. Warte, bis beide Verbindungen eine erfolgreiche Provisionierung anzeigen.

Diese Verbindungen ähneln Peering, der Virtual-Hub-Router stellt jedoch auch Transit bereit. Jedes VNet kündigt sein Präfix in der Standard-Hub-Routingtabelle an und lernt daraus die anderen verbundenen Präfixe.

Verwaltete Routen überprüfen

Öffne vhub-cloudtrips-test-weu, wähle Routing > Effective Routes und danach defaultRouteTable.

Bestätige, dass der Hub beide Präfixe kennt:

10.71.0.0/16 -> Virtual Network Connection
10.72.0.0/16 -> Virtual Network Connection

Die Next-Hop-Ressourcen sollten die jeweiligen VNet-Verbindungen identifizieren. Dies beweist, dass der verwaltete Hub-Router beide Spokes ohne benutzerdefinierte Routingtabelle oder direktes Peering zwischen den VNets gelernt hat.

Da keine VMs bereitgestellt wurden, prüft dieser Trip die Routenpropagierung und keine Anwendungsverbindung. Eine reale Bereitstellung muss weiterhin Datenverkehr, NSGs, Firewalls, DNS und Application Listener testen.

Kostenpflichtiges Lab entfernen

Öffne in vwan-cloudtrips-test Virtual network connections und lösche beide Verbindungen. Entferne sie auf der Virtual-WAN-Seite und nicht auf den Seiten der einzelnen VNets.

Lösche nach den Verbindungen vhub-cloudtrips-test-weu und danach vwan-cloudtrips-test. Öffne abschließend rg-cloudtrips-vwan-test-weu, wähle Delete resource group, gib den exakten Namen der Ressourcengruppe ein und bestätige die Löschung.

Das Löschen der eigenen Ressourcengruppe entfernt auch die beiden temporären VNets. Die vorhandenen CloudTrips-Hub-Spoke- und VPN-Gateway-Ressourcen in rg-cloudtrips-network-test-weu werden nicht verändert.