Microsoft AZ-700: Hybride Vernetzung — Lernleitfaden

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Grundlagen der hybriden Konnektivität und Adressierungsbeschränkungen

Bei hybrider Konnektivität geht es um zuverlässige, routbare und sichere IP-Erreichbarkeit zwischen lokalen Netzwerken und virtuellen Netzwerken in Azure. Bei der Planung der Adressierung von virtuellen Netzwerken ist zu beachten, dass einige von Azure verwaltete Ressourcen innerhalb eines Subnetzes eine zusammenhängende, konfliktfreie Adresszuweisung und manchmal spezifische reservierte Adressen erfordern: Azure Load Balancer und Gateway-Subnetze müssen bewusst herausgelöst werden (das GatewaySubnet muss exakt so benannt und so dimensioniert sein, dass es die Skalierung der Gateway-SKU aufnehmen kann), und private Endpunkte sowie von Azure verwaltete Dienstendpunkte benötigen Adressen aus dem VNet, in dem sie gehostet werden. Überlappende lokale und Azure-Präfixe sind die häufigste Fehlerquelle: Überlappende Bereiche stören das Routing und die BGP-Routenauswahl, erzeugen asymmetrisches Routing und erschweren Firewall-Richtlinien. Verwenden Sie mindestens /27- bis /24-Segmente für Subnetze, die zustandsbehaftete Firewalls, Load Balancer oder viele private Endpunkte hosten; reservieren Sie ein dediziertes GatewaySubnet (/27 oder größer, je nach SKU). DNS ist ebenso entscheidend: Private Endpunkte verwenden private DNS-Zonen der Plattform (z. B. privatelink.database.windows.net), sodass lokale Conditional Forwarder oder der Azure DNS Private Resolver erforderlich sind, um private Azure-Namen aufzulösen. Bei Design-Abwägungen geht es um die IP-Nutzung im Vergleich zur Ausfallsicherheit: Dichter gepackte IPv4-Schemata sparen Adressraum, erhöhen aber das Risiko von Kollisionen und Migrationen, während größere, weniger effiziente Präfixe die zukünftige Erweiterung und BGP-Advertisement-Strategien vereinfachen.

VPN-Gateway-SKUs, BGP-Grundlagen und lokale Netzwerkgateways

Die Wahl der richtigen VPN-Gateway-SKU (VpnGw1–VpnGw5, Basic für ältere Systeme) wirkt sich direkt auf den Durchsatz, die Anzahl gleichzeitiger S2S/P2S-Sitzungen und verfügbare Funktionen wie Aktiv-Aktiv oder Routenlimits aus. Verwenden Sie routenbasierte Gateways für moderne hybride Designs; richtlinienbasierte Gateways sind veraltet und schränken BGP ein. BGP ermöglicht den dynamischen Austausch von Präfixen und unterstützt Pfadresilienz, automatisches Failover und die Priorisierung von Präfixen – konfigurieren Sie die ASN des Azure VPN Gateway (Standard 65515) und stimmen Sie sie mit der lokalen ASN im Local Network Gateway-Objekt ab oder führen Sie ein Peering durch. Das Local Network Gateway speichert die öffentliche IP-Adresse des lokalen Netzwerks, den Adressraum (die Adressräume) und optional die BGP-Peer-IP und ASN; wenn die BGP-Peer-IP nicht eingetragen wird oder die ASNs nicht übereinstimmen, wird die Routenverteilung verhindert und es müssen statische Routen als Umgehungslösung verwendet werden. Ziehen Sie Azure Virtual WAN-Hubs für die Skalierung über mehrere Standorte und integriertes Transit-Routing in Betracht; VWAN-Hubs unterstützen S2S und P2S in großem Umfang und lassen sich in Azure Firewall und ExpressRoute integrieren. Achten Sie auf die Weitergabe von Routingtabellen (Route Table Propagation): Standardmäßig unterdrücken einige Hub-and-Spoke- oder virtuelle Appliance-Topologien die automatische Weitergabe; explizite UDRs oder BGP-Routenankündigungen können erforderlich sein. Abwägungen: Höhere SKUs und VWAN erhöhen die Kosten, reduzieren aber den Verwaltungsaufwand und verbessern den Durchsatz sowie die Skalierbarkeit des Routings.

Point-to-Site-Designoptionen, Client-Unterstützung und DNS-Integration

Die Wahl der Point-to-Site (P2S)-Optionen bestimmt die Client-Kompatibilität, die Authentifizierung und die Skalierbarkeit. OpenVPN (SSL) ist am plattformübergreifendsten und wird für macOS-, Linux- und mobile Clients empfohlen; IKEv2 ist ressourcenschonend und funktioniert gut mit nativen macOS-Clients; SSTP bleibt eine Option für ältere, reine Windows-Szenarien. Zu den Authentifizierungsmodi gehören Azure Active Directory (empfohlen für die Identitätsintegration und den bedingten Zugriff), zertifikatbasierte Authentifizierung und RADIUS für lokale MFA- oder RADIUS-basierte Lösungen. Die VPN-Gateway-SKU bestimmt die Anzahl der P2S-Tunnel und den Durchsatz; wählen Sie VpnGw2/3 für mittlere bis große Benutzerpools und VpnGw4/5 für hohe Skalierung oder durchsatzempfindliche Anwendungsfälle. Private Endpunkte und P2S interagieren über DNS: Damit P2S-Clients die Namen privater Endpunkte (privatelink-Zonen) auflösen können, müssen entweder private DNS-Zonen mit dem VNet verknüpft oder der Azure DNS Private Resolver und Conditional Forwarder vom lokalen oder Client-DNS verwendet werden. Eine häufige Fehlerquelle ist zu vergessen, dass P2S-Clients normalerweise nur dann das vom Gateway bereitgestellte Azure DNS verwenden, wenn der Client Routen und DNS-Einstellungen pusht; explizite Konfigurationen für DNS-Suffixe und Forwarder vermeiden Probleme wie „privater Endpunkt kann nicht aufgelöst werden“. Wägen Sie Skalierbarkeit und Kosten ab: Die zertifikatbasierte Authentifizierung ist kostengünstig, aber Zertifikate sind schwerer zu widerrufen; Azure AD bietet moderne Sicherheitskontrollen, erhöht aber die Lizenzkosten/Komplexität.

Transit-Routing, Forced Tunneling, Inspektion und Platzierung von Sicherheits-Appliances

Das Design von Transit-Verbindungen zwischen mehreren VNets, lokalen Umgebungen und Inspektions-Appliances erfordert eine klare Durchsetzung von Routing- und NAT-Grenzen. Um den Datenverkehr durch eine Azure Firewall oder virtuelle Appliances zu zwingen, sind benutzerdefinierte Routen (UDRs) erforderlich, die auf die private IP-Adresse der Firewall verweisen, oder die Nutzung von Virtual WAN Hub-Routing, um die Inspektion zu zentralisieren. Wenn Sie vollständiges transparentes Proxying oder TLS-Inspektion benötigen, platzieren Sie die Appliance in einem dedizierten Subnetz für die Inspektion und stellen Sie sicher, dass das Gateway-Subnetz und die Firewall-SKUs den Transit für den erwarteten Durchsatz unterstützen. Achten Sie auf das SNAT-Verhalten und die Auswahl der Public IP-SKUs: Standard Public IPs und NAT Gateway werden für vorhersagbares ausgehendes SNAT und Sicherheitsregeln empfohlen; ein NAT Gateway in Verbindung mit einem Satz von Standard Public IPs entlastet SNAT und vermeidet einen Wildwuchs von Public IPs pro VM. Eine Falle ist asymmetrisches Routing, wenn lokale Routen und Azure-UDRs dazu führen, dass der Rückverkehr die vorgesehene Appliance umgeht; stellen Sie sicher, dass alle Spokes die erforderlichen Präfixe über BGP ankündigen oder über UDRs verfügen, die den Verkehr zum Inspektionspunkt leiten. Leistung vs. Kosten: Eine Hub-and-Spoke-Architektur mit Azure Firewall Premium oder Hochdurchsatz-Appliances von Drittanbietern erhöht den Schutz und die zentrale Verwaltung, steigert aber auch die Kosten und das Ausfallrisiko eines einzelnen Hubs, es sei denn, Sie implementieren aktiv-aktive redundante Hubs und koppeln Gateways über Regionen hinweg.

Praktisches Problem: Anwendungsfallszenario

Szenario: Contoso Ltd hat zwei lokale Rechenzentren (Seattle und Amsterdam) und eine bestehende Azure-Umgebung mit drei VNets (VNet-Prod, VNet-Shared, VNet-Dev) in einem einzelnen Hub-VNet (VNet-Hub). Derzeit verwenden sie ein VpnGw1 VPN Gateway für Seattle und eine Site-to-Site-Verbindung zu einem Azure Virtual WAN Hub für Amsterdam. Private Endpunkte werden für Azure SQL im VNet-Shared verwendet.

Herausforderung: Contoso benötigt eine resiliente, skalierbare hybride Konnektivität mit dynamischem Routing (BGP) zwischen beiden Rechenzentren und Azure, zuverlässige P2S-Unterstützung für macOS-Benutzer, DNS-Auflösung von privaten Endpunkten aus der lokalen Umgebung und eine zentralisierte Inspektion des ausgehenden Verkehrs von den Spokes durch eine Azure Firewall.

Empfohlener Ansatz:

Stellen Sie ein neues routenbasiertes VpnGw3 VPN Gateway im VNet-Hub bereit, das aktiv-aktiv mit aktiviertem BGP konfiguriert ist (Gateway-ASN explizit festlegen), und aktualisieren Sie die Local Network Gateway-Objekte mit den BGP-Peer-IPs und ASNs der lokalen Umgebung. Migrieren Sie die S2S-Verbindung von Seattle auf das neue Gateway, um höheren Durchsatz und höhere Routenlimits zu unterstützen.
Konsolidieren Sie die Amsterdam-Verbindung in den Hub, indem Sie eine ExpressRoute-Verbindung einrichten oder den VWAN-Hub auf ein Hub-Peering mit dem VNet-Hub umstellen. Stellen Sie den BGP-Routenaustausch zwischen beiden Rechenzentren sicher, um statische Routen zu vermeiden und ein automatisches Failover zu ermöglichen.
Konfigurieren Sie P2S mit dem OpenVPN-Protokoll und Azure AD-Authentifizierung auf dem VpnGw3, um macOS-Clients zu unterstützen (IKEv2 als Fallback), und dimensionieren Sie die Client-Pools gemäß den VpnGw3-Limits. Veröffentlichen Sie eine bedingte Weiterleitung auf dem lokalen DNS, um privatelink.*-Zonen an einen Azure DNS Private Resolver weiterzuleiten, der im VNet-Shared bereitgestellt und mit den privaten DNS-Zonen für die privaten Endpunkte verknüpft ist.
Stellen Sie eine Azure Firewall (Standard oder Premium, falls TLS-Inspektion erforderlich) im VNet-Hub in einer aktiv-aktiv-Konfiguration bereit und erstellen Sie UDRs für die Spoke-Subnetze, die den gesamten Verkehr (0.0.0.0/0) an die private IP-Adresse der Firewall leiten. Fügen Sie der Firewall ein NAT Gateway mit Standard Public IPs hinzu oder verwenden Sie die öffentliche IP der Firewall für explizites SNAT und die Protokollierung in einem zentralen Log Analytics-Arbeitsbereich.

Begründung: Die Verwendung von VpnGw3 mit BGP ermöglicht eine dynamische Routenverteilung und den nötigen Durchsatz für standortübergreifende Resilienz. OpenVPN+Azure AD unterstützt macOS-Benutzer auf sichere Weise. Die DNS-Weiterleitung an einen Azure DNS Private Resolver stellt die Namensauflösung von privaten Endpunkten aus der lokalen Umgebung sicher. Die Zentralisierung der Inspektion in einem Azure Firewall-Hub mit UDRs vermeidet asymmetrisches Routing und vereinfacht die Richtlinienverwaltung, während Kosten gegen zentralisierte Sicherheit und Beobachtbarkeit eingetauscht werden.

← Azure Virtual Network Design · Alle Domänen · Azure DNS →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →