Ein Versorgungsunternehmen möchte, dass der gesamte Spoke-to-Spoke-Datenverkehr über eine zentrale NVA geleitet wird, die im Virtual WAN-Hub bereitgestellt ist. Sie haben versucht, UDRs in den Spoke-VNets mit einem Next Hop zu erstellen, der auf die IP der Hub-Firewall zeigt, aber die Spoke-Subnetze berücksichtigen diese UDRs nicht. Warum geschieht dies und wie kann der Spoke-to-Spoke-Datenverkehr korrekt durch die Hub-NVA erzwungen werden?

UDRs in Spoke-VNets haben keine Auswirkungen auf den Datenverkehr, der über Azure Virtual WAN geroutet wird, da Virtual WAN sein eigenes Routing verwaltet. Um Spoke-zu-Spoke-Verkehr durch eine NVA im Virtual WAN-Hub zu leiten, müssen Sie eine benutzerdefinierte Routingtabelle im Virtual WAN-Hub erstellen. Diese Routingtabelle sollte statische Routen enthalten (z. B. 0.0.0.0/0 für den gesamten ausgehenden Verkehr oder spezifische Routen für Spoke-Netzwerke), die auf die private IP-Adresse der NVA als nächsten Hop verweisen. Anschließend müssen Sie diese benutzerdefinierte Routingtabelle den Spoke-VNet-Verbindungen zuordnen. Dadurch wird sichergestellt, dass der Hub den Datenverkehr von den Spokes zur NVA leitet, bevor er an andere Spokes weitergeleitet wird. Die anderen Optionen sind falsch, weil: UDRs in Spoke-VNets nicht von Azure blockiert werden, aber sie beeinflussen nicht den über Virtual WAN gerouteten Transit. Service Chaining ist kein Ersatz für die Hub-Routingtabelle. BGP ist für dieses Szenario nicht zwingend erforderlich, und statische UDRs im Hub sind die korrekte Methode. Globales VNet-Peering ist nicht erforderlich, da Virtual WAN die Konnektivität zwischen Spokes und dem Hub bereitstellt. UDRs im Hub-VNet sind nicht die primäre Methode; die Hub-Routingtabelle ist entscheidend.