Microsoft AZ-700: Netzwerküberwachung & Fehlerbehebung — 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.

Observability-Tools und Datenquellen

Die Observability im Azure-Netzwerk konzentriert sich auf Network Watcher, Azure Monitor (Log Analytics) und Diagnoseeinstellungen, die Telemetriedaten von Ressourcen in einen zentralen Arbeitsbereich oder ein Speicherkonto streamen. Network Watcher bietet Paketaufzeichnung, IP-Flussüberprüfung, Nächster Hop, Verbindungsproblembehandlung und Connection Monitor; Connection Monitor v2 unterstützt Tests mit mehreren Endpunkten und Protokollen und speichert die Ergebnisse für abfragbare Telemetrie in einem Log Analytics-Arbeitsbereich. NSG-Flussprotokolle werden über Network Watcher aktiviert und schreiben JSON-Datensätze in ein Speicherkonto; die Aktivierung von Traffic Analytics (erfordert Flussprotokolle + einen Log Analytics-Arbeitsbereich) reichert diese Protokolle mit Anwendungs-/Geo-Einblicken und Visualisierungen an. Diagnoseeinstellungen von Azure Firewall, Application Gateway/WAF, Front Door und Load Balancern sollten an denselben Log Analytics-Arbeitsbereich weitergeleitet werden, um Signale zu korrelieren. Häufige Fallstricke sind Firewall-Regeln für Speicherkonten, die das Schreiben von Flussprotokollen blockieren, das Vergessen, Network Watcher pro Region in älteren Tenants zu aktivieren, und inkonsistente Aufbewahrungsrichtlinien zwischen Speicher und Log Analytics. Die Kompromisse bei Kosten und Funktionalität sind klar: das Schreiben von Rohprotokollen in ein Speicherkonto zur kostengünstigen Archivierung gegenüber der Erfassung in Log Analytics für Abfragen und Warnungen (höhere Kosten, aber weitaus größerer diagnostischer Wert). Die rollenbasierte Zugriffssteuerung (Role-Based Access Control) (Monitor Reader plus Storage Blob Data Reader, wo erforderlich) muss so konfiguriert werden, dass Diagnose-Pipelines schreiben und Analysten Protokolle lesen können.

Paketaufzeichnung, Connection Monitor und Tiefendiagnose

Für die Fehlerbehebung auf Paketebene erstellt die Paketaufzeichnung von Network Watcher (über Portal/CLI/PowerShell) PCAP-Dateien in einem Speicherkonto oder in einer lokalen VM-Datei. Konfigurieren Sie Filter für die Paketaufzeichnung (Protokoll, Quell-/Ziel-IP, Ports) sowie Größen- und Zeitlimits, um übermäßige Speichernutzung und Leistungseinbußen zu vermeiden. Bei VMs mit hohem Durchsatz und beschleunigtem Netzwerkbetrieb kann die Sichtbarkeit von Paketen auf Host-Seite eingeschränkt sein; verwenden Sie VNet TAP, um den Datenverkehr zu einer Collector-VM oder NVA zu spiegeln und so den Verlust von ausgelagerten Paketen zu vermeiden. Connection Monitor sollte für aktive synthetische Tests verwendet werden: Definieren Sie Quell- und Zielendpunkte (IP, FQDN, Port), wählen Sie die Testhäufigkeit und aktivieren Sie die Latenz pro Hop und die Pfadaufzeichnung für die Diagnose über mehrere Segmente hinweg. Verwenden Sie die IP-Flussüberprüfung (IP Flow Verify), um zu prüfen, ob ein bestimmtes 5-Tupel von NSGs/UDRs zugelassen oder verweigert wird, und Nächster Hop (Next-hop), um das effektive Routing zu bestätigen. Achten Sie auf Fallstricke: Die Paketaufzeichnung auf Windows-VMs erfordert möglicherweise erhöhte Berechtigungen und kann durch OS-Offloads beeinträchtigt werden; die Paketaufzeichnung kann CPU-/festplattenintensiv sein, daher sollten gezielte Filter und Zeitfenster bevorzugt werden. Für eine kontinuierliche Paketinspektion im großen Maßstab kombinieren Sie VNet TAP mit einer Paket-Analyse-Appliance oder einem Cloud-SIEM, das PCAP-Streams erfassen kann.

NSG-Flussprotokolle, Traffic Analytics und Sicherheitsdiagnose

NSG-Flussprotokolle (Version 2) liefern Flussdatensätze mit Zeitstempeln, 5-Tupel, Byte-/Paketzählern und der Entscheidung (zugelassen/verweigert). Sie enthalten keine Nutzdaten, Sitzungsdetails der Anwendungsschicht oder entschlüsseltes TLS. Traffic Analytics reichert Flussprotokolle mit Top-Talkern, ASNs und Geo-Mapping an und erfordert einen Log Analytics-Arbeitsbereich. Azure Firewall, Application Gateway/WAF und Azure Front Door geben ihre eigenen Diagnosedaten aus; diese müssen für eine einheitliche Abfrage an Log Analytics weitergeleitet werden. Wichtige Design-Fallstricke: NSG-Regeln, die auf NIC-Ebene angewendet werden, haben Vorrang vor Regeln auf Subnetzebene; es gibt Standardregeln (z. B. AzureLoadBalancer, Internetregeln), die nicht entfernt, sondern nur durch Regeln mit höherer Priorität überschrieben werden können. Flussprotokolle sind nur so nützlich wie die Aufbewahrungs- und Erfassungsstrategie – eine lange Aufbewahrung in Log Analytics ist teuer, während eine kurze Aufbewahrung den Verlust forensischer Beweise riskiert. Kombinieren Sie NSG-Flussprotokolle mit den Diagnoseprotokollen der Firewall und Warnungsregeln auf Basis von Kusto-Abfragen, um laterale Bewegungen oder Datenexfiltration zu erkennen. Berücksichtigen Sie bei der Planung von Abhilfemaßnahmen das Hinzufügen dedizierter öffentlicher IPs zur Azure Firewall, um die Erschöpfung von SNAT-Ports zu mindern, und nutzen Sie DiagnosticSettings, um Daten an Event Hubs zur SIEM-Integration weiterzuleiten, falls die Kosten für Log Analytics zu hoch sind.

Muster zur Fehlerbehebung, Routing-Fallstricke und Design-Kompromisse

Befolgen Sie bei der Fehlerbehebung von Konnektivitätsproblemen einen schichtweisen Ansatz: Überprüfen Sie NSG/UDR auf Ressourcenebene, prüfen Sie effektive Routen und den nächsten Hop, verwenden Sie IP Flow Verify und Connection Troubleshoot und eskalieren Sie bei Bedarf zu Packet Capture oder VNet TAP. Routing-Fallstricke treten häufig bei Forced Tunneling, überlappenden CIDRs oder falsch konfigurierten UDRs auf, die Datenverkehr in das AzureFirewallSubnet ohne entsprechende Rückrouten senden. Wählen Sie für Lastenausgleich und Skalierung zwischen Azure Standard Load Balancer, Application Gateway WAF und Front Door, basierend auf L4- vs. L7-Anforderungen und globalem vs. regionalem Verkehrsmanagement. Berücksichtigen Sie diese SKU-Kompromisse:

Azure Firewall Standard vs. Premium: Premium fügt TLS-Inspektion, IDPS und URL-Filterung zu höheren Kosten hinzu; wählen Sie Premium, wenn eine tiefgehende Datenverkehrsanalyse und regulatorische Kontrolle erforderlich sind.
Azure Front Door Standard vs. Premium: Premium unterstützt erweiterte WAF-Funktionen und Private-Link-Integrationen; Standard ist kostengünstiger für typisches globales CDN + Routing.
VNet TAP vs. Packet Capture: TAP ist teurer, aber für eine verlustfreie Erfassung im großen Maßstab und bei der Auslagerung von Paketen durch Accelerated Networking erforderlich. Die Kompromisse konzentrieren sich auf Leistung, Kosten und Ausfallsicherheit: NVAs können günstiger oder funktionsreicher sein als Firewall Premium, verursachen aber zusätzlichen Verwaltungsaufwand und das Risiko eines Single Point of Failure, es sei denn, sie sind mit HA ausgelegt. Planen Sie die SNAT-Kapazität, reservieren Sie freie öffentliche IPs und richten Sie Diagnose-Pipelines ein, um den Bedarf an Beobachtbarkeit mit den Erfassungskosten in Einklang zu bringen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Contoso Electronics betreibt eine Azure-Umgebung in zwei Regionen (EastUS, WestEurope) mit Hub-and-Spoke-VNets, einer Azure Firewall Standard im Hub, mehreren Spoke Application Gateway WAFs und einem zentralen Log Analytics-Arbeitsbereich für die Überwachung. Kürzlich wurde eine Reihe von Produktions-VMs in einem Spoke bereitgestellt, die zeitweise Ausfälle beim Erreichen eines lokalen SQL-Clusters über eine ExpressRoute-Verbindung melden.

Herausforderung: Zeitweise Konnektivitätsprobleme und hohe Latenz zu lokalen Ressourcen ohne eindeutige Beweise auf Paketebene; vorhandene NSG-Flow-Logs sind aktiviert, zeigen aber erlaubte Flows ohne Latenzmetriken.

Empfohlener Ansatz:

Stellen Sie Connection Monitor v2 von repräsentativen VMs zum lokalen SQL-FQDN und zur IP unter Verwendung von TCP-Port 1433 bereit, legen Sie Tests alle 30 Sekunden fest und senden Sie die Ergebnisse an den zentralen Log Analytics-Arbeitsbereich, um die Latenz pro Hop und die Erreichbarkeit zu erfassen.
Aktivieren Sie Network Watcher Packet Capture auf einer betroffenen VM mit Filtern für die Quell-/Ziel-IP des SQL-Clusters und Port 1433 und speichern Sie die PCAPs in einem Speicherkonto mit einer Lifecycle-Richtlinie; aktivieren Sie gleichzeitig VNet TAP im Spoke-Subnetz, um den Datenverkehr zu einer dedizierten Collector-VM zu spiegeln, falls Accelerated Networking vorhanden ist.
Konfigurieren Sie die Diagnoseeinstellungen für Azure Firewall (Standard), um Anwendungs- und Netzwerkprotokolle an denselben Log Analytics-Arbeitsbereich zu senden, und führen Sie Korrelationsabfragen aus, die die Ergebnisse von Connection Monitor, Firewall-Protokollen und NSG-Flow-Logs verknüpfen, um eine SNAT-Erschöpfung der Firewall oder durch Richtlinien verworfene Pakete zu erkennen.
Verwenden Sie während eines Vorfalls IP Flow Verify und Next Hop für ein fehlerhaftes 5-Tupel; wenn SNAT oder asymmetrisches Routing vermutet wird, fügen Sie der Azure Firewall eine zusätzliche öffentliche IP hinzu oder stellen Sie ein NAT Gateway im Spoke für vorhersagbaren Egress-Verkehr bereit und aktualisieren Sie die UDRs, um den Verkehr durch den Hub zu leiten.

Begründung: Connection Monitor liefert synthetische, mit Zeitstempeln versehene Erreichbarkeits- und Latenzdaten pro Hop; Packet Capture und VNet TAP liefern verlustfreie forensische Daten, wenn Betriebssystem-Offloads den Datenverkehr verschleiern. Die Korrelation von Firewall- und NSG-Protokollen in Log Analytics identifiziert Probleme mit Richtlinien, SNAT oder asymmetrischem Routing; das Hinzufügen öffentlicher IPs oder eines NAT Gateways mildert die Port-Erschöpfung und stabilisiert das Egress-Verhalten.

← Lastenausgleich · Alle Domänen · Azure Virtual WAN →

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