Microsoft AZ-140: Networking, connettività e trasporto — Guida allo studio

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Virtual Desktop Specialty AZ-140 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Le reti, la connettività e il trasporto sono alla base di un’implementazione stabile e performante di Azure Virtual Desktop (AVD). Il piano di controllo è esposto su Internet e completamente gestito da Microsoft, mentre gli host di sessione risiedono nelle tue reti virtuali e devono raggiungere i servizi della piattaforma Azure e, spesso, le applicazioni on-premise. Una progettazione solida bilancia i principi del privilegio minimo (least privilege) e zero-trust con la necessità di un trasporto a bassa latenza e tollerante alla perdita per la sessione utente. Questa sezione consolida i pattern e le decisioni per la configurazione della rete virtuale, i controlli di accesso, la connettività in uscita, i collegamenti ibridi, l’accesso privato e la risoluzione dei problemi.

Progettazione della rete per gli host di sessione: VNet, subnet, NSG, ASG, UDR e DNS

• Topologia di VNet e subnet

  • Utilizzare un’architettura hub-and-spoke. Posizionare i servizi condivisi (Azure Firewall, NAT Gateway, VPN/ExpressRoute, Private DNS Resolver) nell’hub; posizionare gli host di sessione AVD in una o più VNet spoke per regione e livello di carico di lavoro.
  • Segmentare per funzione. Creare subnet dedicate per gli host di sessione, gli strumenti di gestione/manutenzione, Azure Bastion e qualsiasi NVA. Mantenere la AzureBastionSubnet separata e con le dimensioni richieste.
  • Indirizzamento. Allocare un numero sufficiente di IP per il margine di scalabilità automatica (autoscale) e per il ciclo di vita delle immagini. Riservare capacità di crescita per i set di scalabilità e le modalità di drain.

• NSG e ASG

  • In ingresso (Inbound): Negare per impostazione predefinita. Non esporre la porta TCP 3389 da Internet. Consentire solo:
    • Azure Bastion verso gli host di sessione sulla porta TCP 3389 per l’accesso di emergenza (break-glass) amministrativo, limitato alla AzureBastionSubnet o a un ASG di gestione.
    • RDP Shortpath per reti gestite sulla porta UDP 3390 solo da origini private attendibili (subnet di filiali, pool di indirizzi VPN aziendali o prefissi ExpressRoute).
  • In uscita (Outbound): Consentire il set minimo utilizzando service tag e FQDN. Utilizzare i service tag AzureVirtualDesktop, Storage, KeyVault, AzureActiveDirectory, AzureMonitor, WindowsUpdate e MicrosoftGraph dove applicabile. Preferire gli ASG per definire come destinazione gruppi di host di sessione piuttosto che indirizzi IP.

• UDR e routing

  • Internet predefinito e forced tunneling. Se si forza il traffico attraverso un NVA o on-premise (forced tunneling), assicurarsi che le route esplicite per il traffico del piano di controllo di AVD rimangano consentite verso Internet o siano fornite tramite Private Link. Evitare il black-holing di 0.0.0.0/0 senza consentire il traffico in uscita per i servizi Azure richiesti dall’agente AVD e da FSLogix.
  • Gateway transit e peering. Abilitare il gateway transit dall’hub agli spoke e utilizzare la propagazione BGP con attenzione; convalidare le route effettive sulle NIC per verificare il risultato finale.
  • Scalabilità in uscita (Egress). Associare un NAT Gateway alle subnet degli host di sessione quando molti host devono uscire verso Internet, per eliminare l’esaurimento delle porte SNAT e stabilizzare gli IP di uscita.

• DNS

  • Per gli host aggiunti ad Active Directory o Azure AD DS, configurare la VNet per utilizzare i server DNS del dominio appropriato; il DNS fornito da Azure non può risolvere i record SRV di AD. Per Azure AD DS, puntare il DNS della VNet agli IP del dominio gestito prima di aggiungere gli host di sessione al dominio.
  • Risoluzione dei nomi ibrida: Utilizzare Azure DNS Private Resolver per fare da ponte tra le zone DNS private di Azure e il DNS on-premise. Configurare regole in uscita (outbound) per inoltrare zone selezionate (ad esempio, zone privatelink e Azure PaaS) e regole in ingresso (inbound) per servire i client on-premise.
  • DNS privato. Collegare le zone private a tutte le VNet che devono risolvere endpoint privati (per Storage, Key Vault e AVD Private Link, se utilizzato).

Connettività e trasporto dei servizi: reverse connect, Shortpath, UDP/TCP ed endpoint richiesti

• Trasporto reverse connect

  • Gli host di sessione avviano connessioni TLS in uscita verso il control plane e i gateway di AVD; i client si connettono ai gateway tramite TLS. Il broker orchestra una connessione inversa (reverse connection) in modo che l’host di sessione non richieda mai una connessione RDP pubblica in ingresso. Questo design elimina la necessità di esporre la porta TCP 3389 su Internet e consente l’operatività dietro NAT, firewall e proxy.
  • Assicurare che il traffico TCP 443 in uscita e, per prestazioni ottimali, UDP 443 sia consentito da host e client verso i gateway e gli endpoint di servizio di AVD.

• RDP Shortpath

  • Reti gestite: Abilita un datapath UDP diretto da host a client utilizzando indirizzi IP privati, tipicamente su LAN aziendale, VPN site-to-site o ExpressRoute. La porta UDP predefinita è la 3390 sull’host di sessione. Aprire il firewall del sistema operativo dell’host e l’NSG per la porta UDP 3390 da sorgenti private attendibili. Questo percorso riduce la latenza e il jitter, migliorando l’interattività e le prestazioni multimediali.
  • Reti pubbliche: Utilizza un relay gestito da AVD per stabilire un datapath UDP sulla porta 443, migliorando le prestazioni quando la raggiungibilità diretta tramite IP privato non è disponibile. Consentire il traffico UDP 443 in uscita verso gli endpoint di servizio di AVD. Questa è la soluzione ideale per scenari di lavoro da casa senza una VPN aziendale.

• Trasporto UDP, fallback su TCP ed esperienza utente

  • RDP utilizza un doppio trasporto: un canale di controllo TCP affidabile e un canale multimediale UDP ottimizzato. Se l’UDP è bloccato, RDP effettua il fallback alla modalità solo TCP, che è più sensibile a latenza, jitter e perdita di pacchetti; gli utenti potrebbero riscontrare frame rate più bassi e audio degradato.
  • Puntare a una latenza di round-trip inferiore a 100 ms verso la regione dell’host pool; una latenza inferiore a 50 ms fornisce una reattività quasi pari a quella di un desktop locale. Utilizzare l’Azure Virtual Desktop Experience Estimator per orientare la scelta della regione.
  • QoS e DSCP. Dare priorità al traffico UDP 3390 (Shortpath per reti gestite) o UDP 443 (Shortpath per reti pubbliche) e al canale di controllo TCP 443 sui dispositivi perimetrali (edge) per proteggere la qualità della sessione in caso di contesa.

• Connettività ai servizi Azure richiesta e pattern degli endpoint in uscita

  • Consentire agli host di sessione di raggiungere:
    • Il service tag AzureVirtualDesktop su TCP 443 e UDP 443.
    • Endpoint di Storage per i container FSLogix e la diagnostica.
    • AzureActiveDirectory e Microsoft Graph per i flussi di identità e token.
    • Endpoint di WindowsUpdate e di content delivery Microsoft per l’applicazione di patch e le Microsoft 365 Apps.
    • AzureMonitor e Log Analytics se si utilizzano gli AVD Insights.
  • Preferire i service tag e le regole basate su FQDN su Azure Firewall. Per le NVA, mantenere una allowlist (lista di permessi) aggiornata ed evitare l’intercettazione TLS per questi endpoint.

• Considerazioni sui proxy

  • L’agente AVD supporta il traffico in uscita tramite il proxy di sistema. Configurare WinHTTP sugli host di sessione se un proxy esplicito è obbligatorio; evitare proxy che richiedono l’autenticazione interattiva per il traffico di servizio.
  • Esempio per configurare il proxy di sistema:

netsh winhttp set proxy "http=myproxy.contoso.com:8080;https=myproxy.contoso.com:8080" bypass-list="localhost;127.0.0.1"

Connettività ibrida e perimetro: VPN, ExpressRoute, Azure Firewall, proxy, Private Link, DNS privato e Bastion

• Verso le applicazioni on-premise

  • VPN Gateway: Veloce da implementare, adatto per larghezza di banda medio-piccola e connettività di filiali. Utilizzare la modalità active-active con BGP per la resilienza.
  • ExpressRoute: Connettività privata e prevedibile per carichi di lavoro ad alta velocità, sensibili alla latenza e per popolazioni di utenti su larga scala. Abilitare ExpressRoute FastPath per ridurre i salti (hop) nel datapath. Utilizzare la connessione al peering Microsoft per il SaaS se necessario, ma tenere presente che gli endpoint di servizio AVD richiedono comunque Internet o Private Link.
  • Virtual WAN può semplificare i design multi-filiale con partner SD-WAN integrati, policy centralizzate e transito globale.

• Azure Firewall e controlli perimetrali

  • Utilizzare Azure Firewall Premium per l’ispezione TLS dove supportato; non eseguire l’ispezione TLS sul traffico del control plane di AVD, poiché il certificate pinning e l’uso di WebSocket possono interrompere la connettività e degradare le prestazioni.
  • Utilizzare i tag FQDN AzureVirtualDesktop e WindowsUpdate per semplificare la gestione delle regole. Posizionare Azure Firewall nell’hub e pubblicare le route predefinite tramite UDR verso gli spoke; creare le eccezioni necessarie per il traffico diretto a Internet per l’accesso ai servizi AVD o implementare Private Link.

• Endpoint privati e Private Link

  • Storage e Key Vault: Utilizzare gli Endpoint Privati per i container dei profili FSLogix e per eventuali segreti utilizzati durante il provisioning. Collegare le zone DNS private privatelink corrispondenti alle proprie VNet e configurare l’inoltro (forwarding) per i client on-premise se necessario.
  • Azure Virtual Desktop: Configurare Private Link per AVD, dove disponibile, per limitare l’accesso al control plane e ai gateway alla propria rete privata. Creare gli endpoint privati di AVD in una subnet dedicata e abilitare le zone DNS privatelink corrispondenti, ad esempio le zone privatelink del servizio avd, in modo che host e client risolvano gli FQDN di AVD in indirizzi IP privati. Questo riduce l’egress pubblico e rafforza la postura zero-trust.

• Azure Bastion per l’accesso amministrativo

  • Utilizzare Azure Bastion per l’accesso RDP just-in-time basato su browser agli host di sessione tramite TCP 443, senza esporre porte in ingresso su Internet. Limitare le regole di autorizzazione RDP sugli host di sessione alla AzureBastionSubnet tramite NSG o ASG. Mantenere l’RDP diretto disabilitato dalle reti non attendibili.

Monitoraggio e risoluzione dei problemi: Network Watcher e diagnostica

• Azure Monitor e AVD Insights

  • Abilitare AVD Insights per una visibilità end-to-end sulla qualità della connessione, sui tempi di accesso e sulle prestazioni della sessione. Correlare i picchi nel tempo di round trip o nella perdita di pacchetti UDP con le lamentele degli utenti.

• Strumenti di Network Watcher

  • Risoluzione dei problemi di connessione (Connection troubleshoot). Convalidare la raggiungibilità da un host di sessione ai servizi Azure, agli account di archiviazione e agli endpoint on-premise. Esempio PowerShell:

$nw = Get-AzNetworkWatcher -Location "EastUS"
Test-AzNetworkWatcherConnectivity -NetworkWatcher $nw `
  -SourceId "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vmName>" `
  -DestinationAddress "store1.file.core.windows.net" -DestinationPort 445

• Regole di sicurezza e route effettive. Ispezionare le regole NSG e le route effettive sulla NIC per confermare che le porte UDP 3390, UDP 443 e TCP 443 siano consentite come previsto.

• Log di flusso NSG v2. Inviarli a un workspace di Log Analytics per verificare il traffico in uscita (egress) dall’host di sessione e identificare i “deny” che forzano il fallback su TCP.

• Cattura dei pacchetti. Utilizzarla su un host di test per confermare lo stabilimento di UDP Shortpath e per analizzare ritrasmissioni e jitter.

• Diagnostica del client e dell’host

  • All’interno di una sessione, monitorare i contatori “RemoteFX Graphics Frames Skipped” e lo stato del trasporto RDP per distinguere tra colli di bottiglia a livello di server, rete o client.
  • Utilizzare le informazioni di connessione del client AVD per confermare la modalità di trasporto (UDP/Shortpath vs TCP) e il tempo di round trip. Se si osservano solo percorsi TCP, convalidare le autorizzazioni su proxy e firewall e verificare la presenza di blocchi sulle porte UDP 3390/443.

Scenario pratico di un problema

IKEA prevede di fornire Azure Virtual Desktop a 1.200 pianificatori di negozio e buyer in tutta Europa. Gli utenti accedono alla GUI di SAP e a un server di licenze on-premise, mentre metà degli utenti lavora da remoto senza una VPN aziendale. Gli utenti segnalano una reattività incostante durante le ore di punta e fallimenti occasionali nell’accesso dopo l’introduzione di un nuovo proxy in uscita.

1. Progettare un’architettura hub-and-spoke con scalabilità del traffico in uscita (egress)

   • Creare una VNet hub con Azure Firewall Premium e NAT Gateway; distribuire VNet spoke per regione per gli host di sessione. Associare il NAT Gateway a ogni subnet degli host di sessione per evitare l’esaurimento delle porte SNAT quando migliaia di flussi UDP/TCP si aprono durante gli accessi mattutini.
   • Perché: Stabilizza gli IP di egress e fornisce un numero sufficiente di porte effimere, prevenendo fallimenti di connessione intermittenti verso i gateway AVD e lo storage.

2. Implementare regole NSG e ASG precise

   • Assegnare le NIC degli host di sessione a un ASG. Consentire in ingresso la porta UDP 3390 solo da prefissi privati attendibili, consentire in ingresso la porta TCP 3389 dalla AzureBastionSubnet e consentire in uscita le porte TCP/UDP 443 verso i service tag AzureVirtualDesktop, Storage, AzureActiveDirectory e AzureMonitor.
   • Perché: Impone il principio del privilegio minimo, abilitando al contempo Shortpath per reti gestite e un’amministrazione sicura tramite Bastion.

3. Configurare il DNS per la risoluzione dei nomi ibrida

   • Puntare il DNS della VNet ai domain controller in Azure. Distribuire Azure DNS Private Resolver con regole in uscita per inoltrare le zone privatelink e le zone PaaS di Azure; configurare il DNS on-premise per inoltrare le zone private di Azure all’endpoint in ingresso del resolver.
   • Perché: Assicura che gli host AVD risolvano i record SRV di AD, gli endpoint privati di FSLogix e qualsiasi FQDN di AVD Private Link in modo coerente tra le reti cloud e on-premise.

4. Abilitare RDP Shortpath sia per le reti gestite che per quelle pubbliche

   • Attivare Shortpath per le reti gestite sugli host di sessione e aprire internamente la porta UDP 3390; abilitare Shortpath per le reti pubbliche per consentire il relay su UDP 443 per i lavoratori remoti senza VPN. Aggiornare la QoS sui router delle filiali per dare priorità alle porte UDP 3390 e UDP/TCP 443 per i flussi AVD.
   • Perché: Massimizza le prestazioni interattive per gli utenti in ufficio tramite UDP privato diretto e migliora l’esperienza degli utenti da casa tramite UDP 443, con la QoS che protegge questi flussi durante la congestione.

5. Proteggere e semplificare il perimetro con Azure Firewall e policy del proxy

   • Su Azure Firewall, utilizzare i tag FQDN per AzureVirtualDesktop e WindowsUpdate; escluderli dall’ispezione TLS. Sul nuovo proxy in uscita, configurare autorizzazioni esplicite per il WebSocket di AVD su TLS e disabilitare l’autenticazione per il traffico dell’agente AVD. Impostare il proxy WinHTTP in modo coerente sugli host di sessione.
   • Perché: Evita di interrompere la connessione inversa (reverse connect) e Shortpath per reti pubbliche a causa dell’intercettazione TLS o dell’autenticazione del proxy, mantenendo al contempo una governance centralizzata.

6. Fornire accesso privato a servizi PaaS critici

   • Creare Private Endpoint per gli account di archiviazione FSLogix e collegare le zone DNS private privatelink necessarie a tutte le VNet di AVD; validare che la comunicazione SMB su IP privati abbia successo. Valutare AVD Private Link per limitare l’accesso al piano di controllo e al gateway a IP privati, laddove le policy aziendali lo richiedano.
   • Perché: Rimuove la dipendenza dall’egress pubblico per i profili utente e, opzionalmente, per il servizio AVD, migliorando la postura di sicurezza e la prevedibilità.

7. Stabilire la connettività ibrida alle applicazioni on-premise

   • Distribuire ExpressRoute con FastPath verso il data center primario per un accesso a bassa latenza a SAP e al server delle licenze; mantenere un VPN Gateway per il backup delle filiali. Annunciare i prefissi on-premise richiesti con BGP e verificare il next hop e le route effettive sulle NIC degli host di sessione.
   • Perché: ExpressRoute fornisce prestazioni prevedibili su larga scala, con un failover su VPN per la resilienza.

8. Monitorare e convalidare

   • Abilitare AVD Insights e Connection Monitor di Network Watcher per test sintetici verso SAP e lo storage. Attivare i Log di flusso NSG per confermare l’utilizzo delle porte UDP 3390 e UDP 443. Utilizzare la funzione “Connection troubleshoot” durante le ore di punta per isolare i colli di bottiglia del proxy o del firewall.
   • Perché: La visibilità basata sui dati conferma che i percorsi Shortpath sono attivi, che la capacità di egress è adeguata e che le policy perimetrali non stanno introducendo perdite o latenza inaspettate.

← Identità · Tutti i domini · Immagini e provisioning degli host di sessione →

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

Sfoglia Microsoft →