# Azure Networking: Virtual Networks (VNet) & Security-Konzepte

TL;DR / Management Summary Ein Virtual Network (VNet) ist die fundamentale Baueinheit für Ihre privaten Netzwerke in Microsoft Azure. Es ermöglicht Azure-Ressourcen (wie VMs), sicher miteinander, mit dem Internet und mit On-Premise-Netzwerken zu kommunizieren. Ein Senior Admin nutzt Subnetze zur logischen Strukturierung, Network Security Groups (NSG) für den Schutz auf Portebene und VNet Peering, um verschiedene Netzwerke ohne Gateway-Overhead zu verbinden.

# 1. VNet Architektur

Adressräume und Subnetze.

Ein Azure VNet ist an eine Region gebunden.

Adressraum: Definieren Sie einen privaten Bereich (z.B. 10.1.0.0/16).
Subnetze: Teilen Sie den Raum auf (z.B. Frontend, Backend, GatewaySubnet).
Wichtig: Das GatewaySubnet ist ein reservierter Name für VPN- und ExpressRoute-Gateways.

# 2. Security-Mechanismen

Schutz für die Ressourcen.

# 1. Network Security Groups (NSG)

Funktionieren wie eine Cloud-Firewall.

Ebene: Können an ein Subnetz oder eine einzelne Netzwerkkarte (NIC) gebunden werden.
Regeln: Basieren auf 5 Attributen (Source IP/Port, Dest IP/Port, Protocol).
Wichtig: Es gibt eine Standardregel AllowVNetInBound. Alle VMs im gleichen VNet dürfen standardmäßig miteinander sprechen.

# 2. Application Security Groups (ASG)

Ermöglichen es, Regeln basierend auf der Funktion der VM (z.B. “Web-Server”) statt auf IP-Adressen zu schreiben.

# 3. Deep Dive: VNet Peering

Netze verschmelzen lassen.

Wenn Sie zwei VNets haben (z.B. VNet-Prod und VNet-SharedServices), können Sie diese via Peering verbinden.

Vorteil: Der Traffic fließt über den Microsoft-Backbone, nicht über das Internet.
Performance: Keine Bandbreiten-Limitierung durch Gateways.
Kosten: Geringe Gebühren für den Datentransfer zwischen VNets.

# 4. Day-2 Operations: Azure VPN Gateway

Die Brücke ins lokale RZ.

Um Ihr Büro mit Azure zu verbinden:

VNet Gateway erstellen (Typ: VPN).
Local Network Gateway: Repräsentiert Ihre OPNsense-IP (Artikel 541).
Connection: Baut den IPsec-Tunnel auf.

Empfehlung: Nutzen Sie ExpressRoute für geschäftskritische Workloads mit garantierten Latenzen.

# 5. Troubleshooting & “War Stories”

Wenn die Pakete in der Cloud hängen.

# Top 3 Fehlerbilder

Symptom: VM hat Internetzugriff, ist aber nicht via RDP erreichbar.
- Ursache: Fehlende Inbound-Regel in der NSG für Port 3389.
- Lösung: NSG-Regeln im Portal prüfen.
Symptom: VNet Peering zeigt Disconnected.
- Ursache: Adressbereiche überschneiden sich (Overlap). Peering ist nur bei eindeutigen IPs möglich.
Symptom: Routing-Probleme bei Hub-and-Spoke Architekturen.
- Lösung: Aktivieren Sie “Allow Gateway Transit” im Peering der Hub-Seite.

# “War Story”: Der “Default-Internet” Bypass

Ein Admin wunderte sich, warum seine “isolierten” Datenbank-Server trotzdem Malware-Updates aus dem Internet laden konnten. Die Entdeckung: Er hatte keine explizite Outbound-Deny Regel erstellt. Die Ursache: In Azure gibt es die versteckte Regel AllowInternetOutBound. Jede VM hat standardmäßig vollen Zugriff auf das Internet (via Azure NAT). Lehre: Nutzen Sie in Azure immer eine Default-Deny Outbound Strategie für sensible Subnetze und erlauben Sie nur explizite Ziele (z.B. via Service Tags).

# 6. Monitoring & Reporting

Transparenz im VNet.

# Network Watcher

Nutzen Sie den Azure Network Watcher für die Diagnose:

IP Flow Verify: Prüft, ob ein Paket von A nach B durch die NSGs gelassen wird.
Next Hop: Zeigt den genauen Routing-Pfad an.

# 7. Fazit & Empfehlung

Azure Networking ist tief in das Microsoft-Ökosystem integriert.

Empfehlung: Nutzen Sie Service Tags (z.B. Storage, Sql) in Ihren NSG-Regeln statt IP-Listen. Azure hält diese automatisch aktuell.
Wichtig: Planen Sie Ihr VNet-Design als Hub-and-Spoke. Der Hub enthält die OPNsense/Azure-Firewall und das VPN-Gateway, die Spokes enthalten die Workloads.

# Anhang: Cheatsheet (Azure CLI)

Aufgabe	Befehl
VNets listen	`az network vnet list`
Subnet erstellen	`az network vnet subnet create ...`
NSG prüfen	`az network nsg rule list ...`
Peering Status	`az network vnet peering show ...`