Esplorare le reti virtuali di Azure

Completato

Le reti virtuali di Azure rappresentano il componente di base fondamentale della rete privata in Azure. Consentono infatti di creare reti virtuali complesse simili a una rete locale, con in più i vantaggi dell'infrastruttura di Azure, ad esempio scalabilità, disponibilità e isolamento.

Ogni rete virtuale creata ha il proprio blocco CIDR e può essere collegata ad altre reti virtuali e reti locali purché i blocchi CIDR non si sovrappongano. È anche possibile controllare le impostazioni del server DNS per le reti virtuali e la segmentazione della rete virtuale in subnet.

Funzionalità delle reti virtuali di Azure

Le reti virtuali di Azure consentono alle risorse di Azure di comunicare in modo sicuro tra loro, con Internet e con le reti locali.

  • Comunicazione con Internet. Per impostazione predefinita, tutte le risorse in una rete virtuale possono comunicare verso l'esterno su Internet. Per la comunicazione in ingresso con una risorsa, è possibile assegnarle un indirizzo IP pubblico o un servizio di bilanciamento del carico pubblico. Si può usare un indirizzo IP pubblico o un servizio di bilanciamento del carico pubblico anche per gestire le connessioni in uscita.
  • Comunicazione tra risorse di Azure. Esistono tre meccanismi chiave tramite i quali la risorsa di Azure può comunicare: reti virtuali, endpoint di servizio della rete virtuale e peering di reti virtuali. Le reti virtuali possono connettere non solo le macchine virtuali, ma anche altre risorse di Azure, come l'ambiente del servizio app, il servizio Azure Kubernetes e i set di scalabilità di macchine virtuali di Azure. È possibile usare endpoint di servizio per la connessione ad altri tipi di risorse di Azure, come account di archiviazione e database SQL di Azure. Quando si crea una rete virtuale, i servizi e le macchine virtuali all'interno della rete virtuale possono comunicare direttamente e in modo sicuro tra loro nel cloud.
  • Comunicazione tra risorse locali. Estendere in modo sicuro il data center. È possibile connettere i computer e le reti locali a una rete virtuale usando una delle opzioni seguenti: rete privata virtuale (VPN) da punto a sito, VPN da sito a sito, Azure ExpressRoute.
  • Applicazione di filtri al traffico di rete. È possibile filtrare il traffico di rete tra le subnet usando qualsiasi combinazione di gruppi di sicurezza di rete e appliance virtuali di rete, ad esempio firewall, gateway, proxy e servizi NAT (Network Address Translation).
  • Routing del traffico di rete. Azure instrada il traffico tra subnet, reti virtuali connesse, reti locali e Internet, per impostazione predefinita. È possibile implementare tabelle di route o route BGP (Border Gateway Protocol) per eseguire l'override delle route predefinite create da Azure.

Considerazioni sulla progettazione per le reti virtuali di Azure

Spazio indirizzi e subnet

È possibile creare più reti virtuali per ogni area e per ogni sottoscrizione. È possibile creare più subnet all'interno di ogni rete virtuale.

Reti virtuali

Quando si crea una rete virtuale, è consigliabile usare gli intervalli di indirizzi enumerati in RFC 1918, che sono stati riservati da IETF per gli spazi indirizzi privati non instradabili:

  • 10.0.0.0 - 10.255.255.255 (prefisso 10/8)
  • 172.16.0.0 - 172.31.255.255 (prefisso 172.16/12)
  • 192.168.0.0 - 192.168.255.255 (prefisso 192.168/16)

Inoltre, non è possibile aggiungere gli intervalli di indirizzi seguenti:

  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (broadcast)
  • 127.0.0.0/8 (loopback)
  • 169.254.0.0/16 (locale rispetto al collegamento)
  • 168.63.129.16/32 (DNS interno)

Azure assegna alle risorse di una rete virtuale un indirizzo IP privato dello spazio indirizzi di cui si effettua il provisioning. Se ad esempio si distribuisce una macchina virtuale in una rete virtuale con spazio indirizzi 192.168.1.0/24, alla macchina virtuale verrà assegnato un indirizzo IP privato come 192.168.1.4. Azure riserva i primi quattro e l'ultimo indirizzo IP, per un totale di 5 indirizzi IP, all'interno di ogni subnet. Si tratta di x.x.x.0 - x.x.x.3 e dell'ultimo indirizzo della subnet.

L'intervallo di indirizzi IP 192.168.1.0/24, ad esempio, contiene gli indirizzi riservati seguenti:

  • 192.168.1.0: indirizzo di rete
  • 192.168.1.1: riservato da Azure per il gateway predefinito
  • 192.168.1.2, 192.168.1.3: riservato da Azure per il mapping degli IP DNS di Azure allo spazio della rete virtuale
  • 192.168.1.255: indirizzo di broadcast di rete.

Quando si pianifica l'implementazione di reti virtuali, è necessario considerare quanto segue:

  • Verificare che gli spazi indirizzi non si sovrappongano. Assicurarsi che lo spazio indirizzi della rete virtuale (blocco CIDR) non si sovrapponga con altri intervalli di rete dell'organizzazione.
  • È necessario un isolamento della sicurezza?
  • È necessario attenuare eventuali limitazioni dell'indirizzamento IP?
  • Saranno presenti connessioni tra reti virtuali di Azure e reti locali?
  • È necessario un isolamento per scopi amministrativi?
  • Si usano servizi di Azure che creano reti virtuali proprie?

Subnet

Una subnet è un intervallo di indirizzi IP nella rete virtuale. È possibile segmentare le reti virtuali in subnet di dimensioni diverse, creando tutte le subnet necessarie per l'organizzazione e la sicurezza entro il limite della sottoscrizione. È quindi possibile distribuire le risorse di Azure in una subnet specifica. Proprio come le reti tradizionali, le subnet consentono di segmentare lo spazio indirizzi della rete virtuale in segmenti appropriati per la rete interna dell'organizzazione. In questo modo, anche l'allocazione degli indirizzi risulta più efficiente. La subnet IPv4 più piccola supportata è /29 e la più grande è /2 (in base alle definizioni di subnet CIDR). Le subnet IPv6 devono avere esattamente una dimensione di /64. Quando si pianifica l'implementazione di subnet, è necessario considerare quanto segue:

  • Ogni subnet deve avere un intervallo di indirizzi univoco, specificato in formato CIDR (Classless Inter-Domain Routing).
  • Per alcuni servizi di Azure è necessaria una subnet specifica.
  • Le subnet possono essere usate per la gestione del traffico. È ad esempio possibile creare subnet per instradare il traffico attraverso un'appliance virtuale di rete.
  • È possibile limitare l'accesso alle risorse di Azure a subnet specifiche con un endpoint servizio di rete virtuale. È possibile creare più subnet e abilitare un endpoint di servizio per alcune subnet, ma non per altre.

Determinare una convenzione di denominazione

Durante la progettazione della rete di Azure, è importante pianificare la convenzione di denominazione per le risorse. Con una convenzione di denominazione efficace, i nomi delle risorse vengono creati usando informazioni importanti su ogni risorsa. Un nome scelto accuratamente consente di identificare rapidamente il tipo della risorsa, il carico di lavoro associato, l'ambiente di distribuzione e l'area di Azure che la ospita. Ad esempio, il nome di una risorsa IP pubblico per un carico di produzione di SharePoint che si trova nell'area Stati Uniti occidentali potrebbe essere pip-sharepoint-prod-westus-001

Azure resource naming example.

Tutti i tipi di risorse di Azure hanno un ambito che definisce il livello in cui i nomi delle risorse devono essere univoci. Una risorsa deve avere un nome univoco nel proprio ambito. Sono quattro i livelli in cui è possibile specificare un ambito: gruppo di gestione, sottoscrizione, gruppo di risorse e risorsa. Gli ambiti sono gerarchici e a ogni livello della gerarchia l'ambito diventa più specifico.

Ad esempio, una rete virtuale ha un ambito di gruppo di risorse, il che significa che può essere presente una sola rete denominata vnet-prod-westus-001 in ogni gruppo di risorse. Altri gruppi di risorse potrebbero avere una propria rete virtuale denominata vnet-prod-westus-001. L'ambito delle subnet è quello delle reti virtuali, quindi ogni subnet all'interno di una rete virtuale deve avere un nome distinto.

Informazioni sulle aree e sulle sottoscrizioni

Tutte le risorse di Azure vengono create in un'area e in una sottoscrizione di Azure. Una risorsa può essere creata solo in una rete virtuale presente nella stessa area e nella stessa sottoscrizione della risorsa. È tuttavia possibile connettere reti virtuali esistenti in sottoscrizioni e aree diverse. Durante la progettazione della rete di Azure è importante considerare le aree di Azure in relazione all'infrastruttura, ai dati, alle applicazioni e agli utenti finali.

È possibile distribuire tutte le reti virtuali necessarie all'interno di ogni sottoscrizione, fino al limite della sottoscrizione. Alcune organizzazioni più grandi con distribuzioni globali hanno più reti virtuali connesse tra aree, come nell'esempio seguente.

Screen capture of a World map showing Azure global network.

Zone di disponibilità di Azure

Una zona di disponibilità di Azure consente di definire posizioni fisiche univoche all'interno di un'area. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. Progettata per garantire la disponibilità elevata dei servizi di Azure, la separazione fisica delle zone di disponibilità all'interno di un'area protegge le applicazioni e i dati dagli errori dei data center.

Azure region showing three availability zones.

È consigliabile prendere in considerazione le zone di disponibilità quando si progetta la rete di Azure e pianificare i servizi che supportano le zone di disponibilità.

I servizi di Azure che supportano le zone di disponibilità rientrano in tre categorie:

  • Servizi a livello di zona: le risorse possono essere aggiunte a una zona specifica. Ad esempio, le macchine virtuali, i dischi gestiti o gli indirizzi IP standard possono essere aggiunti a una zona specifica, il che assicura una maggiore resilienza grazie alla presenza di una o più istanze delle risorse distribuite tra le zone.
  • Servizi con ridondanza della zona: le risorse vengono replicate o distribuite automaticamente tra le zone. Azure replica i dati in tre zone in modo che un errore di una zona non influisca sulla disponibilità.
  • Servizi non a livello di area: i servizi sono sempre disponibili nelle aree geografiche di Azure e sono resilienti alle interruzioni a livello di zona, oltre che alle interruzioni a livello di area.