Microsoft AZ-700: Progettazione di Azure Virtual Network — Guida allo studio
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.
Pianificazione dello spazio di indirizzi e delle subnet
Un piano di indirizzamento IP disciplinato previene future rilavorazioni ed evita collisioni con reti on-premise o altre VNet. Utilizzare blocchi CIDR gerarchici (ad esempio, un /16 per ogni principale unità di business, /24 per VNet, da /26 a /22 per subnet a seconda del ruolo) e riservare intervalli contigui per espansione, peering e mappature di siti VPN/S2S. Azure impone requisiti di nome e subnet per diversi servizi della piattaforma: GatewaySubnet deve esistere (ed essere dimensionata per includere il gateway VPN e le sue unità di scala), AzureFirewallSubnet deve essere dedicata e denominata AzureFirewallSubnet, e AzureBastionSubnet deve essere una /27 dedicata o più grande. Anche Application Gateway e molte appliance virtuali di rete richiedono subnet dedicate (senza altre risorse). Pianificare la non sovrapposizione degli indirizzi tra VNet in peering e intervalli on-premise; spazi di indirizzi sovrapposti interrompono il peering, la VPN e il routing. Considerare la delega di subnet durante l’implementazione di servizi della piattaforma (AKS, istanze gestite di Azure Database) ed evitare di inserire NSG o UDR che entrano in conflitto con le route di piattaforma richieste per tali servizi. Una trappola comune è sottodimensionare la GatewaySubnet o la AzureFirewallSubnet; questi servizi possono scalare e richiedere IP aggiuntivi nel tempo. Compromessi: CIDR più piccoli risparmiano spazio di indirizzamento ma aumentano il rischio di future riconfigurazioni; CIDR più grandi non costano nulla ma aumentano la superficie di gestione. Documentare tutte le assegnazioni e riservare blocchi per endpoint privati PaaS, jump host, agenti di monitoraggio e capacità NAT in uscita (egress).
Peering di VNet, transito tramite gateway e precedenza delle route
Il peering di VNet fornisce connettività a bassa latenza e alta larghezza di banda, ma non è transitivo: il traffico da uno spoke in peering non viene instradato automaticamente attraverso una seconda VNet in peering per raggiungere l’on-premise. Per centralizzare la connettività on-premise è necessario implementare una VNet hub con un VPN Gateway o un gateway ExpressRoute. Configurare il peering dell’hub con allowGatewayTransit abilitato e configurare il peering dello spoke con useRemoteGateways abilitato; il VPN Gateway deve esistere solo nell’hub. Ricordare che il peering richiede spazi di indirizzi non sovrapposti e supporta sia il peering regionale che quello globale (il peering globale comporta costi di trasferimento dati e una latenza leggermente superiore). La precedenza delle route è importante: le route definite dall’utente (UDR) hanno la precedenza sulle route apprese tramite BGP e su quelle di sistema; le route BGP hanno la precedenza sulle route di sistema. Se è necessario il forced-tunneling per l’ispezione del traffico in uscita (egress), creare UDR che puntano a una Virtual Appliance (NVA) o a un Azure Firewall, quindi annunciare le route appropriate verso l’on-premise tramite BGP, se necessario. Trappole comuni includono dimenticare di impostare allowGatewayTransit sull’hub o useRemoteGateways sugli spoke, non riscaricare le configurazioni dei client P2S dopo aver aggiunto degli spoke (i client P2S necessitano di route aggiornate) e dare per scontato che il peering sia transitivo. Scegliere gli SKU del VPN Gateway in base al throughput e alle funzionalità P2S: considerare VpnGw1/2/3 per P2S di produzione e BGP; lo SKU Basic manca di molte funzionalità.
- SKU di VPN Gateway: VpnGw1 — throughput moderato, supporta OpenVPN/IKEv2/P2S; VpnGw2 — throughput più elevato e scalabilità TLS; VpnGw3 — throughput massimo e scala più grande. Basic — funzionalità limitate e non raccomandato per scenari hub.
Service endpoint vs private endpoint e implicazioni DNS
I service endpoint estendono l’identità della VNet ai servizi PaaS di Azure (Storage, SQL, Cosmos DB) in modo che il traffico utilizzi la backbone di Microsoft, mentre l’endpoint pubblico del servizio è protetto e accessibile solo da subnet selezionate. I private endpoint inseriscono un’interfaccia di rete nella subnet che mappa all’IP privato della risorsa PaaS, fornendo una vera connettività privata. Scegliere i service endpoint quando si desidera un semplice controllo degli accessi a livello di subnet senza modifiche al DNS; scegliere i private endpoint quando si richiede l’accesso per singola risorsa, l’isolamento a livello di VNet o la disabilitazione completa dell’accesso dalla rete pubblica. I private endpoint creano una ENI e devono essere associati a una zona DNS privata (privatelink.<service>.azure.com) o richiedono record DNS A manuali — una trappola frequente è trascurare il DNS, il che porta i client a risolvere l’IP pubblico invece dell’endpoint privato. Tenere inoltre presente che i private endpoint consumano un IP dalla subnet di destinazione; pianificare la capacità di indirizzi IP. I service endpoint non eliminano l’endpoint pubblico: per bloccare completamente un account di archiviazione è necessario disabilitare l’accesso dalla rete pubblica dopo aver abilitato il private endpoint. Compromessi operativi e di costo: i private endpoint aumentano la gestione (DNS per risorsa e approvazioni) e la complessità operativa, ma offrono un isolamento più forte; i service endpoint sono più semplici e meno costosi, ma meno granulari.
← ExpressRoute e connettività WAN · Tutti i domini · Networking ibrido →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →