Pianificare l’address space della VNet

Una virtual network in Azure è definita da uno o più blocchi CIDR, il suo address space. La best practice attesa dall’esame è usare i range privati RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16); Azure supporta nelle VNet anche lo shared address space RFC 6598 (100.64.0.0/10), utile quando i range privati “classici” sono già saturi.

Il criterio guida è uno solo: scegliere fin da subito range non sovrapposti, coordinati fra tutte le VNet, le reti on-premises e i peering futuri. Meglio sovradimensionare l’address space e lasciare margine di crescita: puoi aggiungere blocchi a una VNet in un secondo momento, ma modificare un range già usato da peering o connessioni gateway è invasivo. Evita di consumare internamente indirizzi pubblici instradabili: creano ambiguità di routing verso Internet.

Dimensionare le subnet

Ogni subnet perde 5 indirizzi riservati da Azure: il primo (network), i due successivi (mapping interno e Azure DNS), il gateway di default (.1) e l’ultimo (broadcast). Quindi una /29 offre solo 3 IP utilizzabili ed è la subnet più piccola supportata. Il trade-off è netto: subnet troppo grandi sprecano spazio dell’address space, subnet troppo piccole bloccano lo scaling di VM e servizi.

Alcune subnet di servizio hanno nome e dimensione obbligati e su questi l’esame insiste:

  • GatewaySubnet (VPN gateway / ExpressRoute): il nome deve essere esattamente questo, dimensione consigliata /27 per lasciare spazio a più gateway e feature.
  • AzureBastionSubnet: minimo /26.
  • AzureFirewallSubnet: /26.

Ricorda che NSG e route table si associano a livello di subnet, e che le subnet delegate a servizi PaaS non possono ospitare risorse arbitrarie.

IP services: public IP e public IP prefix

I public IP hanno due SKU. Il Basic è ormai ritirato: l’esame lo cita come contrapposizione allo Standard, che è static-only, secure-by-default (il traffico è bloccato finché un NSG non lo consente esplicitamente), può essere zone-redundant o zonal ed è richiesto da servizi moderni come Standard Load Balancer e NAT Gateway. Sul metodo di allocazione: scegli static quando l’indirizzo deve restare stabile per record DNS, failover o allowlisting; il dynamic può cambiare a ogni deallocazione.

Un public IP prefix è un blocco contiguo di public IP Standard static riservato in una singola region, con dimensioni da /28 (16 indirizzi) a /31 (2 indirizzi). Il vantaggio decisivo: conosci l’intero range prima di assegnare i singoli indirizzi, quindi un partner esterno o un firewall a valle può inserire in allowlist un unico prefisso invece di IP sparsi. È la scelta corretta anche per garantire indirizzi in uscita contigui su NAT Gateway o Azure Firewall.

Address space sovrapposti e VNet peering

Il punto più insidioso: il VNet peering richiede address space non sovrapposti. Se due VNet condividono anche solo una porzione di CIDR, il routing non può disambiguare la destinazione e il peering semplicemente non si stabilisce. Il peering inoltre non è transitivo: A-B e B-C non danno connettività A-C.

Quando la sovrapposizione è inevitabile (tipicamente dopo fusioni o acquisizioni), non esiste un peering che la aggiri: serve NAT. Il VPN Gateway supporta NAT rules per tradurre i range in conflitto e ristabilire la connettività. Resta comunque preferibile prevenire il problema in fase di design dell’address space.

Trappole tipiche d’esame

  • Due VNet con address space sovrapposti da collegare → il peering fallisce: non è un problema di NSG o di gateway; il peering esige range disgiunti. Ridisegna gli address space oppure usa VPN Gateway con NAT rules.
  • Serve la subnet più piccola possibile → /29, non /30: Azure riserva 5 indirizzi per subnet, quindi /29 dà 3 IP usabili mentre /30 non ne lascia nessuno.
  • Il VPN gateway non si crea o la subnet è troppo piccola → GatewaySubnet almeno /27: il nome deve essere esattamente GatewaySubnet e va dimensionata con margine.
  • Un partner deve inserire in allowlist i tuoi IP in uscita → public IP prefix: un blocco contiguo noto in anticipo, non IP singoli sparsi difficili da autorizzare.
  • Public IP che deve nascere “chiuso di default” → Standard SKU: lo Standard è secure-by-default e richiede un NSG per consentire il traffico; il Basic (ritirato) era aperto.
  • Indirizzo pubblico stabile per DNS o failover → static assignment su Standard: il dynamic cambia alla deallocazione, lo static resta fisso.