Reti virtuali e subnet di Azure

Le reti virtuali di Azure (VNets) e le subnet sono gli elementi costitutivi fondamentali di ogni rete Azure. Questo articolo illustra come le reti virtuali forniscono isolamento, come le subnet organizzano le risorse e come ridimensionare e strutturare la rete per i carichi di lavoro di produzione.

Informazioni su questo articolo

Questo articolo illustra i confini di isolamento della VNet, il dimensionamento delle subnet e gli indirizzi riservati, le subnet di piattaforma dedicate a servizi come Firewall di Azure e Application Gateway, il peering di VNet e i modelli comuni di layout di rete.

Chi ha bisogno di questo articolo

Leggere questo articolo se:

  • Stai distribuendo il tuo primo carico di lavoro in Azure e hai bisogno di capire come funziona la rete prima di creare le risorse.
  • State pianificando un ambiente con più carichi di lavoro e dovete decidere quante VNets e subnet creare.
  • La migrazione dei carichi di lavoro locali a Azure e la necessità di comprendere in che modo la rete Azure differisce dalla rete fisica.
  • È necessario ridimensionare correttamente le subnet per i servizi della piattaforma Azure, ad esempio Firewall di Azure, Gateway VPN o Servizio Azure Kubernetes (AKS).
  • Si vuole comprendere quando separare i carichi di lavoro in reti virtuali diverse anziché mantenerli nella stessa rete virtuale.

Focus su lift-and-shift: rispecchiare in Azure la segmentazione delle subnet locali. Mappare le VLAN e le zone di sicurezza esistenti sulle subnet, mantenere gli spazi di indirizzamento allineati agli intervalli che il team già utilizza e dimensionare le subnet con un margine ampio, in modo da non dover riassegnare gli indirizzi IP durante la migrazione.

Focus sulla modernizzazione: progettare le subnet in funzione dei servizi della piattaforma e dell'automazione. Dimensionate correttamente le subnet per AKS, gli endpoint privati e i servizi di piattaforma dedicati e pianificate l’uso di gestione rete virtuale di Azure per applicare una configurazione uniforme tra numerose reti virtuali.

Focus multi-cloud: pianificare uno spazio di indirizzi non sovrapposto tra Azure, AWS e Google Cloud prima di creare qualsiasi rete virtuale. Riservare intervalli CIDR che non si sovrappongano alle VPC esistenti, in modo da poter stabilire il peering o collegare i cloud tramite VPN senza NAT.

Azure servizi e funzionalità

I servizi e le funzionalità seguenti costituiscono la base di rete virtuale in Azure:

Servizio o funzionalità Elementi forniti Quando usarlo
Rete virtuale di Azure (VNet) Una rete privata isolata in Azure. Tutte le Azure rete iniziano qui. Le risorse nella stessa rete virtuale possono comunicare per impostazione predefinita; le risorse in reti virtuali diverse non possono comunicare a meno che non si connettano in modo esplicito. Sempre: ogni carico di lavoro che richiede la connettività di rete richiede una rete virtuale.
Sottorete Partizione dello spazio indirizzi della rete virtuale. Le subnet costituiscono l'ambito di associazione per i gruppi di sicurezza di rete (NSG) e le tabelle di route. Sempre: organizzare i componenti del carico di lavoro in subnet per funzione o limite di sicurezza.
Peering reti virtuali Connettività privata a bassa latenza tra due reti virtuali nella stessa area o tra aree. Il traffico rimane sul backbone Microsoft. Il peering non è transitivo; ogni peering è un collegamento diretto. Quando le risorse in reti virtuali separate devono comunicare. Per il peering tra aree geografiche, vedere Connettività tra aree geografiche.
Peering di subnet (anteprima) Peering tra subnet specifiche anziché intere reti virtuali. Fornisce un controllo granulare sulle subnet che partecipano alle relazioni di peering. Quando è necessario un controllo granulare del peering tra subnet specifiche in reti virtuali diverse. Vedere la sezione vincoli .
Tabella di routing / Rotte definite dall'utente (UDR) Eseguire l'override delle route di sistema predefinite in Azure per controllare dove viene inviato il traffico. Applicato a livello di subnet. Quando è necessario forzare il traffico attraverso un firewall o un'appliance virtuale di rete. Obbligatorio per il controllo del traffico in uscita hub-spoke. Vedi progettazione di Firewall di Azure e topologia hub-and-spoke.
gestione rete virtuale di Azure (AVNM) Creare, gestire e applicare in modo centralizzato le configurazioni di rete alle reti virtuali tra sottoscrizioni. Quando si gestiscono molte VNets distribuite in più sottoscrizioni. Vedere Gestione centralizzata della rete.

Diagramma che mostra una rete virtuale con subnet dei carichi di lavoro per i livelli Web, applicazione e dati, insieme alle subnet della piattaforma dedicate per gateway, firewall e Bastion

Come scegliere

Che cos'è una rete virtuale?

Una rete virtuale (VNet) è una rete isolata e definita dal software in Azure. Pensala come la tua rete privata in Azure. A differenza di una rete fisica che usa cavi, commutatori e router, una rete virtuale è completamente software-defined. Lo crei, gli assegni uno spazio indirizzi e vi distribuisci le risorse.

Caratteristiche chiave:

  • Con ambito a livello di area: una rete virtuale (VNet) esiste in una singola area di Azure. Tutte le risorse nella rete virtuale devono trovarsi nella stessa area. Una VNet si estende tra le zone di disponibilità all'interno di quella regione.
  • Isolamento per impostazione predefinita: le risorse in una rete virtuale non possono comunicare con le risorse in un'altra rete virtuale, a meno che non si crei in modo esplicito una connessione (peering o VPN).
  • Connettività interna predefinita: le risorse all'interno della stessa rete virtuale possono comunicare tra loro per impostazione predefinita tramite route di sistema fornite Azure.

Che cos'è una subnet?

Una subnet è un intervallo di indirizzi IP all'interno della rete virtuale. Le subnet consentono di:

  • Segmentare la rete in base al componente del carico di lavoro (ad esempio, livello Web, livello applicazione, livello dati).
  • Applicare le regole di sicurezza: I gruppi di sicurezza di rete si collegano a livello di subnet per filtrare il traffico.
  • Controllo del routing: le tabelle di routing si associano a livello di subnet per indirizzare il traffico.

Azure riserva cinque indirizzi IP in ogni subnet: i primi quattro indirizzi e l'ultimo indirizzo. Ad esempio, in una subnet /24 (256 indirizzi), solo 251 sono utilizzabili. Tieni conto di questa riserva nei calcoli di dimensionamento.

Esempio: applicazione a tre livelli

Un'applicazione Web tipica a tre livelli usa tre subnet per separare le problematiche e applicare regole di sicurezza distinte:

Sottorete Intervallo CIDR Purpose Risorse di esempio
web-subnet 10.0.1.0/24 server Web front-end che accettano il traffico HTTP/HTTPS in ingresso proveniente da Internet o dall'Application Gateway Ambiente del servizio app di Azure, set di scalabilità di macchine virtuali che eseguono NGINX
app-subnet 10.0.2.0/24 Logica dell'applicazione di livello intermedio. Accetta il traffico solo dalla subnet Web. Funzioni di Azure (integrato nella rete virtuale), macchine virtuali che eseguono la logica di business
data-subnet 10.0.3.0/24 Archivi di dati. Accetta il traffico solo dalla subnet dell'app. Nessun accesso diretto a Internet. Istanza gestita di SQL di Azure, endpoint privati per database SQL di Azure o Cosmos DB

Questa configurazione consente di applicare un NSG a ogni subnet, in modo da limitare il traffico solo a quanto necessario per quel livello. La subnet Web consente il traffico HTTPS in ingresso (porta 443). La subnet dell'app consente il traffico in ingresso solo dall'intervallo di indirizzi IP della subnet web. La subnet dei dati consente solo il traffico in ingresso dall'intervallo IP della subnet dell'applicazione.

Per un modello di modernizzazione basato su AKS, è possibile usare una subnet aks-nodes, ad esempio 10.0.4.0/24, per i pool di nodi del cluster quando si distribuisce Azure CNI Overlay. In tale modello, solo i nodi usano gli indirizzi IP della rete virtuale dalla subnet. I pod utilizzano un CIDR overlay separato, che consente di mantenere la subnet dei nodi più ridotta rispetto a una configurazione AKS con rete flat.

Modelli comuni

I layout di subnet seguenti illustrano gli scenari di distribuzione Azure più comuni:

Modello Subnetti Quando utilizzare
App Web semplice web + data Applicazioni a due livelli con un front-end e un database. Complessità minima.
Enterprise a tre livelli web + app + data + management Carichi di lavoro aziendali tradizionali con livelli distinti e una jump box o una subnet Bastion per l'amministrazione.
AKS con servizi condivisi aks-nodes + aks-ingress + appgw + shared Carichi di lavoro Kubernetes con una subnet dedicata per il controller di ingresso e Gateway applicazione per il WAF.
Traffico in uscita hub-spoke AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management Rete virtuale hub in una topologia hub-spoke. I servizi condivisi attraverso cui il traffico viene instradato dalle reti virtuali spoke. Vedere anche topologia hub-and-spoke.
Carico di lavoro dei dati compute + data + private-endpoints + management I carichi di lavoro di analisi e piattaforma dati in cui gli endpoint privati per l'archiviazione e i database necessitano della propria subnet per maggiore chiarezza nella pianificazione IP.

Quante reti virtuali e subnet?

Il principio guida è semplice: usare una rete virtuale per applicazione e una subnet per ogni componente (livello). Questa impostazione predefinita mantiene ogni carico di lavoro isolato, rende il traffico tra livelli facile da controllare con i gruppi di sicurezza di rete e lascia spazio a crescere. Modificare da questa posizione in base ai servizi condivisi, ai requisiti di isolamento e alla scalabilità.

Usare questa tabella decisionale per determinare la strategia di rete virtuale e subnet:

La tua situazione Approccio consigliato
Carico di lavoro singolo, singolo team, nessun servizio condiviso necessario Una rete virtuale con subnet per ogni componente dell'applicazione (Web, logica dell'applicazione, dati). Vedi Topologia con singolo carico di lavoro.
Più carichi di lavoro indipendenti che condividono un gateway o un firewall Rete virtuale hub per i servizi condivisi + una rete virtuale spoke per ogni carico di lavoro. Consultare la topologia hub-and-spoke.
Isolamento rigoroso tra carichi di lavoro (raggio di esplosione, requisiti di conformità) Una VNet per ogni carico di lavoro, senza peering tra di loro.
Ambiente molto grande con molte sottoscrizioni e aree geografiche rete WAN virtuale di Azure con la gestione automatizzata dell'hub. Vedere rete WAN virtuale topologia.

Riferimento per il dimensionamento delle subnet dedicate

Molti servizi della piattaforma Azure richiedono una subnet dedicata con un nome e una dimensione minima specifici. Il diagramma seguente illustra i requisiti di denominazione e le dimensioni minime per le subnet della piattaforma dedicate:

Diagramma che mostra le dimensioni minime delle subnet per cinque subnet della piattaforma dedicate, tra cui gateway, firewall, Bastion e Server di route

Usa questa tabella per pianificare lo spazio di indirizzamento:

Servizio di Azure Dimensioni minime della subnet Nome subnet obbligatorio Note
Firewall di Azure /26 (59 indirizzi IP utilizzabili) AzureFirewallSubnet Obbligatorio per tutti gli SKU del firewall. Vedere progettazione Firewall di Azure.
Gateway VPN /27 (27 indirizzi IP utilizzabili) GatewaySubnet Microsoft consiglia /27 o maggiore per avere margine di scalabilità.
Azure Bastion /26 (59 indirizzi IP utilizzabili) AzureBastionSubnet Minimo /26 per tutte le distribuzioni create dopo novembre 2021.
Gateway di applicazioni v2 /24 consigliato (251 indirizzi IP utilizzabili) Nessun nome obbligatorio Altamente consigliato /24 per supportare la scalabilità automatica. Il valore minimo è basato su una formula (istanze + 5 IP riservati + 1 IP front-end privato).
ambiente del servizio app (Ambiente di Servizio delle App) /24 (produzione), /23 (scala massima) Nessun nome obbligatorio Il ridimensionamento consuma indirizzi IP della subnet. Usa /23 se prevedi di avvicinarti al massimo di 200 istanze.
Server di route Azure /26 (59 indirizzi IP utilizzabili) RouteServerSubnet Necessario per lo scambio di instradamenti BGP con NVA.
Sistema di risoluzione privato DNS di Azure /28 minimo per ogni subnet dell'endpoint Subnet in ingresso e in uscita dedicate Richiede subnet separate per gli endpoint in ingresso e in uscita. Non è possibile condividere con altre risorse.
Servizio AKS (Azure Kubernetes) Basato su formula (dipendente da CNI) Nessun nome obbligatorio Consultare le linee guida per il dimensionamento di AKS.

Note

Gli endpoint privati usano indirizzi IP da subnet esistenti. Non richiedono una subnet dedicata. Tenere conto di questo consumo di IP nel dimensionamento della subnet. Per informazioni dettagliate sulla pianificazione degli indirizzi IP, vedere Pianificazione degli indirizzi IP.

Dimensionamento della subnet di Servizio Azure Kubernetes (AKS)

Il dimensionamento della subnet di AKS dipende dal plug-in CNI (Container Networking Interface) scelto. Nessuna dimensione minima:

  • Azure CNI Overlay: la subnet deve contenere solo i nodi perché i pod usano un blocco CIDR privato separato (Classless Inter-Domain Routing). Una subnet significativamente più piccola è accettabile rispetto alla rete flat.
  • Azure CNI (rete piatta): La subnet deve ospitare sia i nodi che i pod. Formula: (nodes + surge) × (max_pods + 1). Un /21 o superiore è comune per i cluster con 50 o più nodi.
  • Kubenet: solo i nodi consumano gli indirizzi IP della subnet della rete virtuale. I pod ottengono indirizzi IP interni al cluster.

Per le formule per il dimensionamento per ciascuna opzione CNI, vedi Pianificare l'indirizzamento IP per il cluster AKS.

Vincoli di peering della subnet

Il peering delle subnet connette subnet specifiche tra reti virtuali anziché gli interi spazi di indirizzi. Questo approccio offre un controllo granulare sulle subnet che partecipano alle relazioni di peering.

Importante

Il peering di subnet è attualmente in anteprima e presenta i vincoli seguenti:

  • Richiede l'inserimento della sottoscrizione in un elenco approvato (non la registrazione autonoma)
  • Solo CLI, modello ARM, Terraform o PowerShell (nessun supporto del portale)
  • Gli SKU V5 basati su Intel (o SKU basati su AMD Genova/Cobalt 100) sono necessari per l'uso in produzione per evitare un bug noto sugli SKU di generazione meno recenti: vedere Configurare il peering di subnet per i requisiti hardware correnti
  • Massimo 200 subnet per ciascun lato di ogni collegamento di peering
  • Massimo 1.000 subnet totali in tutti i collegamenti di peering per rete virtuale
  • Le subnet devono appartenere a spazi indirizzi univoci e non sovrapposti

Per le limitazioni e la registrazione correnti, vedere Configurare il peering di subnet.

Note

gestione rete virtuale di Azure (AVNM) non è in grado di distinguere il peering tra subnet dal peering tra VNet. Se si utilizza AVNM per gestire le configurazioni di peering, si noti che le relazioni di peering a livello di subnet vengono visualizzate in AVNM come peering VNet standard.

Considerazioni relative alla progettazione

Focus sulla progettazione lift-and-shift di reti virtuali e subnet

  • Ricrea la segmentazione on-premises: mappa ogni VLAN o zona di sicurezza su una subnet, in modo che i confini del firewall esistenti e la responsabilità operativa vengano mantenuti con modifiche minime.
  • Dimensionare le subnet con un margine di capacità. La riassegnazione degli indirizzi IP dopo la migrazione è un'operazione dirompente; pertanto, assegna intervalli CIDR più ampi di quanto richieda l'attuale numero di host, così da assorbire la crescita e i cinque indirizzi riservati da Azure per ogni subnet.
  • Mantenere gli spazi di indirizzi di Azure allineati agli intervalli della rete locale, ove possibile, per semplificare il routing ed evitare sovrapposizioni di indirizzi quando ci si connette tramite Gateway VPN o ExpressRoute.
  • Passare come impostazione predefinita a una rete virtuale per ogni applicazione migrata con una subnet per livello. Questa progettazione rispecchia i tipici layout locali a tre livelli e mantiene prevedibile lo spostamento.

Modernizzare il focus sulla progettazione di VNet e subnet

  • Progettate innanzitutto le subnet in funzione dei servizi della piattaforma: subnet dedicate per Firewall di Azure, Application Gateway e Bastion, oltre a subnet dimensionate correttamente per AKS in base al CNI scelto.
  • Usare Azure CNI Overlay per AKS per mantenere ridotte le subnet dei nodi, perché i pod attingono a un CIDR overlay separato anziché allo spazio di indirizzi della VNet.
  • Riservare una subnet dedicata per gli endpoint privati in modo che l'utilizzo ip rimanga prevedibile man mano che si adottano più servizi PaaS Azure.
  • Adotta gestione rete virtuale di Azure fin da subito per applicare in modo coerente gruppi di rete, configurazioni di connettività e di sicurezza man mano che il numero di VNet aumenta nelle varie sottoscrizioni.

Progettazione di VNet e subnet in ambienti multi-cloud

  • Stabilire un piano di indirizzi globale prima di creare una rete virtuale. Riserva blocchi CIDR non sovrapposti per Azure che non si sovrappongano alle VPC AWS esistenti o alle reti VPC di Google Cloud. Questa prenotazione è obbligatoria per la VPN instradata o l'interconnessione.
  • Associare le primitive di rete di ciascun cloud ad Azure: un VPC AWS o una rete VPC di Google Cloud corrisponde a una rete virtuale di Azure e i gruppi di sicurezza corrispondono agli NSG.
  • Riservare spazio nella subnet per i componenti di interconnessione tra cloud, come GatewaySubnet per Gateway VPN o l'hub usato da rete WAN virtuale di Azure, in modo che l'infrastruttura di transito abbia margine per espandersi.
  • Standardizzare la denominazione e l'assegnazione di tag alle subnet tra cloud, in modo che i team operativi possano correlare livelli equivalenti quando risolvono i problemi del traffico multicloud.

Prerequisiti

Prima di progettare la rete virtuale e il layout della subnet, assicurarsi di disporre di:

  • Sottoscrizione di Azure: Una sottoscrizione di Azure attiva con autorizzazioni per la creazione di risorse di rete (ruolo Collaboratore di rete o superiore).
  • Gruppo di risorse: un gruppo di risorse nell'area di destinazione per contenere risorse di rete virtuale.
  • Decisione dell'area: scegliere l'area Azure primaria in base alla prossimità agli utenti, ai requisiti di conformità e alla disponibilità del servizio.
  • Piano dello spazio di indirizzi: scegli un intervallo di indirizzi IP (blocco CIDR) che non si sovrapponga alle reti on-premises o ad altre VNet con cui prevedi di eseguire il peering. Per indicazioni, vedere Pianificazione degli indirizzi IP .

Considerazioni relative alla sicurezza

Le reti virtuali e le subnet sono il primo livello di segmentazione di rete. Applicare le procedure di sicurezza seguenti:

  • Gruppi di sicurezza di rete : associare gruppi di sicurezza di rete a ogni subnet per filtrare il traffico in ingresso e in uscita. Definire le regole di autorizzazione specifiche per il ruolo di ogni subnet e negare tutto il resto per impostazione predefinita. Per indicazioni dettagliate, vedere Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni.
  • Tunneling forzato con route definite dall'utente (UDR): se i requisiti di conformità impongono che tutto il traffico destinato a Internet passi attraverso un dispositivo di ispezione in locale o un firewall cloud, usare tabelle di route con route definite dall'utente per sostituire il routing Internet predefinito. Vedere Connettività in uscita.
  • Isolamento subnet: posizionare le risorse con livelli di attendibilità diversi in subnet separate. Ad esempio, mantenere i database in una subnet che consente solo il traffico in ingresso dalla subnet del livello applicazione. Questa separazione limita lo spostamento laterale se un utente malintenzionato compromette un componente.
  • Subnet dedicate per i servizi della piattaforma: molti servizi della piattaforma Azure (Firewall di Azure, gateway applicazione, Bastion) vengono distribuiti in subnet dedicate. Questo isolamento garantisce che il routing del servizio della piattaforma e le regole di sicurezza non interferiscano con le subnet del carico di lavoro.

Interazione tra NSG e subnet

Quando si associa un gruppo di sicurezza di rete a una subnet, le regole del gruppo di sicurezza di rete si applicano a tutte le risorse in tale subnet. Comprendere questi comportamenti di interazione:

  • Valutazione cumulativa: se la scheda di interfaccia di rete di una macchina virtuale ha anche un gruppo di sicurezza di rete, Azure valuta sia il gruppo di sicurezza di rete a livello di subnet che il gruppo di sicurezza di rete a livello di scheda di interfaccia di rete. Per il traffico in ingresso, Azure esamina prima l'NSG della subnet, quindi l'NSG della NIC. Per il traffico in uscita, Azure valuta prima il gruppo di sicurezza di rete della scheda di interfaccia di rete, quindi il gruppo di sicurezza di rete della subnet.
  • Nega predefinita: Azure include regole predefinite che consentono il traffico tra reti virtuali e l'accesso a Internet in uscita. Dopo aver aggiunto regole di negazione personalizzate, verificare che il traffico legittimo (ad esempio Azure Load Balancer probe di integrità dall'indirizzo IP 168.63.129.16) non venga bloccato inavvertitamente.
  • Tag del servizio e asg: usare i tag del servizio (ad esempio AzureLoadBalancer, Internet, VirtualNetwork) e i gruppi di sicurezza delle applicazioni nelle regole del gruppo di sicurezza di rete invece degli indirizzi IP non elaborati. Questo approccio semplifica la gestione delle regole e si adatta automaticamente quando cambiano gli intervalli IP Azure.
  • Log di flusso per la visibilità: abilitare i log di flusso degli NSG su ogni NSG a livello di subnet per registrare il traffico consentito e negato. I log dei flussi consentono di verificare che le regole di sicurezza funzionino come previsto e forniscano prove per i controlli di conformità. Vedere log dei flussi NSG per le istruzioni di configurazione.

Questi articoli nella guida alla progettazione della rete Azure trattano gli argomenti correlati:

Ulteriori informazioni

Per altre informazioni sulla rete virtuale Azure, vedere le risorse seguenti:

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Pianificare lo spazio degli indirizzi IP: allocare un pool CIDR /16 che evita la sovrapposizione con gli intervalli di indirizzi locali.

Nel prossimo percorso di modernizzazione:

Pianifica lo spazio degli indirizzi IP: alloca pool di indirizzi IP di due regioni con intervalli non sovrapposti per il peering attivo-attivo.

Il prossimo passo nel tuo percorso multicloud:

Pianificare lo spazio degli indirizzi IP: progettare indirizzi non sovrapposti tra Azure, Amazon Web Services (AWS) e Google Cloud.

  • Last updated on