Azure Networking im Detail: VNets, Subnets und NSGs richtig planen

Warum Azure Networking so oft schiefgeht

Die meisten Azure-Probleme, die im Ticket landen, sind keine Compute- oder Storage-Probleme – es ist das Netzwerk. Eine VM ist nicht erreichbar, ein Private Endpoint loest nicht auf, zwei VNets sehen sich trotz Peering nicht, oder eine NSG-Regel, die “eigentlich” passen sollte, greift nicht. Das Tuecke dabei: Azure Networking sieht auf den ersten Blick simpel aus (ein VNet, ein paar Subnetze, eine Firewall-Regel-Tabelle), ist aber in der Tiefe voller Fallstricke, die erst bei der zweiten oder dritten Subscription richtig wehtun.

Dieser Artikel geht ueber die Grundlagen hinaus, die du schon aus Azure – Grundlagen fuer IT-Allrounder kennst. Ziel ist, dass du ein VNet-Konzept fuer ein wachsendes KMU sauber planst, NSG-Prioritaeten nicht mehr rätst, sondern verstehst, und wenn eine Verbindung blockiert wird, in fuenf Minuten den Grund findest statt zwei Stunden zu debuggen.

VNet-Adressraum-Planung: Die Entscheidung, die du nicht rueckgaengig machen kannst

Ein Azure Virtual Network bekommt beim Erstellen einen Adressraum in CIDR-Notation, zum Beispiel 10.10.0.0/16. Das klingt nach einer Kleinigkeit – ist aber die wichtigste Entscheidung im ganzen Projekt, weil du den Adressraum eines VNets nachtraeglich nur eingeschraenkt aendern kannst (zusaetzliche, nicht ueberlappende Bereiche hinzufuegen geht, ein bestehendes Netz “umziehen” nicht ohne Neuaufbau von Ressourcen).

RFC1918-Bereiche und was Azure zusaetzlich einschraenkt

Fuer private Adressraeume gilt weiterhin RFC1918:

Azure reserviert in jedem Subnetz die ersten vier und die letzte Adresse fuer eigene Zwecke (Netzwerkadresse, Default Gateway, zwei DNS-Mapping-Adressen, Broadcast). Ein /24-Subnetz mit 256 Adressen liefert dir also nur 251 nutzbare IPs – bei kleinen Subnetzen (/28 mit 16 Adressen -> nur 11 nutzbar) faellt das richtig ins Gewicht.

Praxis-Empfehlung fuer KMU

Fuer ein Schweizer KMU mit Wachstumsperspektive (mehrere Standorte, evtl. spaeter Azure Virtual WAN oder ExpressRoute) hat sich folgendes Muster bewaehrt:

• Reserviere pro Region/Umgebung einen eigenen /16-Block aus 10.0.0.0/8, z.B. 10.10.0.0/16 fuer Produktion Schweiz Nord, 10.20.0.0/16 fuer Test.
• Dokumentiere die Zuteilung zentral (IPAM-Tabelle, auch eine simple Excel-Liste reicht am Anfang) – siehe dazu auch IT-Dokumentation und Inventar.
• Plane grosszuegig: Ein /16 kostet nichts extra, aber ein zu kleiner Adressraum bedeutet spaeter Migrationsaufwand.
• Reserviere von Anfang an einen Block fuer Container-Workloads (AKS-Subnetze sind adressraum-hungrig, da jeder Pod oft eine eigene IP bekommt bei Azure CNI).

# VNet mit durchdachtem Adressraum erstellen
az network vnet create `
  --resource-group "RG-Network-Prod" `
  --name "VNet-CH-Prod" `
  --address-prefix "10.10.0.0/16" `
  --location "switzerlandnorth" `
  --subnet-name "snet-gateway" `
  --subnet-prefix "10.10.0.0/27"

Subnetting: Mehr als nur IP-Bereiche zerschneiden

Klassisches Subnetting

Innerhalb des /16-VNets teilst du in funktionale Subnetze auf. Ein realistisches Schema fuer eine Hub- oder Spoke-VNet sieht so aus:

Delegierte Subnetze

Manche Azure-PaaS-Dienste “injizieren” sich direkt in dein VNet und brauchen dafuer ein delegiertes Subnetz – das Subnetz wird exklusiv fuer diesen Dienst reserviert. Wichtige Beispiele:

# Verfuegbare Delegationen fuer eine Region auflisten
az network vnet subnet list-available-delegations `
  --resource-group "RG-Network-Prod" `
  --output table

# Subnetz fuer SQL Managed Instance delegieren
az network vnet subnet update `
  --resource-group "RG-Network-Prod" `
  --vnet-name "VNet-CH-Prod" `
  --name "snet-sqlmi" `
  --delegations "Microsoft.Sql/managedInstances"

NSG-Regeln und Prioritaeten: Wie Azure wirklich entscheidet

Eine Network Security Group ist eine zustandsbehaftete (stateful) Filterliste. Stateful heisst: Antwortverkehr auf eine erlaubte ausgehende Verbindung wird automatisch zurueckgelassen, du musst dafuer keine explizite Inbound-Regel schreiben.

Der Regel-Algorithmus

Fuer jedes Paket prueft Azure die Regeln nach Prioritaet aufsteigend (niedrigere Zahl = wird zuerst geprueft, Bereich 100–4096) und wendet die erste passende Regel an – danach wird nicht weitergesucht. Reihenfolge in der Portal-Liste spielt keine Rolle, nur die Prioritaetszahl zaehlt.

Jede NSG hat sechs unveraenderliche Standardregeln, die du nicht loeschen, aber durch Regeln mit niedrigerer Prioritaetszahl (= hoeherer Prioritaet) uebersteuern kannst:

Das erklaert einen klassischen “Aha-Moment”: Zwei VMs im selben VNet erreichen sich per Default gegenseitig, auch ohne eine einzige eigene Regel – weil AllowVnetInBound das schon erlaubt. Willst du das unterbinden (Micro-Segmentierung zwischen Subnetzen), musst du explizit eine Deny-Regel mit niedrigerer Prioritaetszahl als 65000 setzen.

NSG auf Subnetz- vs. NIC-Ebene

Du kannst eine NSG einem Subnetz, einer einzelnen Netzwerkkarte (NIC) oder beidem zuweisen. Wenn beide vorhanden sind, muessen Regeln aus beiden NSGs den Traffic erlauben, damit er durchkommt – bei Inbound wird zuerst die Subnetz-NSG, dann die NIC-NSG geprueft (und umgekehrt bei Outbound). Das ist der zweithaeufigste Grund fuer “die Regel ist doch da, trotzdem blockiert”.

Praxisbeispiel: Drei-Tier-Segmentierung

# Web-Tier: HTTPS von aussen erlauben, Rest verweigern
az network nsg rule create `
  --resource-group "RG-Network-Prod" `
  --nsg-name "NSG-Web" `
  --name "Allow-HTTPS-Inbound" `
  --priority 100 `
  --direction Inbound `
  --protocol Tcp `
  --source-address-prefixes Internet `
  --destination-port-ranges 443 `
  --access Allow

# App-Tier: nur vom Web-Subnetz erreichbar, sonst nichts
az network nsg rule create `
  --resource-group "RG-Network-Prod" `
  --nsg-name "NSG-App" `
  --name "Allow-From-Web-Subnet" `
  --priority 100 `
  --direction Inbound `
  --protocol Tcp `
  --source-address-prefixes "10.10.1.0/24" `
  --destination-port-ranges 8443 `
  --access Allow

az network nsg rule create `
  --resource-group "RG-Network-Prod" `
  --nsg-name "NSG-App" `
  --name "Deny-VNet-Rest" `
  --priority 200 `
  --direction Inbound `
  --protocol "*" `
  --source-address-prefixes VirtualNetwork `
  --destination-port-ranges "*" `
  --access Deny

Die Regel Deny-VNet-Rest mit Prioritaet 200 uebersteuert die Default-Regel AllowVnetInBound (65000), weil sie eine niedrigere Zahl hat und damit zuerst gepruegt wird. So verhinderst du, dass jede beliebige VM im VNet direkt auf den App-Tier zugreift, ausser dem explizit erlaubten Web-Subnetz.

Service Endpoints vs. Private Endpoints

Beides loest dasselbe Grundproblem – PaaS-Dienste (Storage Account, SQL Database, Key Vault) sicher aus dem VNet heraus erreichen, ohne ueber das oeffentliche Internet zu gehen –, aber auf technisch unterschiedliche Weise. Die Verwechslung der beiden ist einer der haeufigsten Architekturfehler in KMU-Azure-Umgebungen.

Wann was einsetzen?

• Service Endpoint: Schnelle, kostenlose Absicherung fuer Szenarien, in denen der Zugriff ausschliesslich aus demselben VNet/derselben Region kommt und kein Hybrid-Zugriff noetig ist. Gut fuer einfache Setups, aber Achtung: Der Storage Account bleibt technisch trotzdem oeffentlich erreichbar, du schraenkst nur ein, welche Quellen zugelassen sind (per Firewall-Regel im Dienst selbst).
• Private Endpoint: Der heutige Standardansatz fuer produktive, sicherheitskritische Workloads – besonders wenn Compliance-Vorgaben (DSGVO/nDSG) verlangen, dass Daten nie ueber ein oeffentliches Netz-Interface erreichbar sind. Siehe dazu auch DSGVO/nDSG in der IT-Praxis.

# Private Endpoint fuer einen Storage Account erstellen
az network private-endpoint create `
  --resource-group "RG-Network-Prod" `
  --name "pe-storage-backup" `
  --vnet-name "VNet-CH-Prod" `
  --subnet "snet-pe" `
  --private-connection-resource-id "/subscriptions/<sub-id>/resourceGroups/RG-Backup/providers/Microsoft.Storage/storageAccounts/firmabkp2026" `
  --group-id "blob" `
  --connection-name "conn-storage-backup"

# Private DNS Zone verknuepfen (automatische Registrierung)
az network private-endpoint dns-zone-group create `
  --resource-group "RG-Network-Prod" `
  --endpoint-name "pe-storage-backup" `
  --name "default-zone-group" `
  --private-dns-zone "/subscriptions/<sub-id>/resourceGroups/RG-Network-Prod/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net" `
  --zone-name "blob"

VNet Peering und Hub-Spoke-Topologie

Peering-Grundlagen

VNet Peering verbindet zwei VNets ueber das Azure-Backbone – kein Gateway noetig, geringe Latenz, hoher Durchsatz. Wichtige Eigenschaften, die immer wieder zu Ueberraschungen fuehren:

• Peering ist nicht transitiv. Wenn VNet A mit B gepeert ist und B mit C, sieht A trotzdem C nicht automatisch. Fuer Spoke-zu-Spoke-Kommunikation brauchst du entweder direkte Peerings zwischen den Spokes oder Routing ueber eine zentrale Firewall/NVA im Hub (User Defined Routes).
• Adressraeume duerfen sich nicht ueberlappen. Peering zwischen zwei VNets mit gleichem oder ueberlappendem CIDR ist schlicht nicht moeglich.
• Peering ist bidirektional zu konfigurieren. Du legst auf jeder Seite ein Peering-Objekt an; beide muessen “Connected” zeigen.
• Ein Hub kann bis zu 500 Peering-Verbindungen halten (Standard-Limit), mit Azure Virtual Network Manager sind es bis zu 1000 Spokes.

Hub-Spoke-Topologie

Die Hub-Spoke-Architektur ist der De-facto-Standard fuer Umgebungen mit mehr als einem VNet:

                    ┌─────────────────────────┐
                    │      Hub-VNet            │
                    │  10.10.0.0/16            │
                    │                          │
                    │  - Azure Firewall        │
                    │  - VPN/ER Gateway        │
                    │  - Azure Bastion         │
                    │  - Zentrale DNS-Resolver │
                    └──────────┬───────────────┘
                     Peering   │   Peering
              ┌────────────────┼────────────────┐
              │                                  │
    ┌─────────▼─────────┐            ┌───────────▼────────┐
    │  Spoke-Prod        │            │  Spoke-Test         │
    │  10.20.0.0/16       │            │  10.30.0.0/16        │
    │  App- und Data-Tier │            │  Test-Workloads      │
    └─────────────────────┘            └──────────────────────┘

Grundregeln fuer eine saubere Hub-Spoke-Umgebung:

1. Der Hub enthaelt nur geteilte Infrastruktur (Firewall, Gateways, Bastion, DNS) – keine Applikations-Workloads.
2. Jeder Spoke hat sein eigenes Peering zum Hub, “Allow Forwarded Traffic” und “Allow Gateway Transit” werden je nach Bedarf aktiviert.
3. Spoke-zu-Spoke-Traffic wird per User Defined Route (UDR) ueber die Firewall im Hub gezwungen (“Force Tunneling”), damit du zentral filtern und loggen kannst.
4. On-Premise-Anbindung (VPN/ExpressRoute) landet ausschliesslich im Hub, Spokes nutzen “Gateway Transit”, statt eigene Gateways zu bauen.

# Peering vom Hub zum Spoke anlegen
az network vnet peering create `
  --resource-group "RG-Network-Hub" `
  --name "Hub-to-SpokeProd" `
  --vnet-name "VNet-Hub" `
  --remote-vnet "VNet-Spoke-Prod" `
  --allow-vnet-access `
  --allow-forwarded-traffic `
  --allow-gateway-transit

# Peering vom Spoke zum Hub anlegen (Gegenrichtung, use-remote-gateways)
az network vnet peering create `
  --resource-group "RG-Network-Spoke-Prod" `
  --name "SpokeProd-to-Hub" `
  --vnet-name "VNet-Spoke-Prod" `
  --remote-vnet "VNet-Hub" `
  --allow-vnet-access `
  --allow-forwarded-traffic `
  --use-remote-gateways

Effective Security Rules: So findest du den wahren Grund einer Blockade

Wenn eine Verbindung nicht funktioniert und du nicht sofort siehst, warum, ist die Effective-Security-Rules-Ansicht dein wichtigstes Werkzeug. Sie zeigt dir die tatsaechlich wirksame Kombination aus Subnetz-NSG, NIC-NSG und allen Default-Regeln fuer eine konkrete Netzwerkkarte – nicht nur, was du selbst konfiguriert hast.

# Effective Security Rules fuer eine NIC abrufen
az network nic list-effective-nsg `
  --resource-group "RG-Prod" `
  --name "vm-appserver01-nic" `
  --output table

Voraussetzungen, damit der Befehl ueberhaupt etwas liefert:

• Die VM muss laufen (nicht deallocated).
• Es muss mindestens eine NSG auf Subnetz- oder NIC-Ebene zugewiesen sein.

Systematisches Troubleshooting-Vorgehen

Wenn eine Verbindung blockiert wird, arbeite diese Schritte der Reihe nach ab, statt wild an Regeln herumzuschrauben:

1. Effective Security Rules pruefen (az network nic list-effective-nsg) – zeigt dir die tatsaechlich aktive Regel, inklusive Herkunft (Subnetz- oder NIC-NSG).
2. NSG-Flow-Logs auswerten (ueber Network Watcher / Traffic Analytics), um zu sehen, ob und welche Regel ein konkretes Paket tatsaechlich getroffen hat.
3. Network Watcher “IP Flow Verify” nutzen – simuliert ein einzelnes Paket und sagt dir direkt, welche Regel (Name + Prioritaet) es blockiert oder erlaubt.
4. Routing pruefen (Effective Routes) – oft liegt das Problem gar nicht an der NSG, sondern an einer UDR, die den Traffic falsch umleitet (z.B. Force-Tunneling ueber eine Firewall, die den Rueckweg nicht kennt).
5. DNS-Aufloesung verifizieren, besonders bei Private Endpoints – siehe Callout weiter oben.

# IP Flow Verify: Simuliert ein Paket und zeigt, welche Regel greift
az network watcher test-ip-flow `
  --resource-group "RG-Prod" `
  --vm "vm-appserver01" `
  --direction Inbound `
  --protocol Tcp `
  --local "10.10.1.4:8443" `
  --remote "10.10.1.10:51000"

# Effective Routes pruefen (fuer Routing-Probleme statt NSG)
az network nic show-effective-route-table `
  --resource-group "RG-Prod" `
  --name "vm-appserver01-nic" `
  --output table

Fuer tiefergehende Analysen mit Flow-Logs plus Log Analytics eignet sich eine KQL-Abfrage wie diese, um alle abgelehnten Verbindungen der letzten Stunde auf einer bestimmten NSG zu finden:

AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| where FlowStatus_s == "D"
| where TimeGenerated > ago(1h)
| where NSGList_s contains "NSG-App"
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, L4Protocol_s, NSGRule_s
| order by TimeGenerated desc

Entscheidungsbaum: Welchen Ansatz fuer den Zugriff auf einen PaaS-Dienst?

Braucht die Ressource Zugriff auf einen Azure-PaaS-Dienst (Storage, SQL, Key Vault ...)?
│
├─ Zugriff nur aus demselben VNet/derselben Region, kein Hybrid-Zugriff,
│  kein Compliance-Zwang zu privater IP?
│  └─ JA → Service Endpoint (schnell, kostenlos)
│
├─ Zugriff auch von On-Premise (VPN/ExpressRoute), von gepeerten VNets,
│  oder Compliance verlangt private IP-Adressierung?
│  └─ JA → Private Endpoint (+ Private DNS Zone nicht vergessen!)
│
└─ Ressource wird direkt IN das VNet injiziert (SQL MI, App Service VNet-Integration)?
   └─ JA → Delegiertes Subnetz statt Endpoint-Konzept

Best Practices fuer Schweizer KMU im Ueberblick

• Ein durchdachter Adressraum von Anfang an – lieber ein grosszuegiges /16 pro Umgebung als spaeter migrieren muessen.
• NSGs auf Subnetz-Ebene verwalten, nicht auf jeder einzelnen NIC – bleibt uebersichtlich und auditierbar.
• Deny-by-Default zwischen Tiers, nicht nur am Rand des VNets. Die Default-Regel AllowVnetInBound ist fuer produktive Mehr-Tier-Architekturen fast immer zu offen.
• Private Endpoints als Standard fuer alles, was Kundendaten oder Geschaeftsgeheimnisse beruehrt – Service Endpoints nur fuer unkritische, reine Azure-interne Szenarien.
• Hub-Spoke von Anfang an, sobald mehr als ein VNet absehbar ist – auch wenn heute nur ein Spoke existiert, spart das spaeter eine schmerzhafte Migration.
• NSG Flow Logs aktivieren, bevor du sie brauchst. Nachtraeglich Flow-Logs fuer einen Vorfall zu aktivieren, der schon passiert ist, bringt nichts.
• IPAM-Dokumentation pflegen – wer welchen Adressbereich wann bekommen hat, gehoert in dieselbe Dokumentation wie Server und Lizenzen, siehe IT-Dokumentation und Inventar.

Weiterlernen

• Azure Virtual Network – Uebersicht (Microsoft Learn, deutsch)
• Network Security Groups – Uebersicht (Microsoft Learn)
• Was ist ein Private Endpoint? (Microsoft Learn)
• Hub-Spoke-Netzwerktopologie (Azure Architecture Center)
• Subnetzdelegierung in Azure Virtual Network (Microsoft Learn, deutsch)
• NSG-Diagnose mit Network Watcher (Microsoft Learn)