Address space e piano di indirizzamento

Ogni Azure Virtual Network (VNet) si definisce con uno o più address space in notazione CIDR (es. 10.0.0.0/16). Lo spazio va scelto con criterio: deve essere privato (RFC 1918: 10/8, 172.16/12, 192.168/16) e soprattutto non deve sovrapporsi con altre reti con cui in futuro dovrai comunicare — altre VNet da mettere in peering, la rete on-premises collegata via VPN/ExpressRoute, o gli address space di altri tenant.

Regola pratica da associate: dimensiona in eccesso l’address space complessivo (un /16 per hub e spoke) ma segmenta in subnet ragionevoli. Una subnet in Azure “consuma” 5 indirizzi riservati per ogni prefisso: il primo (network), l’ultimo (broadcast) e tre riservati da Azure per il default gateway e il DNS mapping. Quindi un /29 offre solo 3 host utilizzabili, non 8.

Segmentazione in subnet

Le subnet isolano workload e permettono di applicare Network Security Group (NSG), route table (UDR) e delegazioni. Alcune subnet hanno nome e ruolo obbligati:

  • GatewaySubnet — richiesta per il Virtual Network Gateway (VPN o ExpressRoute). Il nome deve essere esattamente questo; consigliato almeno un /27 per supportare tutte le SKU. Non applicarvi NSG restrittivi.
  • AzureFirewallSubnet — richiesta per Azure Firewall, minimo /26, nome fisso.
  • AzureBastionSubnet — per Azure Bastion, minimo /26.

Service endpoint e private endpoint

I service endpoint estendono l’identità della subnet verso servizi PaaS (Storage, SQL, Key Vault) sulla backbone Microsoft, così puoi limitare l’accesso al servizio “solo da questa subnet/VNet” tramite le firewall del servizio. Restano però su IP pubblico del servizio. Il private endpoint invece porta il servizio PaaS dentro la VNet con un IP privato: è la scelta preferita quando serve isolamento completo o accesso da on-premises.

VNet peering

Il VNet peering connette due VNet facendo transitare il traffico sulla backbone Microsoft (niente Internet, niente gateway), con latenza bassa e banda piena. Due varianti:

  • peering regionale (stessa region);
  • Global VNet peering (region diverse, anche cross-tenant/cross-subscription).

Opzioni chiave da configurare in modo simmetrico su entrambi i lati: Allow forwarded traffic, Allow gateway transit (lato hub) e Use remote gateways (lato spoke), che consentono agli spoke di usare il gateway VPN/ExpressRoute centralizzato nell’hub.

Due proprietà critiche:

  1. Gli address space non devono sovrapporsi: il peering fallisce se i CIDR si intersecano.
  2. Il peering non è transitivo. Se A è in peering con B e B con C, A non parla con C automaticamente.

Topologia hub-spoke

La topologia hub-spoke risolve la non-transitività e centralizza i servizi condivisi. L’hub ospita gli elementi comuni — Azure Firewall, VPN/ExpressRoute Gateway, Bastion, DNS — mentre gli spoke contengono i workload isolati e sono in peering solo con l’hub.

Poiché il peering non è transitivo, per far comunicare spoke-to-spoke o spoke↔on-premises devi forzare il traffico attraverso l’hub con una User Defined Route che punta come next hop all’IP privato dell’Azure Firewall (o di un NVA). L’hub esegue routing e ispezione; gli spoke usano gateway transit per raggiungere l’on-premises senza ciascuno un proprio gateway. Questo modello riduce costi (un solo gateway/firewall), centralizza la security policy e scala aggiungendo spoke.

Trappole tipiche d’esame

  • Peering che fallisce alla creazione → quasi sempre address space sovrapposti. La risposta corretta è ridisegnare il CIDR di una delle VNet, non modificare NSG o route.
  • Due spoke non comunicano pur avendo entrambi il peering con l’hub → il peering non è transitivo: serve una UDR con next hop l’Azure Firewall/NVA nell’hub (oppure abilitare gateway transit se il percorso è verso on-premises), non un peering diretto se lo scenario chiede routing centralizzato.
  • Gli spoke devono raggiungere l’on-premises tramite il gateway dell’hub → abilitare Allow gateway transit sul peering lato hub e Use remote gateways lato spoke; un solo gateway condiviso.
  • Serve limitare l’accesso a uno Storage Account “solo dalla mia subnet” → service endpoint + regola sulla firewall del servizio; se invece serve un IP privato dentro la VNet o accesso da on-prem, scegli il private endpoint.
  • Deploy del VPN Gateway che non parte → la subnet dedicata deve chiamarsi esattamente GatewaySubnet ed essere sufficientemente ampia (≥ /27); un nome diverso o un /29 fanno fallire lo scenario.