Microsoft AZ-700: Networking ibrido — 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.

Fondamenti di connettività ibrida e vincoli di indirizzamento

La connettività ibrida riguarda la raggiungibilità IP affidabile, instradabile e sicura tra le reti on-premise e le reti virtuali di Azure. Quando si pianifica l’indirizzamento della rete virtuale, è bene ricordare che alcune risorse gestite da Azure all’interno di una subnet richiedono un’allocazione di indirizzi contigua e non in conflitto, e talvolta indirizzi riservati specifici: i load balancer di Azure e le subnet del gateway devono essere ritagliate deliberatamente (la GatewaySubnet deve avere esattamente questo nome ed essere dimensionata per supportare la scalabilità dello SKU del gateway), e gli endpoint privati e gli endpoint di servizio gestiti da Azure richiedono indirizzi prelevati dalla VNet che li ospita. La sovrapposizione dei prefissi on-premise e Azure è la trappola più comune: gli intervalli sovrapposti compromettono il routing e la selezione delle route BGP, creano routing asimmetrico e complicano le policy dei firewall. Utilizzare segmenti di almeno /27–/24 per le subnet che ospitano firewall stateful, load balancer o molti endpoint privati; riservare una GatewaySubnet dedicata (/27 o più grande a seconda dello SKU). Il DNS è altrettanto critico: gli endpoint privati utilizzano le zone DNS private della piattaforma (ad esempio, privatelink.database.windows.net), quindi sono necessari inoltri condizionali (conditional forwarders) o Azure DNS Private Resolver on-premise per risolvere i nomi privati di Azure. I compromessi di progettazione si concentrano sull’utilizzo degli IP rispetto alla resilienza: schemi IPv4 più densi risparmiano spazio di indirizzamento ma aumentano il rischio di collisioni e di migrazione, mentre prefissi più grandi e meno efficienti semplificano l’espansione futura e le strategie di advertisement BGP.

SKU di VPN Gateway, fondamenti di BGP e Local Network Gateway

La scelta dello SKU corretto per il VPN gateway (VpnGw1–VpnGw5, Basic dove legacy) influisce direttamente sul throughput, sulle sessioni S2S/P2S concorrenti e sulle funzionalità disponibili come la modalità active-active o i limiti di route. Utilizzare gateway basati su route (route-based) per i design ibridi moderni; quelli basati su policy (policy-based) sono legacy e limitano il BGP. Il BGP fornisce uno scambio dinamico di prefissi e supporta la resilienza del percorso, il failover automatico e la prioritizzazione dei prefissi — configurare l’ASN dell’Azure VPN Gateway (predefinito 65515) e farlo corrispondere o stabilire un peering con l’ASN on-premise nell’oggetto Local Network Gateway. Il Local Network Gateway memorizza l’IP pubblico on-premise, lo spazio (o gli spazi) di indirizzi e, facoltativamente, l’IP del peer BGP e l’ASN; dimenticare di popolare l’IP del peer BGP o non far corrispondere gli ASN impedisce la propagazione delle route e porta a soluzioni alternative basate su route statiche. Considerare gli hub di Azure Virtual WAN per la scalabilità multi-sito e il routing di transito integrato; gli hub VWAN supportano S2S e P2S su larga scala e si integrano con Azure Firewall ed ExpressRoute. Prestare attenzione alla propagazione della tabella di routing: per impostazione predefinita, alcune topologie hub-and-spoke o con appliance virtuali sopprimono la propagazione automatica; potrebbero essere necessarie UDR esplicite o advertisement di route BGP. Compromessi: SKU più alti e VWAN aumentano i costi ma riducono l’overhead di gestione e migliorano il throughput e la scalabilità del routing.

Scelte di progettazione Point-to-Site, supporto client e integrazione DNS

Le scelte di progettazione Point-to-Site (P2S) determinano la compatibilità dei client, l’autenticazione e la scalabilità. OpenVPN (SSL) è il più multipiattaforma e consigliato per client macOS, Linux e mobili; IKEv2 è leggero e funziona bene con i client nativi di macOS; SSTP rimane un’opzione per scenari più vecchi solo per Windows. Le modalità di autenticazione includono Azure Active Directory (consigliato per l’integrazione dell’identità e l’accesso condizionale), quella basata su certificati e RADIUS per soluzioni MFA on-premise o basate su RADIUS. Lo SKU del VPN Gateway determina il numero di tunnel P2S e il throughput; scegliere VpnGw2/3 per pool di utenti di medie e grandi dimensioni e VpnGw4/5 per un utilizzo su larga scala o sensibile al throughput. Gli endpoint privati e P2S interagiscono tramite DNS: per consentire ai client P2S di risolvere i nomi degli endpoint privati (zone privatelink), è necessario collegare le zone DNS private alla VNet oppure utilizzare Azure DNS Private Resolver e inoltri condizionali (conditional forwarders) dal DNS on-premise o del client. Una trappola frequente è dimenticare che i client P2S normalmente utilizzano il DNS di Azure fornito dal gateway solo quando il client esegue il push delle route e delle impostazioni DNS; configurazioni esplicite del suffisso DNS e degli inoltri evitano problemi del tipo “impossibile risolvere l’endpoint privato”. Bilanciare scalabilità e costi: l’autenticazione tramite certificati è a basso costo ma più difficile da revocare; Azure AD offre controlli di sicurezza moderni ma aggiunge costi di licenza e complessità.

Routing di transito, forced tunneling, ispezione e posizionamento delle appliance di sicurezza

La progettazione del transito tra più VNet, ambienti on-premise e appliance di ispezione richiede una chiara applicazione dei confini di routing e NAT. Forzare il traffico attraverso Azure Firewall o appliance virtuali richiede route definite dall’utente (UDR) che puntano all’IP privato del firewall o l’uso del routing dell’hub di Virtual WAN per centralizzare l’ispezione. Se è necessario un proxy completamente trasparente o l’ispezione TLS, posizionare l’appliance in una subnet di ispezione dedicata e assicurarsi che gli SKU del gateway subnet e del firewall supportino il transito per il throughput previsto. Prestare attenzione al comportamento di SNAT e alla scelta degli SKU degli IP pubblici: gli IP pubblici Standard e NAT Gateway sono consigliati per un SNAT in uscita prevedibile e per le regole di sicurezza; NAT Gateway abbinato a un set di IP pubblici Standard scarica il carico di SNAT ed evita la proliferazione di IP pubblici per singola VM. Una trappola è il routing asimmetrico, che si verifica quando le route on-premise e le UDR di Azure fanno sì che il traffico di ritorno bypassi l’appliance prevista; assicurarsi che tutti gli spoke annuncino i prefissi richiesti tramite BGP o dispongano di UDR che incanalano il traffico verso il punto di ispezione. Prestazioni vs costi: un’architettura hub-and-spoke con Azure Firewall Premium o appliance di terze parti ad alto throughput aumenta la protezione e la gestione centralizzata, ma incrementa i costi e il rischio di guasto del singolo hub, a meno che non si implementino hub ridondanti in modalità active-active e si accoppino i gateway tra le region.

Problema Pratico: Scenario d’Uso

Scenario: Contoso Ltd ha due datacenter on-premise (Seattle e Amsterdam) e un ambiente Azure esistente con tre VNet (VNet-Prod, VNet-Shared, VNet-Dev) in un’unica VNet hub (VNet-Hub). Attualmente utilizzano un VPN Gateway VpnGw1 per Seattle e una connessione site-to-site verso un hub di Azure Virtual WAN per Amsterdam. Gli endpoint privati sono utilizzati per Azure SQL nella VNet-Shared.

Sfida: Contoso necessita di connettività ibrida resiliente e scalabile con routing dinamico (BGP) tra entrambi i datacenter e Azure, supporto P2S affidabile per gli utenti macOS, risoluzione DNS degli endpoint privati dall’ambiente on-premise e ispezione centralizzata del traffico in uscita dagli spoke attraverso Azure Firewall.

Approccio Raccomandato:

Implementare un nuovo VPN Gateway VpnGw3 basato su route nella VNet-Hub, configurato in modalità active-active con BGP abilitato (impostare esplicitamente l’ASN del gateway) e aggiornare gli oggetti Local Network Gateway con gli IP dei peer BGP on-premise e i relativi ASN; migrare la connessione S2S di Seattle sul nuovo gateway per supportare un throughput più elevato e limiti di route maggiori.
Consolidare la connessione di Amsterdam nell’hub stabilendo una connessione ExpressRoute o migrando l’hub VWAN a un peering con la VNet-Hub; garantire lo scambio di route BGP tra entrambi i datacenter per evitare route statiche e abilitare il failover automatico.
Configurare la connessione P2S utilizzando il protocollo OpenVPN con autenticazione Azure AD sul VpnGw3 per supportare i client macOS (con IKEv2 come fallback) e dimensionare i pool di client in base ai limiti del VpnGw3; pubblicare un server d’inoltro condizionale (conditional forwarder) sul DNS on-premise per inoltrare le zone privatelink.* a un Azure DNS Private Resolver implementato nella VNet-Shared e collegato alle zone DNS private per gli endpoint privati.
Implementare Azure Firewall (Standard o Premium se è richiesta l’ispezione TLS) nella VNet-Hub in configurazione active-active e creare UDR per le subnet degli spoke che indirizzano la rotta 0.0.0.0/0 all’IP privato del Firewall; collegare un NAT Gateway con IP pubblici Standard al firewall o utilizzare l’IP pubblico del Firewall per SNAT esplicito e per la registrazione dei log in un’area di lavoro Log Analytics centralizzata.

Motivazione: L’utilizzo di VpnGw3 con BGP fornisce propagazione dinamica delle route e throughput per la resilienza multi-sito; OpenVPN+Azure AD supporta gli utenti macOS in modo sicuro; l’inoltro DNS verso Azure DNS Private Resolver garantisce la risoluzione dei nomi degli endpoint privati dall’ambiente on-premise; centralizzare l’ispezione in un hub con Azure Firewall e UDR evita il routing asimmetrico e semplifica la gestione delle policy, scambiando un costo maggiore con sicurezza e osservabilità centralizzate.

← Progettazione di Azure Virtual Network · Tutti i domini · Azure DNS e risoluzione dei nomi →

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