Reti virtuali e subnet

Una rete virtuale di Azure (VNet) è una rete logicamente isolata nel cloud di Azure che è possibile definire e controllare. È l'elemento fondamentale delle reti di Azure e consente alle risorse di Azure, come macchine virtuali, database e servizi app, di comunicare in modo sicuro tra loro, con Internet e con le reti locali. Una VNet è associata a una singola area di Azure e a uno spazio di indirizzi CIDR IPv4 specifico (ed eventualmente IPv6), definito durante la creazione.

Quando si crea una VNet, si assegna uno spazio di indirizzi usando la notazione CIDR. La notazione CIDR (Classless Inter-Domain Routing) specifica sia l'indirizzo di rete sia il numero di bit utilizzati per il prefisso di rete. Ad esempio, 10.0.0.0/16 fornisce 65.536 indirizzi IP (da 10.0.0.0 a 10.0.255.255). Lo spazio di indirizzi deve appartenere a un intervallo di indirizzi IP privati (10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16 secondo RFC 1918). Scelga uno spazio di indirizzi abbastanza ampio da contenere tutte le subnet previste e consentire l'espansione futura, evitando però sovrapposizioni con le reti locali se si prevede una connessione ibrida.

Una subnet divide lo spazio di indirizzi della VNet in segmenti di rete più piccoli. Ogni subnet ha un proprio intervallo IP (un sottoinsieme dello spazio di indirizzi della VNet) e può contenere risorse di tipi diversi. Le subnet hanno due scopi: organizzazione (raggruppare risorse correlate) e isolamento (applicare regole di sicurezza diverse a gruppi di risorse differenti). Ad esempio, si possono avere una subnet web-tier (10.0.1.0/24) per i server Web, una subnet app-tier (10.0.2.0/24) per i server applicativi e una subnet data-tier (10.0.3.0/24) per i database.

All'interno di ogni subnet, Azure riserva i primi quattro indirizzi IP e l'ultimo indirizzo IP per il proprio utilizzo. Per una subnet 10.0.1.0/24: 10.0.1.0 (indirizzo di rete), 10.0.1.1 (gateway predefinito), 10.0.1.2 e 10.0.1.3 (riservati per Azure DNS) e 10.0.1.255 (indirizzo broadcast). In una subnet /24 restano quindi 251 IP utilizzabili. Tenga conto di questa riserva nel dimensionamento delle subnet: una subnet /28 dispone di soli 11 indirizzi utilizzabili (16 meno 5 riservati).

Per impostazione predefinita, le risorse all'interno della stessa VNet possono comunicare tra loro usando i rispettivi indirizzi IP privati, anche se si trovano in subnet diverse. Per la comunicazione interna alla VNet non è necessaria alcuna configurazione aggiuntiva. Le risorse in VNet diverse non possono comunicare per impostazione predefinita: è necessario connetterle esplicitamente usando il peering VNet. Le risorse nella stessa subnet condividono lo stesso segmento di rete, quindi la comunicazione tra loro segue il percorso più diretto possibile all'interno del livello di rete software-defined di Azure.

Per impostazione predefinita, le VM in una VNet possono avviare connessioni in uscita verso Internet: Azure fornisce automaticamente l'accesso a Internet in uscita tramite un servizio NAT gestito. Per l'accesso in entrata da Internet, una risorsa deve avere un indirizzo IP pubblico assegnato alla propria interfaccia di rete o al bilanciatore del carico. È quindi possibile controllare l'accesso in entrata usando le regole del gruppo di sicurezza di rete (NSG), specificando esattamente quali porte e protocolli sono consentiti. Un'architettura comune colloca i server Web in una subnet pubblica con IP pubblici e i server applicativi in una subnet privata accessibile solo dal livello Web.

Per impostazione predefinita, Azure gestisce automaticamente il routing: il traffico tra subnet rimane all'interno della VNet, il traffico Internet in uscita viene sottoposto a NAT e il traffico verso i servizi di Azure usa il backbone di Azure. È possibile sostituire questo comportamento con le route definite dall'utente (UDR) in una tabella di route. Un uso comune consiste nel forzare tutto il traffico Internet in uscita a passare attraverso un appliance di rete virtuale (NVA) o Azure Firewall in una VNet hub, per un'ispezione centralizzata. Per applicare questa configurazione, si crea una tabella di route, si aggiungono le voci di routing e si associa la tabella a una o più subnet.

Alcuni servizi Azure — come Azure App Service (VNet Integration), Azure Kubernetes Service, Azure SQL Managed Instance e Azure Databricks — richiedono una subnet dedicata delegata a tale servizio. Una subnet delegata consente ad Azure di inserire per Suo conto risorse specifiche del servizio (interfacce di rete, indirizzi IP interni) nella subnet. Non è possibile distribuire altri tipi di risorse in una subnet delegata: è riservata esclusivamente a quel servizio Azure. Quando prevede di usare servizi che richiedono la delega, allochi sempre una subnet dedicata con uno spazio IP sufficiente.

Procedure consigliate fondamentali per la progettazione delle VNet: pianifichi lo spazio degli indirizzi prima di creare la VNet: non potrà modificarlo senza ricreare le risorse. Utilizzi subnet separate per ogni livello dell'applicazione, così da applicare criteri di sicurezza distinti. Eviti la sovrapposizione degli spazi degli indirizzi con le reti locali se prevede di connettersi tramite VPN o ExpressRoute. Riservi subnet più ampie ai servizi che richiedono scalabilità (ad esempio, i pool di nodi AKS). Assegni nomi chiari alle risorse (ad esempio, vnet-prod-eastus-001) per facilitare la gestione su larga scala. Una VNet progettata correttamente è molto più facile da proteggere e risolvere rispetto a una creata in modo improvvisato.

Le VNet di Azure possono essere connesse alle reti locali tramite due meccanismi: VPN Gateway — un tunnel IPsec/IKE crittografato sulla rete Internet pubblica, conveniente per esigenze di larghezza di banda moderate. Azure ExpressRoute — una connessione privata e dedicata in fibra tramite un partner provider di rete, che offre larghezza di banda maggiore, latenza inferiore e prestazioni più prevedibili rispetto alla VPN. Per carichi di lavoro sensibili o scenari che richiedono una larghezza di banda garantita, ExpressRoute è l'opzione preferibile, anche se comporta costi significativamente più elevati e tempi di provisioning più lunghi.

Il dimensionamento dello spazio degli indirizzi di una VNet richiede una pianificazione delle esigenze attuali e future. Un modello aziendale comune è il seguente: spazio degli indirizzi della VNet: /16 (65.536 indirizzi). Subnet: /24 per ogni livello del carico di lavoro (251 indirizzi utilizzabili ciascuna). Una VNet /16 può contenere 256 subnet /24, più che sufficienti per la maggior parte degli ambienti. Per ambienti molto grandi, utilizzi un intervallo /8 o richieda più intervalli non sovrapposti. Lasci sempre spazio per la crescita: allocare oggi una /24 quando l'anno prossimo potrebbe servire una /22 comporta in seguito un complesso lavoro di riassegnazione degli indirizzi.

In questa lezione ha appreso che: una VNet di Azure è una rete logicamente isolata con uno spazio degli indirizzi CIDR definito, associata a una singola area, le subnet dividono la VNet in segmenti per l'organizzazione e l'isolamento dei criteri di sicurezza e Azure riserva 5 indirizzi IP per subnet; le risorse all'interno della stessa VNet comunicano privatamente per impostazione predefinita, senza configurazioni aggiuntive. Nella prossima lezione esamineremo i Network Security Group e gli Application Security Group per il filtraggio del traffico.