Azure Hub-and-Spoke: Peering-Routen abschalten, damit der Verkehr durch die Firewall läuft

Das Problem: Die längste Übereinstimmung gewinnt

Azure wählt Routen nach der längsten Präfixübereinstimmung. Im Beispiel von Microsoft ist ein Hub mit 10.0.0.0/16 mit den Spokes 10.1.0.0/16 und 10.2.0.0/16 gepeert. Im Hub entstehen dadurch System-Routen für beide Spokes mit dem nächsten Hop „Virtual network peering“. Eine benutzerdefinierte Route für 10.0.0.0/8 zur Firewall verliert gegen beide.

Die Folge: Verkehr aus dem lokalen Netz, der über das VPN- oder ExpressRoute-Gateway im Hub kommt, geht direkt in die Spokes und nicht durch die Firewall. Die übliche Lösung war bisher eine eigene Route je Spoke in der Routentabelle des GatewaySubnet. Bei vielen Spokes wird das zur Daueraufgabe, und jede vergessene Route ist eine Lücke in der Inspektion.

Was die Preview ändert

Routentabellen haben eine neue Eigenschaft disablePeeringRoute. Mit dem Wert All unterdrückt Azure die System-Routen der Peerings für IPv4 und IPv6, und zwar für unterstützte Workloads in allen Subnetzen, denen die Routentabelle zugeordnet ist. Das Peering selbst bleibt bestehen. Der Standardwert ist None.

Im Beispiel reicht damit eine zusammengefasste Route 10.0.0.0/8 zur Firewall, neue Spokes im selben Adressbereich sind automatisch abgedeckt. Kombiniert mit Advertised Gateway Prefixes lässt sich auch die Ankündigung in Richtung lokales Netz auf wenige zusammengefasste Präfixe reduzieren.

Die Einstellung erzeugt keine Ersatzroute. Fehlt die passende benutzerdefinierte Route, verliert das Subnetz den Weg in die Spokes.

Die Grenzen der Preview

• Firewall oder NVA müssen im selben VNet liegen wie die Netzwerkkarte der Quelle. Ein nächster Hop in einem gepeerten VNet wird nicht unterstützt. In einer klassischen Hub-and-Spoke-Topologie mit Firewall im Hub wirkt die Funktion damit auf Subnetze im Hub wie das GatewaySubnet, nicht auf Subnetze in den Spokes.
• Workloads auf Azure BareMetal Infrastructure ignorieren die Einstellung und routen weiter nach längster Übereinstimmung. Andere unterstützte Workloads im selben Subnetz nutzen die zusammengefassten Routen wie vorgesehen.
• Verwaltet wird die Einstellung an der Routentabelle, nicht über Routing-Regelsammlungen des Azure Virtual Network Manager.
• Terraform unterstützt sie nur über den AzAPI-Provider, nicht über AzureRM. Für REST, ARM und Bicep ist die API-Version 2025-07-01 oder neuer nötig.
• Das Preview-Feature Microsoft.Network/AllowDisablePeeringRoutes muss in der Subscription mit der Routentabelle registriert sein.

Einrichten und prüfen

Mit der Azure CLI sieht die Einrichtung so aus:

az feature register --namespace Microsoft.Network --name AllowDisablePeeringRoutes
az feature show --namespace Microsoft.Network --name AllowDisablePeeringRoutes --query properties.state --output tsv
az provider register --namespace Microsoft.Network

az network route-table update \
  --resource-group "<resource-group>" \
  --name "<route-table-name>" \
  --disable-peering-route All

Der Schritt mit az provider register folgt, sobald der Status Registered lautet. In PowerShell (Az.Network ab Version 8.1.0) wird die Eigenschaft DisablePeeringRoute der Routentabelle auf All gesetzt und mit Set-AzRouteTable gespeichert. Im Portal heißt die Option unter Routentabelle, Konfiguration „Enable peering routes (Preview)“. Rückgängig geht es mit dem Wert None.

Danach die effektiven Routen einer Netzwerkkarte im betroffenen Subnetz prüfen. Einträge mit dem nächsten Hop „Virtual network peering“ sollten für unterstützte Workloads fehlen, die benutzerdefinierte Route zur Firewall sollte greifen.

Worauf ich vor dem Einschalten achten würde

• Zuerst die benutzerdefinierten Routen anlegen und prüfen, dann die Peering-Routen abschalten. In umgekehrter Reihenfolge ist das Subnetz zwischendurch ohne Weg in die Spokes.
• Nicht an der Routentabelle des Firewall-Subnetzes einschalten. Die Firewall selbst braucht die Peering-Routen, um die Spokes zu erreichen.
• Am GatewaySubnet gelten eigene Regeln. Für ExpressRoute-Gateways dokumentiert Microsoft zum Beispiel, dass benutzerdefinierte Routen auf 0.0.0.0/0 dort nicht unterstützt werden. Eine zusammengefasste Route wie 10.0.0.0/8 ist davon nicht betroffen.
• Auf den Rückweg achten. Eine zustandsbehaftete Firewall braucht symmetrischen Verkehr. Läuft der Hinweg durch die Firewall, müssen auch die Routentabellen in den Spokes den Rückweg ins lokale Netz über sie führen.
• Zuerst in einer Test-Subscription ausprobieren. Preview-Funktionen können sich bis zur allgemeinen Verfügbarkeit ändern und unterliegen den ergänzenden Nutzungsbedingungen für Previews.

Effektive Routen gegen den Plan prüfen

Ob der Verkehr in einer gewachsenen Hub-and-Spoke-Umgebung tatsächlich durch die Firewall läuft, zeigt erst der Abgleich von Adressplan, Routentabellen und effektiven Routen. Ein Architekturreview prüft genau das, einschließlich der Frage, ob diese Preview den Pflegeaufwand senkt oder ein anderes Muster besser passt. Die Routenänderungen nimmt Ihr Team vor.