Netzwerk braucht Firewall-Inspektion? Erstelle Azure Firewall

Das CloudTrips-Anwendungssubnetz kann sich über NAT Gateway mit dem Internet verbinden, aber NAT übersetzt nur Adressen. Es entscheidet nicht, welche Ziele oder Protokolle die Workloads verwenden dürfen.

Stelle Azure Firewall als zentralen Netzwerksicherheitsdienst bereit. Füge danach eine benutzerdefinierte Route hinzu, damit internetgebundener Datenverkehr aus snet-app die Firewall passieren muss. Azure Firewall ist zustandsbehaftet: Sie bewertet eine Verbindung einmal und erkennt den zugehörigen Antwortverkehr automatisch.

Dieser Trip baut auf Ein Admin braucht sicheren VM-Zugriff? Erstelle Azure Bastion auf. Behalte oder erstelle dessen private VM und Bastion-Developer-Verbindung für den Abschlusstest erneut.

Der Pfad wird zu:

VM in snet-app -> Routentabelle -> Azure Firewall -> Internet

Azure Firewall verweigert Datenverkehr, auf den keine Allow-Regel zutrifft. Dieser Trip nutzt dieses Default-Deny-Verhalten, um nachzuweisen, dass die Firewall im Pfad liegt. Der nächste Trip erstellt eine zentral verwaltete Firewall Policy und erlaubt ein genehmigtes Ziel.

Azure Firewall Standard ist ab der Bereitstellung kostenpflichtig. Schließe diesen und den folgenden Firewall-Policy-Trip in derselben Lab-Sitzung ab oder führe am Ende dieses Trips die Bereinigung durch.

Entferne den vorherigen NAT-Pfad

Falls natgw-cloudtrips-app-test-weu noch snet-app zugeordnet ist, öffne:

Virtual networks > vnet-cloudtrips-test-weu > Subnets > snet-app

Setze NAT gateway auf None und speichere. Lösche natgw-cloudtrips-app-test-weu und pip-cloudtrips-nat-test-weu, wenn sie nicht mehr benötigt werden.

NAT Gateway und Azure Firewall sind beide gültige ausgehende Designs, aber diese Übung braucht einen eindeutigen Egress-Pfad. Die Firewall stellt für ausgehende Verbindungen eine eigene öffentliche IP bereit.

Erstelle das erforderliche Firewall-Subnetz

Azure Firewall muss in einem dedizierten Subnetz mit dem exakten Namen AzureFirewallSubnet bereitgestellt werden. Azure erkennt diesen reservierten Namen und verwendet das Subnetz für die verwalteten Firewall-Instanzen. Das Subnetz muss /26 oder größer sein, damit Azure genügend Adressen für Skalierung und Wartung hat.

Öffne vnet-cloudtrips-test-weu, wähle Settings > Subnets und danach + Subnet. Konfiguriere:

Subnet purpose/template: Azure Firewall
Name: AzureFirewallSubnet
Starting address: 10.20.3.0
Subnet size: /26

Ordne weder NSG noch Routentabelle, NAT Gateway, Service Endpoint oder Subnetzdelegation zu. Wähle Add oder Save.

10.20.3.0/26 liegt im VNet-Adressraum 10.20.0.0/16 und überschneidet sich nicht mit snet-app oder snet-data.

Stelle Azure Firewall bereit

Wähle im Azure-Portal Create a resource, suche nach Firewall und wähle Create.

Konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: afw-cloudtrips-test-weu
Region: West Europe
Availability options: No infrastructure redundancy required
Firewall SKU: Standard
Firewall management: Use classic firewall rules
Virtual network: Use existing
Virtual network name: vnet-cloudtrips-test-weu
Public IP address: Create new
Public IP name: pip-cloudtrips-afw-test-weu
Enable Firewall Management NIC: Disabled

Wenn die Validierung meldet, dass Force Tunneling ein AzureFirewallManagementSubnet erfordert, kehre zur Firewall-Konfiguration zurück und deaktiviere Enable Firewall Management NIC beziehungsweise setze Force Tunneling auf Disabled. Erstelle für diese Übung kein AzureFirewallManagementSubnet.

Die später hinzugefügte Route zwingt Workload-Datenverkehr aus snet-app zur Azure Firewall. Force Tunneling von Azure Firewall ist eine andere Funktion: Sie sendet den eigenen internetgebundenen Datenverkehr der Firewall an einen weiteren Next Hop, beispielsweise eine lokale Firewall, und benötigt deshalb ein separates Management-Subnetz.

Falls das Portal die Firewall-Verwaltung als Policy-Auswahl darstellt, wähle None (use classic firewall rules). Erstelle noch keine Regeln; der nächste Trip ersetzt die klassische Verwaltung durch eine zentrale Firewall Policy.

Füge unter Tags hinzu:

Application: CloudTrips
Environment: TEST
Purpose: NetworkInspection

Wähle Review + create und danach Create. Die Bereitstellung kann einige Minuten dauern.

Öffne afw-cloudtrips-test-weu und warte, bis der Bereitstellungsstatus Succeeded ist. Notiere die Private IP address für den nächsten Schritt. Die öffentliche IP wird für diesen Test nicht benötigt.

Das Erstellen der Firewall leitet Workload-Datenverkehr nicht automatisch um. Die Subnetzroute muss sie ausdrücklich als nächsten Hop auswählen.

Route den Anwendungs-Egress durch die Firewall

Öffne rt-cloudtrips-app-test-weu, die bereits snet-app zugeordnete Routentabelle. Wähle Settings > Routes > Add und konfiguriere:

Route name: Default-To-Azure-Firewall
Destination type: IP Addresses
Destination IP addresses/CIDR ranges: 0.0.0.0/0
Next hop type: Virtual appliance
Next hop address: Die private IP von afw-cloudtrips-test-weu

Wähle Add.

0.0.0.0/0 entspricht IPv4-Zielen, wenn keine spezifischere Route vorhanden ist. In einer Routentabelle bedeutet Virtual appliance: „Sende den Datenverkehr zur Verarbeitung oder Weiterleitung an diese private IP.“ Der Next Hop kann eine Firewall-VM, Router-VM, eine Network Virtual Appliance eines Drittanbieters oder Azure Firewall sein. Azure Firewall gehört zu dieser Routenkategorie, ist aber ein von Microsoft verwalteter Dienst: Du verwaltest Policies und Regeln und nicht die zugrunde liegenden VMs.

Die bestehende Route Block-Future-Services ist spezifischer als die Standardroute und verwirft weiterhin 10.30.0.0/16.

Überprüfe Default Deny

Erstelle die VM neu, wenn du sie gelöscht hast

Starte vm-cloudtrips-bastion-test-weu, falls sie nur freigegeben ist. Wenn du sie nach dem Bastion-Trip gelöscht hast, erstelle im Azure-Portal einen Ersatz mit:

Resource group: rg-cloudtrips-network-test-weu
Name: vm-cloudtrips-bastion-test-weu
Region: West Europe
Availability option: Availability zone
Zone: 3
Security type: Standard
Image: Ubuntu Server 24.04 LTS - x64 Gen2
Size: Standard_D2s_v3
Authentication type: Password
Username: azureuser
Password: Erstelle ein temporäres starkes Passwort
Public inbound ports: None

Verwende unter Disks eine Standard SSD und aktiviere das Löschen des OS-Datenträgers zusammen mit der VM. Konfiguriere unter Networking:

Virtual network: vnet-cloudtrips-test-weu
Subnet: snet-app
Public IP: None
NIC network security group: None
Delete NIC when VM is deleted: Enabled

Füge die Tags Application: CloudTrips, Environment: TEST und Purpose: FirewallTest hinzu. Wähle Review + create, danach Create, und warte, bis die VM läuft. Der vorherige Bastion-Trip erklärt, warum diese private VM ohne öffentliche IP administriert werden kann.

Teste über Bastion

Verbinde dich über Connect > Bastion und führe aus:

curl --connect-timeout 10 -I http://www.microsoft.com

Das erwartete Ergebnis ist eine von der Firewall erzeugte Blockantwort wie:

HTTP/1.1 470 status code 470

Status 470 ist keine erfolgreiche Antwort von www.microsoft.com. Azure Firewall gibt ihn für diese verweigerte HTTP-Anfrage zurück, weil keine passende Allow-Regel existiert.

Die Antwort ist der erwartete Nachweis und keine defekte Bereitstellung. Die UDR sendet die Verbindung an Azure Firewall, und das Default-Deny-Verhalten der Firewall blockiert sie, weil keine Regel das Ziel erlaubt.

Fortfahren oder bereinigen

Wenn du sofort mit dem Firewall-Policy-Trip fortfährst, gib die VM frei und behalte Firewall, öffentliche IP, AzureFirewallSubnet und die Route Default-To-Azure-Firewall.

Andernfalls lösche zuerst Default-To-Azure-Firewall aus rt-cloudtrips-app-test-weu, damit snet-app keine Route zu einem fehlenden nächsten Hop behält. Lösche danach in dieser Reihenfolge:

afw-cloudtrips-test-weu
pip-cloudtrips-afw-test-weu
AzureFirewallSubnet
vm-cloudtrips-bastion-test-weu und Datenträger/NIC

Behalte VNet, Anwendungssubnetz, NSG und Routentabelle für spätere Networking-Trips.