Microsoft AZ-104: Azure Virtuelle Vernetzung — Lernleitfaden

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Teil des Microsoft Azure Administrator Associate AZ-104 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure Virtual Networking bildet die softwaredefinierte Rechenzentrums-Fabric für IaaS- und PaaS-Workloads. Sie entwerfen einen Adressplan mit CIDR, unterteilen Subnetze entlang von Vertrauensgrenzen, sichern Ost-West- und Nord-Süd-Datenverkehrsflüsse mit Network Security Groups (NSGs) und Azure Firewall, verbinden Umgebungen mittels VNet-Peering, VPN Gateway oder ExpressRoute, steuern den Datenverkehr mit benutzerdefinierten Routen und stellen eine zuverlässige Namensauflösung mit Azure DNS bereit. Die korrekte Konfiguration dieser Konstrukte ermöglicht skalierbare Hub-and-Spoke-Designs, sicheren PaaS-Zugriff über Private Endpoints und ein vorhersagbares Routing, das Compliance- und Leistungsanforderungen erfüllt.

Adressierung, Segmentierung und Richtlinien (VNets, Subnetze, NSGs, ASGs, UDR)

Ein virtuelles Netzwerk definiert einen oder mehrere nicht überlappende RFC1918-Adressräume unter Verwendung der CIDR-Notation (z. B. 10.0.0.0/16). Sie können später zusätzliche Adresspräfixe hinzufügen, wenn keine Konflikte mit Peers bestehen. Subnetze segmentieren das VNet in routbare Blöcke (z. B. 10.0.1.0/24 für Web, 10.0.2.0/24 für App). Reservieren Sie ein dediziertes GatewaySubnet für VPN/ExpressRoute-Gateways; bemessen Sie es großzügig (mindestens /27), um zukünftige Skalierungsgrenzen zu vermeiden. Die IP-Zuweisung ist standardmäßig dynamisch; bei Bedarf können Sie statische private IPs auf NICs festlegen.

Standardmäßige Systemrouten erlauben VNet-internen Datenverkehr und senden 0.0.0.0/0 an das Internet (abhängig vom Vorhandensein einer öffentlichen IP). Benutzerdefinierte Routen (UDR) überschreiben diese Standardeinstellungen auf Subnetzebene. Erstellen Sie eine Routingtabelle und weisen Sie sie einem Subnetz zu; die Einträge umfassen:

Nächster Hop: Virtuelle Appliance (die IP einer NVA im selben VNet), Virtuelles Netzwerkgateway (um den Verkehr über VPN/ExpressRoute zu On-Premises zu leiten), Internet (um Internet-Egress zu erzwingen) oder Keine (Blackhole).
Erzwungenes Tunneling: Senden Sie 0.0.0.0/0 an ein virtuelles Netzwerkgateway, um den gesamten ausgehenden Verkehr zu On-Premises zu zwingen, oder an eine NVA/Azure Firewall für eine zentralisierte Egress-Kontrolle. Wenn Sie BGP mit einem Gateway verwenden, das eine Standardroute ankündigt, sollten Sie die Gateway-Routenverteilung auf bestimmten Subnetzen deaktivieren, um eine unbeabsichtigte Pfadauswahl zu verhindern.

NSGs setzen zustandsbehaftete L3-L4-Richtlinien auf NICs oder Subnetzen durch; beide Bereiche können gleichzeitig verwendet werden, und der Datenverkehr muss von allen anwendbaren NSGs zugelassen werden. Regeln werden nach Priorität (100–4096; niedrigere Zahlen zuerst) und Richtung (eingehend/ausgehend) ausgewertet. Die Standardregeln umfassen:

Eingehend: AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Ausgehend: AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Überschreiben Sie die Standardeinstellungen mit benutzerdefinierten Regeln höherer Priorität. Verwenden Sie Dienst-Tags (z. B. Internet, AzureLoadBalancer, Storage), um die Wartung zu vereinfachen, und IP-Gruppen für wiederverwendbare Adresslisten.

Anwendungssicherheitsgruppen (ASGs) entkoppeln die IP-Adressierung von der Richtlinie. Weisen Sie NICs ASGs zu, die Rollen repräsentieren (z. B. Web, App, DB), und referenzieren Sie diese ASGs in NSG-Regeln. Dies ermöglicht Richtlinienänderungen, ohne IPs oder Subnetze anzupassen, und unterstützt eine konsistente rollenbasierte Segmentierung innerhalb eines VNets.

Konnektivitätsoptionen: Peering, VPN Gateway und ExpressRoute

VNet-Peering verbindet VNets über das Microsoft-Backbone mit niedriger Latenz und hoher Bandbreite. Lokales Peering findet innerhalb einer Region statt; globales Peering erstreckt sich über Regionen. Peering ist nicht transitiv und erfordert sich nicht überschneidende Adressräume. Wichtige Flags:

Zugriff auf virtuelles Netzwerk zulassen ermöglicht geroutete Konnektivität zwischen den Peers.
Weitergeleiteten Datenverkehr zulassen gestattet, dass von NVAs weitergeleiteter Datenverkehr das Peering durchquert.
Remotegateways verwenden ermöglicht einem VNet, ein VPN/ER-Gateway in einem verbundenen „Hub“ zu nutzen. Der Hub muss Gatewaytransit zulassen konfiguriert haben. Ein VNet kann Remotegateways von nur einem Peer verwenden. Gekoppelte VNets erhalten nicht automatisch P2S-Client-Routen; Endbenutzer müssen aktualisierte VPN-Client-Konfigurationen installieren, die Routen zu neuen Spokes enthalten.

Azure VPN Gateway stellt IPSec/IKE-Tunnel bereit:

Site-to-Site (S2S) verbindet lokale VPN-Geräte mit Azure; verwenden Sie routenbasiertes VPN (IKEv2) für die meisten Szenarien, insbesondere bei BGP und mehreren Tunneln.
Point-to-Site (P2S) ermöglicht einzelnen Clients (Windows, macOS, Linux) die Verbindung über OpenVPN, IKEv2 oder SSTP. Die Client-Konfiguration enthält statische Routen zu Azure-Präfixen; laden Sie sie erneut herunter, wenn sich Adressräume ändern oder Sie erreichbare Spokes hinter einem Hub hinzufügen.
VNet-zu-VNet verwendet S2S innerhalb von Azure-Regionen/-Mandanten und erfordert sich nicht überschneidende Adressen. Nützlich, wenn Peering nicht möglich ist (z. B. mandantenübergreifend mit administrativen Grenzen).
SKUs: Bevorzugen Sie VpnGw1–VpnGw5 (und die AZ-Varianten für Zonenredundanz). Basic ist veraltet und es fehlen Funktionen (kein IKEv2/BGP). Routenbasiert unterstützt P2S, BGP und Aktiv/Aktiv. Richtlinienbasiert ist eingeschränkt (nur S2S, kein BGP).
BGP kündigt Präfixe dynamisch an, unterstützt den Transit über mehrere Tunnel und vereinfacht das Routen-Failover. VPN-NAT-Regeln können überschneidende lokale/Azure-Präfixe übersetzen, wenn dies unvermeidbar ist.

ExpressRoute liefert private, SLA-gestützte Konnektivität über die Leitung eines Partners zum Edge von Microsoft:

Eine Leitung wird vom Anbieter bereitgestellt (Bandbreite, Abrechnungsmodell, SKU) und über einen Dienstschlüssel mit Ihrem Abonnement verknüpft. Redundanz ist integriert: Jede Leitung stellt duale primäre/sekundäre Verbindungen bereit; Ihr Router sollte für Hochverfügbarkeit (HA) duale BGP-Sitzungen aufbauen.
Peering-Typen:
- Privates Peering überträgt privaten RFC1918-Datenverkehr zu VNets über ein virtuelles ExpressRoute-Netzwerkgateway (ErGw1AZ–ErGw3AZ). Unterstützt BGP, schnelles Failover und optional FastPath zur Beschleunigung der Datenebene.
- Microsoft-Peering stellt öffentliche Microsoft-Dienste (z. B. Storage, SQL, Microsoft 365) über öffentliche IPs mit Routenfiltern bereit. Verwenden Sie dies für internetseitige Endpunkte, ohne über das öffentliche Internet zu gehen. Microsoft 365 erfordert eine zusätzliche Prüfung.
Verwenden Sie ExpressRoute Global Reach, um lokale Standorte über das Microsoft-Backbone miteinander zu verbinden. Für erzwungenes Tunneling kündigen Sie eine Standardroute über privates Peering an oder kombinieren Sie es mit UDRs/Azure Firewall für selektiven Egress-Verkehr.

Koexistenz: Ein VNet kann sowohl VPN- als auch ExpressRoute-Gateways im selben GatewaySubnet haben; verwenden Sie Gatewaytransit und UDRs, um die Datenflüsse zu steuern. ExpressRoute wird für den stabilen Unternehmensverkehr bevorzugt; VPN dient als Backup oder zur Anbindung von Zweigstellen/kleinen Büros.

Namensauflösung und sicherer Zugriff auf PaaS (Azure DNS, Endpunkte)

Azure DNS hostet öffentliche Zonen, sodass Ihre internetseitigen Einträge auf der globalen DNS-Plattform von Azure mit hoher Verfügbarkeit liegen. Für die VNet-interne Auflösung bieten Private Azure DNS-Zonen einen Split-Horizon-Namensdienst. Verknüpfen Sie VNets mit einer privaten Zone, um die Auflösung zu ermöglichen; aktivieren Sie optional die automatische Registrierung, damit A-Einträge von VMs bei Änderungen der NIC-IP automatisch registriert und aktualisiert werden. Für hybride Namensauflösung und bedingte Weiterleitung zwischen Azure und On-Premises stellen Sie Azure DNS Private Resolver mit eingehenden/ausgehenden Endpunkten und Regelsätzen bereit, die ausgewählte Domänen weiterleiten (z. B. corp.contoso.com an lokale DNS-Server oder privatelink.* zurück nach Azure).

Dienstendpunkte erweitern die Identität Ihres VNets auf ausgewählte Azure-Dienste (z. B. Storage, SQL) über das Microsoft-Backbone, wobei die öffentliche IP des Dienstes beibehalten wird. Beschränken Sie in der PaaS-Firewall den Zugriff auf ein bestimmtes VNet/Subnetz. Sie sind pro Subnetz und pro Dienst einfach zu aktivieren, erfordern keine DNS-Änderungen und eignen sich gut für einfache, reine Azure-Szenarien. Die Ressource hat jedoch weiterhin eine öffentliche IP und ist von On-Premises aus nicht privat adressierbar, ohne den öffentlichen Endpunkt zu durchlaufen.

Private Endpunkte platzieren über Private Link eine NIC mit einer privaten IP aus Ihrem Subnetz auf der PaaS-Ressource. Der Datenverkehr verbleibt im privaten Netzwerk, was eine feingranulare Kontrolle der Datenexfiltration und den Zugriff von On-Premises über VPN/ExpressRoute ermöglicht. Eine korrekte DNS-Konfiguration ist unerlässlich: Überschreiben Sie den öffentlichen FQDN der Ressource, um ihn auf dessen privatelink-FQDN aufzulösen, der auf Ihre private IP verweist. Verwenden Sie mit VNets verknüpfte Private Azure DNS-Zonen (z. B. privatelink.blob.core.windows.net). Wählen Sie Private Endpunkte, wenn Sie echte private Adressierung, standortübergreifenden Zugriff und strikte Egress-Kontrollen benötigen.

Azure Firewall und zentralisierte Egress/Ingress-Governance

Azure Firewall ist eine zustandsbehaftete, cloudnative Firewall, die elastisch skaliert und eine zentrale Richtlinie für Hub-and-Spoke-Designs bereitstellt. Stellen Sie sie in einem dedizierten AzureFirewallSubnet bereit. Fügen Sie für Szenarien mit erzwungenem Tunneling (Forced Tunneling) ein AzureFirewallManagementSubnet hinzu, damit der Verwaltungsdatenverkehr das Internet nutzt, während der Datenverkehr Ihrer Standardroute folgt.

Regelsammlungstypen werden in dieser Reihenfolge und nach Priorität der Regelsammlung angewendet: