Indirizzi IP riservati nelle subnet Azure
Per ogni subnet, Azure riserva 5 indirizzi IP: i primi quattro indirizzi e l’ultimo indirizzo dell’intervallo. Questi indirizzi non possono essere assegnati alle risorse.
Prendiamo come esempio la subnet:
192.168.1.0/24
che contiene 256 indirizzi, da 192.168.1.0 a 192.168.1.255.
| IP | Utilizzo |
|---|---|
192.168.1.0 | Indirizzo di rete (Network Address) |
192.168.1.1 | Riservato da Azure per il default gateway |
192.168.1.2 | Riservato da Azure per il mapping del servizio Azure DNS |
192.168.1.3 | Riservato da Azure per il mapping del servizio Azure DNS |
192.168.1.255 | Indirizzo riservato come broadcast address |
Microsoft conferma esplicitamente anche questo preciso esempio 192.168.1.0/24.
Quindi gli indirizzi effettivamente assegnabili alle risorse sono:
192.168.1.4 → 192.168.1.254
cioè 251 IP utilizzabili su 256.
Nota: è meglio dire che
.255è riservato da Azure come broadcast address, non che Azure utilizzi normalmente il broadcast IP come avverrebbe in una LAN Ethernet tradizionale.
Routing tra subnet
Per impostazione predefinita, Azure instrada automaticamente il traffico tra tutte le subnet appartenenti alla stessa Virtual Network (VNet).
Ad esempio:
VNet 192.168.0.0/16Subnet-A192.168.1.0/24 │ │ Azure System Route ▼Subnet-B192.168.2.0/24
Non è quindi necessario creare manualmente una route per consentire a una VM 192.168.1.x di raggiungere una VM 192.168.2.x.
Azure crea automaticamente delle System Routes e, per lo spazio di indirizzamento della VNet, utilizza come next hop Virtual network. Microsoft specifica infatti che, per impostazione predefinita, Azure instrada il traffico tra subnet senza necessità di route table o gateway aggiuntivi.
È però possibile modificare questo comportamento utilizzando delle User Defined Routes (UDR).
Per esempio, possiamo obbligare il traffico tra due subnet a passare attraverso una Network Virtual Appliance (NVA), come un firewall:
Subnet-A192.168.1.0/24 │ │ UDR ▼┌───────────────┐│ Firewall/NVA ││ 192.168.10.4 │└───────┬───────┘ │ ▼Subnet-B192.168.2.0/24
In questo caso si associa una Route Table alla subnet e si crea una UDR, ad esempio:
Destination: 192.168.2.0/24Next hop: Virtual applianceNext hop IP: 192.168.10.4
Microsoft conferma espressamente che le route personalizzate possono essere utilizzate proprio per instradare il traffico tra subnet attraverso una NVA.
Quindi anche l’ultima frase dell’articolo è corretta: se vuoi forzare il traffico tra due risorse della stessa VNet attraverso una NVA/firewall, normalmente le risorse devono trovarsi in subnet differenti, in modo da poter controllare il percorso tramite le route associate alle subnet.