Microsoft AZ-700: Monitoraggio della rete e risoluzione dei problemi — Guida allo studio

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

Fa parte della Microsoft Azure Network Engineer AZ-700 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Strumenti di osservabilità e origini dati

L’osservabilità nel networking di Azure si concentra su Network Watcher, Azure Monitor (Log Analytics) e sulle impostazioni di diagnostica che trasmettono la telemetria dalle risorse a un’area di lavoro centrale o a un account di archiviazione. Network Watcher fornisce acquisizione di pacchetti, verifica del flusso IP, hop successivo, risoluzione dei problemi di connessione e Connection Monitor; Connection Monitor v2 supporta test multi-endpoint e multi-protocollo e archivia i risultati in un’area di lavoro Log Analytics per una telemetria interrogabile. I log di flusso NSG vengono abilitati tramite Network Watcher e scrivono record JSON in un account di archiviazione; l’abilitazione di Traffic Analytics (che richiede i log di flusso + un’area di lavoro Log Analytics) arricchisce tali log con insight applicativi/geografici e visualizzazioni. Le impostazioni di diagnostica su Azure Firewall, Application Gateway/WAF, Front Door e i bilanciatori di carico dovrebbero essere instradate verso la stessa area di lavoro Log Analytics per correlare i segnali. Le trappole comuni includono regole firewall dell’account di archiviazione che bloccano la scrittura dei log di flusso, dimenticare di abilitare Network Watcher per ogni regione nei tenant più vecchi e policy di conservazione incoerenti tra l’archiviazione e Log Analytics. I compromessi tra costi e capacità sono chiari: scrivere i log grezzi su un account di archiviazione per un’archiviazione a basso costo rispetto all’ingestione in Log Analytics per query e avvisi (costo più elevato ma valore diagnostico molto maggiore). Il Controllo degli Accessi in Base al Ruolo (Monitor Reader più Storage Blob Data Reader dove richiesto) deve essere configurato in modo che le pipeline di diagnostica possano scrivere e gli analisti possano leggere i log.

Acquisizione di pacchetti, Connection Monitor e diagnostica approfondita

Per la risoluzione dei problemi a livello di pacchetto, l’acquisizione di pacchetti di Network Watcher (tramite portale/CLI/PowerShell) crea file PCAP in un account di archiviazione o in un file locale sulla VM. Configurare i filtri di acquisizione dei pacchetti (protocollo, IP di origine/destinazione, porte) e limiti di dimensione/tempo per evitare un impatto eccessivo sull’archiviazione e sulle prestazioni. Per le VM ad alto throughput con rete accelerata, la visibilità dei pacchetti lato host potrebbe essere limitata; utilizzare VNet TAP per eseguire il mirroring del traffico verso una VM collettore o una NVA per evitare di perdere i pacchetti sottoposti a offload. Connection Monitor dovrebbe essere usato per test sintetici attivi: definire gli endpoint di origine e destinazione (IP, FQDN, porta), scegliere la frequenza dei test e abilitare la latenza per-hop e l’acquisizione del percorso per la diagnosi multi-segmento. Utilizzare IP Flow Verify per verificare se una specifica 5-tuple è consentita o negata da NSG/UDR, e Next-hop per confermare il routing effettivo. Attenzione alle insidie: l’acquisizione di pacchetti su VM Windows può richiedere autorizzazioni elevate e può essere influenzata dagli offload del sistema operativo; l’acquisizione di pacchetti può essere intensiva in termini di CPU/disco, quindi è preferibile usare filtri mirati e limiti di tempo. Per l’ispezione continua dei pacchetti su larga scala, abbinare VNet TAP a un’appliance di analisi dei pacchetti o a un SIEM cloud in grado di ingerire flussi PCAP.

Log di flusso NSG, Traffic Analytics e diagnostica di sicurezza

I log di flusso NSG (versione 2) forniscono record di flusso con timestamp, 5-tuple, conteggi di byte/pacchetti e la decisione (consentito/negato). Non contengono il payload, i dettagli della sessione a livello di applicazione o il TLS decrittato. Traffic Analytics arricchisce i log di flusso con i principali “talker”, ASN e mappatura geografica, richiedendo un’area di lavoro Log Analytics. Azure Firewall, Application Gateway/WAF e Azure Front Door emettono la propria diagnostica; questa deve essere indirizzata a Log Analytics per un’interrogazione unificata. Importanti trappole di progettazione: le regole NSG applicate a livello di NIC hanno la precedenza sulle regole a livello di subnet; esistono regole predefinite (ad es. AzureLoadBalancer, regole internet) che non possono essere rimosse, ma solo sovrascritte da regole con priorità più alta. L’utilità dei log di flusso dipende dalla strategia di conservazione e ingestione: una lunga conservazione in Log Analytics è costosa, mentre una conservazione breve rischia di far perdere prove forensi. Combinare i log di flusso NSG con i log di diagnostica del Firewall e le regole di Alert basate su query Kusto per rilevare movimenti laterali o esfiltrazione di dati. Quando si pianificano azioni correttive, considerare l’aggiunta di IP pubblici dedicati ad Azure Firewall per mitigare l’esaurimento delle porte SNAT e sfruttare le DiagnosticSettings per instradare i dati verso Event Hubs per l’integrazione con un SIEM, se i costi di Log Analytics sono proibitivi.

Pattern di troubleshooting, insidie del routing e compromessi di progettazione

Quando si risolvono problemi di connettività, seguire un approccio a più livelli: verificare NSG/UDR a livello di risorsa, controllare le route effettive e il next hop, utilizzare IP Flow Verify e Connection Troubleshoot, quindi passare alla cattura dei pacchetti o a VNet TAP se necessario. Le insidie del routing emergono spesso con il forced tunneling, CIDR sovrapposti o UDR configurate in modo errato che inviano traffico nella AzureFirewallSubnet senza adeguate route di ritorno. Per il bilanciamento del carico e la scalabilità, scegliere tra Azure Standard Load Balancer, Application Gateway WAF e Front Door in base alle esigenze di livello L4 o L7 e alla gestione del traffico globale o regionale. Considerare questi compromessi tra le SKU:

Azure Firewall Standard vs Premium: La versione Premium aggiunge ispezione TLS, IDPS e filtraggio URL a un costo maggiore; scegliere la Premium quando sono richieste un’ispezione approfondita del traffico e un controllo normativo.
Azure Front Door Standard vs Premium: La versione Premium supporta funzionalità WAF avanzate e integrazioni con private link; la Standard ha un costo inferiore per le tipiche esigenze di CDN globale + routing.
VNet TAP vs packet capture: Il TAP ha un costo più elevato ma è necessario per la cattura lossless su larga scala e quando l’accelerated networking effettua l’offload dei pacchetti. I compromessi si concentrano su prestazioni, costo e resilienza: le NVA possono essere più economiche o più ricche di funzionalità rispetto a Firewall Premium, ma aggiungono un sovraccarico di gestione e il rischio di un single-point-of-failure, a meno che non siano progettate con l’alta disponibilità (HA). Pianificare la capacità SNAT, riservare indirizzi IP pubblici di riserva e predisporre pipeline di diagnostica per bilanciare le esigenze di osservabilità con i costi di inserimento (ingestion).

Problema Pratico: Scenario d’Uso

Scenario: Contoso Electronics gestisce una presenza Azure su due region (EastUS, WestEurope) con VNet hub-and-spoke, un Azure Firewall Standard nell’hub, molteplici Application Gateway WAF negli spoke e un’area di lavoro Log Analytics centrale per il monitoraggio. Di recente hanno distribuito un set di VM di produzione in uno spoke che segnalano errori intermittenti nel raggiungere un cluster SQL on-premise tramite un circuito ExpressRoute.

Sfida: Connettività intermittente e alta latenza verso le risorse on-premise senza chiare evidenze a livello di pacchetto; i flow log degli NSG esistenti sono abilitati ma mostrano flussi consentiti senza metriche di latenza.

Approccio Raccomandato:

Distribuire Connection Monitor v2 da VM rappresentative verso l’FQDN e l’IP del SQL on-premise utilizzando la porta TCP 1433, impostare test ogni 30 secondi e inviare i risultati all’area di lavoro Log Analytics centrale per catturare la latenza per-hop e la raggiungibilità.
Abilitare la cattura dei pacchetti di Network Watcher su una VM interessata con filtri per l’IP di origine/destinazione del cluster SQL e la porta 1433, salvare i file PCAP in un account di storage con una policy sul ciclo di vita; contemporaneamente, abilitare VNet TAP sulla subnet dello spoke per eseguire il mirroring del traffico verso una VM collettore dedicata se è presente l’accelerated networking.
Configurare le impostazioni di diagnostica per Azure Firewall (Standard) per inviare i log delle applicazioni e di rete alla stessa area di lavoro Log Analytics, ed eseguire query di correlazione che uniscono i risultati di Connection Monitor, i log del firewall e i flow log degli NSG per rilevare l’esaurimento delle porte SNAT del firewall o le cadute di pacchetti dovute alle policy.
Utilizzare IP Flow Verify e Next Hop per una 5-tupla che presenta l’errore durante un incidente; se si sospetta un problema di SNAT o di routing asimmetrico, aggiungere un indirizzo IP pubblico aggiuntivo all’Azure Firewall o distribuire un NAT Gateway nello spoke per un egress prevedibile e aggiornare le UDR per instradare attraverso l’hub.

Logica: Connection Monitor fornisce dati sintetici e con timestamp sulla raggiungibilità e la latenza per-hop; la cattura dei pacchetti e VNet TAP forniscono dati forensi lossless quando l’offload del sistema operativo nasconde il traffico. La correlazione dei log del firewall e degli NSG in Log Analytics identifica problemi di policy, SNAT o routing asimmetrico; l’aggiunta di IP pubblici o di un NAT Gateway mitiga l’esaurimento delle porte e stabilizza il comportamento dell’egress.

← Bilanciamento del carico e gestione del traffico · Tutti i domini · Azure Virtual WAN e Hub-Spoke →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →