Virtual-WAN-Datenverkehr muss gesteuert werden? Konfiguriere Routing Intent

Der CloudTrips-Virtual-WAN-Hub tauscht automatisch Routen zwischen seinen verbundenen VNets aus. Das schafft Konnektivität, garantiert aber nicht, dass der Datenverkehr eine zentrale Sicherheitskontrolle durchläuft.

Routing Intent legt fest, dass eine gesamte Verkehrskategorie eine Sicherheitslösung im Virtual Hub als Next Hop verwenden muss. Routing Intent steuert den Pfad; die Firewall Policy entscheidet separat, welche Verbindungen zugelassen oder verweigert werden.

Dieser Trip fügt dem vorhandenen Hub eine Azure Firewall hinzu und leitet privaten Datenverkehr darüber. Das Internetrouting bleibt unverändert.

Dieser Trip baut auf folgendem Trip auf: Ein globales Filialnetz benötigt einen Hub? Erstelle Virtual WAN. Wenn du dieses Lab bereits gelöscht hast, führe den vorherigen Trip erneut bis Verwaltete Routen überprüfen aus. Dadurch werden Ressourcengruppe, Virtual WAN, Virtual Hub, zwei Test-VNets und zwei VNet-Verbindungen wiederhergestellt. Führe die Bereinigung nicht aus, bevor du hier fortfährst.

Die beiden Richtlinien verstehen

Routing Intent unterstützt zwei große Verkehrskategorien:

Private traffic
  -> traffic between VNets, branches, and virtual hubs
  -> includes 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 by default

Internet traffic
  -> traffic whose destination is 0.0.0.0/0

CloudTrips konfiguriert nur Private traffic. Der vorgesehene Pfad lautet:

App VNet -> Virtual Hub -> Azure Firewall -> Virtual Hub -> Services VNet

Ohne Routing Intent sendet der verwaltete Hub-Router Datenverkehr direkt zwischen den beiden VNet-Verbindungen. Mit Routing Intent verwaltet Azure die notwendigen Hubrouten automatisch; an keines der Workload-Subnetze wird eine UDR angefügt.

Vorhandenes Hubrouting prüfen

Öffne vwan-cloudtrips-test, wähle Connectivity > Hubs und öffne vhub-cloudtrips-test-weu.

Öffne unter Routing die Route Tables und wähle Default. Der zugrunde liegende Ressourcenname lautet defaultRouteTable. Wähle nicht None; dessen Ressourcenname ist noneRouteTable. Bestätige, dass unter Default keine benutzerdefinierten statischen Routen vorhanden sind. Die unter Effective Routes sichtbaren VNet-Präfixe wurden dynamisch gelernt und müssen nicht entfernt werden.

Eine leere Routenliste auf der Registerkarte Basics ist hier das erwartete Ergebnis. Diese Registerkarte zeigt manuell konfigurierte statische Routen und nicht die von den VNet-Verbindungen dynamisch gelernten Routen. Wähle nicht + Add route. Gelernte Routen werden separat unter Effective Routes angezeigt.

Ändere Propagations in diesem Routingtabellen-Editor nicht. Das Portal kann No und 0 selected anzeigen und diese Werte nach dem Speichern wiederherstellen. Das ist zu erwarten, weil CloudTrips hier keine VPN-, ExpressRoute- oder User-VPN-Branchverbindungen zur Auswahl besitzt. Die beiden VNet-Verbindungen enthalten bereits ihre eigene Routingkonfiguration. Routing Intent verwaltet deren Routenzuordnung und -propagierung später automatisch.

Erstelle keine weitere Routingtabelle; Routing Intent setzt voraus, dass nur die integrierte defaultRouteTable und noneRouteTable vorhanden sind.

Firewall Policy erstellen

Suche im Portal nach Firewall Manager, öffne Azure Firewall Policies und wähle Create Azure Firewall Policy.

Konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-vwan-test-weu
Name: afwp-cloudtrips-vwan-test
Region: West Europe
Policy tier: Basic
Parent policy: None

Verwende Basic für diese kurze Routingübung. Standard oder Premium sind erst erforderlich, wenn ein Workload deren zusätzliche Inspektionsfunktionen benötigt. Füge der Policy keine benutzerdefinierten Regeln hinzu; Azure Firewall verweigert standardmäßig Datenverkehr, auf den keine Regel passt.

Wähle Review + create und danach Create.

Azure Firewall zum Virtual Hub hinzufügen

Kehre zu vhub-cloudtrips-test-weu zurück. Wähle unter Security die Option Azure Firewall and Firewall Manager und danach unten auf der Seite Next: Azure Firewall.

Wähle auf der allgemeinen Firewall-Manager-Seite nicht Create new secured virtual hub. Diese Aktion erstellt einen weiteren Hub. Da vhub-cloudtrips-test-weu bereits geöffnet ist, konvertiert Next: Azure Firewall diesen vorhandenen Hub, indem Azure Firewall darin installiert wird. Der richtige Assistent fragt nach Firewalleinstellungen, aber nicht nach einem weiteren Hubnamen oder Hubadressraum.

Wähle Deploy a firewall with an existing policy. Dadurch wird eine neue Azure Firewall im vorhandenen Virtual Hub bereitgestellt und mit der im vorherigen Schritt erstellten Policy verknüpft. Wähle nicht die Option, die eine weitere Policy erstellt.

Aktiviere Azure Firewall und konfiguriere:

Firewall tier: Basic
Firewall policy: afwp-cloudtrips-vwan-test
Public IP addresses: Keep the minimum offered by the portal

Lass Trusted Security Partners deaktiviert. Prüfe die Konfiguration und starte die Bereitstellung. Azure erstellt die Firewall im von Microsoft verwalteten Hub; AzureFirewallSubnet wird nicht selbst erstellt.

Warte, bis der Hub Secured und der Bereitstellungsstatus der Azure Firewall Succeeded anzeigt. Warte außerdem, bis der Virtual Hub nicht mehr Updating und sein Routingstatus Provisioned ist. Die Bereitstellung kann 20–30 Minuten dauern. Routing Intent darf nicht gespeichert werden, solange der Hub noch aktualisiert wird.

Azure Firewall und der Secured Virtual Hub werden ab der Bereitstellung abgerechnet. Schließe die restlichen Schritte und die Bereinigung in derselben Lab-Sitzung ab.

Der Hub kann Datenverkehr jetzt prüfen. Allein die Installation einer Firewall zwingt die VNet-Verbindungen jedoch noch nicht, sie zu verwenden.

Routing Intent für privaten Datenverkehr konfigurieren

Wähle in vhub-cloudtrips-test-weu Routing > Routing Intent and Routing Policies.

Konfiguriere:

Private traffic: Select the Azure Firewall in vhub-cloudtrips-test-weu
Internet traffic: None

Wähle Save. Warte, bis der Bereitstellungsstatus von Routing Intent Succeeded lautet, bevor du die Routen prüfst. Das Anwenden der verwalteten Routen kann danach noch einige Minuten dauern.

Wenn ein früherer Versuch Failed mit InvalidNextHop anzeigt, lösche diesen fehlgeschlagenen Routing Intent. Bestätige für den Hub den Routingstatus Provisioned und für die Firewall den Status Succeeded. Konfiguriere und speichere Routing Intent danach erneut. Firewall und Firewall Policy müssen nicht neu erstellt werden.

Die Private Policy erfasst beide temporären VNet-Präfixe, weil sie innerhalb von 10.0.0.0/8 liegen. Internetverkehr wird in diesem Trip nicht umgeleitet. Routing Intent fügt daher keine Policy-Route für 0.0.0.0/0 hinzu.

Erzeugte Route prüfen

Öffne unter Routing die Effective Routes und wähle Default (defaultRouteTable). Bestätige, dass die effektiven Routen Folgendes enthalten:

Destinations: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Next hop: Azure Firewall

Das Portal kann die erzeugte Route als _policy_PrivateTraffic, mit einem anderen von der Policy verwalteten Namen oder in der Ansicht Effective Routes ohne Namen darstellen. Der Name ist nicht das Prüfkriterium. Wähle nicht + Add route und erstelle diese Route nicht manuell; Routing Intent verwaltet sie. Wenn die Präfixe nicht sichtbar sind, bestätige für Firewall und Routing Intent jeweils den Status Succeeded, warte einige Minuten und aktualisiere Effective Routes.

Wenn unter Effective Routes nur 10.71.0.0/16 und 10.72.0.0/16 mit dem Next-Hop-Typ Virtual Network Connection erscheinen, ist Routing Intent noch nicht wirksam. Kehre zu Routing Intent and Routing Policies zurück, bestätige die Auswahl für Private Traffic und wähle Save.

Das ist das entscheidende Ergebnis: Routing Intent verwaltet die Zuordnungen und Propagierung der Routen für die VNet-Verbindungen und programmiert Azure so, dass privater Datenverkehr an die Firewall gesendet wird. Wenn die Firewall Policy ein Paket zulässt, leitet Virtual WAN es an das endgültige VNet-Ziel weiter.

Für diesen Trip sind keine VMs erforderlich. Das Ergebnis in der Routingtabelle beweist die Control-Plane-Konfiguration, nicht die End-to-End-Anwendungskonnektivität.

Kostenpflichtiges Lab entfernen

Kehre zuerst zu Routing Intent and Routing Policies zurück, entferne die Auswahl für privaten Datenverkehr und speichere. Warte, bis die Policy entfernt wurde, bevor du ihren Next Hop löschst.

Öffne unter Security die Option Azure Firewall and Firewall Manager und lösche die Azure Firewall aus dem Virtual Hub. Lösche nach der Firewall afwp-cloudtrips-vwan-test.

Wenn das gesamte Virtual-WAN-Lab abgeschlossen ist, lösche beide VNet-Verbindungen, danach vhub-cloudtrips-test-weu und vwan-cloudtrips-test. Lösche abschließend rg-cloudtrips-vwan-test-weu; dadurch werden auch die beiden temporären VNets entfernt.