Microsoft AZ-700: Netwerkmonitoring en probleemoplossing — Studiegids

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

Onderdeel van de Microsoft Azure Network Engineer AZ-700 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Observeerbaarheidstools en databronnen

Observeerbaarheid binnen Azure-netwerken draait om Network Watcher, Azure Monitor (Log Analytics) en diagnostische instellingen die telemetrie van resources streamen naar een centrale werkruimte of een storage-account. Network Watcher biedt packet capture, IP flow verify, next hop, connection troubleshoot en Connection Monitor; Connection Monitor v2 ondersteunt tests met meerdere eindpunten en protocollen en slaat de resultaten op in een Log Analytics-werkruimte voor opvraagbare telemetrie. NSG-flowlogboeken worden ingeschakeld via Network Watcher en schrijven JSON-records naar een storage-account; het inschakelen van Traffic Analytics (wat flowlogboeken + een Log Analytics-werkruimte vereist) verrijkt die logboeken met applicatie-/geo-inzichten en visualisatie. Diagnostische instellingen op Azure Firewall, Application Gateway/WAF, Front Door en load balancers moeten naar dezelfde Log Analytics-werkruimte worden gerouteerd om signalen te correleren. Veelvoorkomende valkuilen zijn firewallregels van storage-accounts die het schrijven van flowlogboeken blokkeren, vergeten om Network Watcher per regio in te schakelen in oudere tenants, en inconsistente bewaarbeleidsregels tussen storage en Log Analytics. De afwegingen tussen kosten en mogelijkheden zijn duidelijk: het wegschrijven van onbewerkte logboeken naar een storage-account voor goedkope archivering versus opname in Log Analytics voor query’s en alarmering (hogere kosten maar veel grotere diagnostische waarde). Role-Based Access Control (Monitor Reader plus waar nodig Storage Blob Data Reader) moet worden geconfigureerd zodat diagnostische pipelines kunnen schrijven en analisten de logboeken kunnen lezen.

Packet capture, Connection Monitor en diepgaande diagnostiek

Voor troubleshooting op pakketniveau maakt Network Watcher packet capture (via de portal/CLI/PowerShell) PCAP-bestanden aan in een storage-account of als een lokaal bestand op een VM. Configureer filters voor packet capture (protocol, src/dst IP, poorten) en limieten voor grootte/tijd om overmatig opslaggebruik en prestatie-impact te voorkomen. Voor VM’s met hoge doorvoer en accelerated networking kan de zichtbaarheid van pakketten aan de host-zijde beperkt zijn; gebruik VNet TAP om verkeer te spiegelen naar een collector-VM of NVA om te voorkomen dat offloaded pakketten worden gemist. Connection Monitor moet worden gebruikt voor actieve synthetische tests: definieer bron- en bestemmings-eindpunten (IP, FQDN, poort), kies de testfrequentie en schakel per-hop latentie en padregistratie in voor diagnose over meerdere segmenten. Gebruik IP Flow Verify om te controleren of een specifieke 5-tuple wordt toegestaan of geweigerd door NSG’s/UDR’s, en Next-hop om de effectieve routering te bevestigen. Let op valkuilen: packet capture op Windows VM’s kan verhoogde machtigingen vereisen en kan worden beïnvloed door OS-offloads; packet capture kan CPU-/schijfintensief zijn, dus geef de voorkeur aan gerichte filters en tijdsbeperkingen. Voor continue pakketinspectie op schaal, koppel VNet TAP aan een packet analytics appliance of een cloud-SIEM die PCAP-streams kan opnemen.

NSG-flowlogboeken, Traffic Analytics en beveiligingsdiagnostiek

NSG-flowlogboeken (versie 2) leveren flow-records met tijdstempels, 5-tuple, byte-/pakkettellingen en de beslissing (toegestaan/geweigerd). Ze bevatten geen payload, sessiedetails van de applicatielaag of ontsleutelde TLS. Traffic Analytics verrijkt flowlogboeken met ’top talkers’, ASN’s en geo-mapping, en vereist een Log Analytics-werkruimte. Azure Firewall, Application Gateway/WAF en Azure Front Door produceren hun eigen diagnostische gegevens; deze moeten naar Log Analytics worden gestuurd voor uniforme query’s. Belangrijke valkuilen bij het ontwerp: NSG-regels die op NIC-niveau worden toegepast, hebben voorrang op regels op subnetniveau; er bestaan standaardregels (bijv. AzureLoadBalancer, internetregels) en deze kunnen niet worden verwijderd, alleen worden overschreven door regels met een hogere prioriteit. Flowlogboeken zijn slechts zo nuttig als de bewaar- en opnamestrategie—lang bewaren in Log Analytics is duur, terwijl een korte bewaartermijn het risico met zich meebrengt dat forensisch bewijs verloren gaat. Combineer NSG-flowlogboeken met diagnostische logboeken van de Firewall en Alert-regels op basis van Kusto-query’s om laterale verplaatsing of data-exfiltratie te detecteren. Overweeg bij het plannen van herstelacties om dedicated public IP’s toe te voegen aan Azure Firewall om SNAT-poortuitputting te verminderen en gebruik DiagnosticSettings om gegevens door te sturen naar Event Hubs voor SIEM-integratie als de kosten van Log Analytics te hoog zijn.

Patronen voor probleemoplossing, routeringsproblemen en ontwerpafwegingen

Volg bij het oplossen van connectiviteitsproblemen een gelaagde aanpak: verifieer NSG/UDR op resourceniveau, controleer effectieve routes en de next hop, gebruik IP Flow Verify en Connection Troubleshoot, en escaleer indien nodig naar packet capture of VNet TAP. Routeringsproblemen (‘pitfalls’) doen zich vaak voor bij ‘forced tunneling’, overlappende CIDR’s, of verkeerd geconfigureerde UDR’s die verkeer naar de AzureFirewallSubnet sturen zonder de juiste retourroutes. Kies voor load balancing en schaalbaarheid tussen Azure Standard Load Balancer, Application Gateway WAF en Front Door, gebaseerd op L4- versus L7-behoeften en globaal versus regionaal verkeersbeheer. Overweeg deze afwegingen tussen SKU’s:

Azure Firewall Standard vs Premium: Premium voegt TLS-inspectie, IDPS en URL-filtering toe tegen hogere kosten; kies Premium wanneer diepgaande verkeersinspectie en naleving van regelgeving vereist zijn.
Azure Front Door Standard vs Premium: Premium ondersteunt geavanceerde WAF-functies en private link-integraties; Standard is goedkoper voor typische globale CDN + routering.
VNet TAP vs packet capture: TAP is duurder maar vereist voor ’lossless capture’ op grote schaal en wanneer ‘accelerated networking’ pakketten ‘offload’. De afwegingen draaien om prestaties, kosten en veerkracht: NVA’s kunnen goedkoper of rijker aan functies zijn dan Firewall Premium, maar voegen beheeroverhead en het risico op een ‘single-point-of-failure’ toe, tenzij ze met HA zijn ontworpen. Plan voor SNAT-capaciteit, reserveer extra publieke IP’s en richt diagnostische pipelines in om de behoeften aan ‘observability’ af te wegen tegen de ‘ingestion’-kosten.

Praktijkprobleem: Gebruikersscenario

Scenario: Contoso Electronics heeft een Azure-omgeving in twee regio’s (EastUS, WestEurope) met hub-and-spoke VNet’s, een Azure Firewall Standard in de hub, meerdere Application Gateway WAF’s in de spokes, en een centrale Log Analytics workspace voor monitoring. Ze hebben onlangs een set productie-VM’s in een spoke geïmplementeerd die met tussenpozen storingen melden bij het bereiken van een on-premises SQL-cluster via een ExpressRoute-circuit.

Uitdaging: Intermitterende connectiviteit en hoge latentie naar on-premises resources zonder duidelijk bewijs op pakketniveau; de bestaande NSG flow logs zijn ingeschakeld maar tonen toegestane ‘flows’ zonder latentiegegevens.

Aanbevolen Aanpak:

Implementeer Connection Monitor v2 vanaf representatieve VM’s naar de on-premises SQL FQDN en het IP-adres via TCP-poort 1433, stel tests in om de 30 seconden, en stuur de resultaten naar de centrale Log Analytics workspace om de ‘per-hop’-latentie en bereikbaarheid vast te leggen.
Schakel Network Watcher packet capture in op een betreffende VM met filters voor het bron-/bestemmings-IP van het SQL-cluster en poort 1433, en sla de PCAP’s op in een storage account met een ’lifecycle policy’; schakel tegelijkertijd VNet TAP in op het spoke-subnet om verkeer te spiegelen naar een speciale ‘collector VM’ als ‘accelerated networking’ aanwezig is.
Configureer ‘diagnostic settings’ voor Azure Firewall (Standard) om applicatie- en netwerklogs naar dezelfde Log Analytics workspace te sturen, en voer correlatiequery’s uit die de resultaten van Connection Monitor, firewall-logs en NSG flow logs combineren om SNAT-uitputting of ‘policy drops’ van de firewall te detecteren.
Gebruik IP Flow Verify en Next Hop voor een falende 5-tuple tijdens een incident; als SNAT of asymmetrische routering wordt vermoed, voeg dan een extra publiek IP-adres toe aan de Azure Firewall of implementeer een NAT Gateway in de spoke voor voorspelbare ’egress’ en werk de UDR’s bij om via de hub te routeren.

Rationale: Connection Monitor levert synthetische bereikbaarheidsdata met tijdstempels en ‘per-hop’-latentie; packet capture en VNet TAP bieden ’lossless’ forensische data wanneer ‘OS offloads’ het verkeer onzichtbaar maken. Het correleren van firewall- en NSG-logs in Log Analytics identificeert problemen met beleid (policy), SNAT of asymmetrische routering; het toevoegen van publieke IP’s of een NAT Gateway vermindert ‘port exhaustion’ en stabiliseert het ’egress’-gedrag.

← Load Balancing en verkeersbeheer · Alle domeinen · Azure Virtual WAN en Hub-Spoke →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →