Guida rapida a CIDR, subnet mask e IP utilizzabili

CIDR, subnet mask e IP utilizzabili: la parte che serve davvero in un server

Quando devi assegnare indirizzi a server, firewall, VLAN o pool DHCP, la domanda non è “cos’è una subnet” in astratto: è capire subito quanti IP hai, quali sono riservati e quale prefisso conviene usare. CIDR, subnet mask e IP utilizzabili sono tre modi diversi di descrivere la stessa struttura. Se li leggi bene, eviti errori banali come mettere un host nella rete sbagliata o scegliere una /30 quando ti servono più indirizzi di quanti pensi.

Il punto chiave è questo: una rete IPv4 divide gli indirizzi in una parte di rete e una parte host. Il prefisso CIDR, come /24 o /27, dice quanti bit sono dedicati alla rete. La subnet mask traduce lo stesso concetto in formato decimale puntato, per esempio 255.255.255.0. Gli IP utilizzabili sono gli indirizzi assegnabili agli host, esclusi in genere indirizzo di rete e broadcast.

CIDR e subnet mask: stessa informazione, due forme diverse

CIDR significa Classless Inter-Domain Routing. In pratica, invece di ragionare con le vecchie classi A, B e C, si usa un prefisso che indica la lunghezza della parte di rete. Una notazione come 192.168.10.0/24 dice che i primi 24 bit identificano la rete e gli ultimi 8 identificano gli host.

La subnet mask è la versione “esplicita” dello stesso dato. Per /24 la mask è 255.255.255.0. Per /26 diventa 255.255.255.192. Per /20 è 255.255.240.0. Se sai leggere una delle due forme, puoi ricavare l’altra senza strumenti esterni.

Il trucco operativo è semplice: ogni ottetto della mask vale 8 bit. Un ottetto pieno di bit a 1 vale 255. Se la maschera non finisce su un confine da 8 bit, l’ottetto “parziale” si calcola con le potenze di due. Per esempio, 11111100 in binario vale 252, quindi /22 corrisponde a 255.255.252.0.

Come si calcolano rete, broadcast e IP utilizzabili

Ogni subnet IPv4 ha tre elementi da tenere distinti: indirizzo di rete, broadcast e host utilizzabili. L’indirizzo di rete identifica il blocco e non si assegna a un dispositivo. Il broadcast è l’ultimo indirizzo del blocco e, in IPv4, serve per la diffusione a tutti gli host della subnet. Gli IP utilizzabili sono quelli compresi in mezzo.

La formula più pratica è questa: se il prefisso è /n, gli host bit sono 32 - n. Gli indirizzi totali sono 2^(32-n). Gli utilizzabili, nella maggior parte dei casi, sono 2^(32-n) - 2, perché si sottraggono rete e broadcast.

Esempio rapido con /24: hai 8 bit host, quindi 2^8 = 256 indirizzi totali. Gli utilizzabili sono 254. Se la rete è 192.168.1.0/24, la rete è 192.168.1.0, il broadcast è 192.168.1.255 e gli host vanno da 192.168.1.1 a 192.168.1.254.

Con una /26 la musica cambia: gli host bit sono 6, quindi 64 indirizzi totali e 62 utilizzabili. Se la rete è 10.0.4.128/26, il range va da 10.0.4.128 a 10.0.4.191, con host utilizzabili da 10.0.4.129 a 10.0.4.190.

Per non sbagliare, conviene ragionare sempre in termini di blocco. Il prefisso determina la dimensione del blocco e il blocco si ripete a intervalli fissi. In una /26, gli intervalli sono di 64: .0, .64, .128, .192. Se vedi un host come 10.0.4.142, sai subito che cade nel blocco 10.0.4.128/26.

Metodo mentale veloce per capire la subnet senza fare conti lunghi

In campo operativo serve velocità, non algebra. Il metodo più utile è fissare prima la dimensione del blocco. Quando il prefisso supera /24, la subnet si restringe nell’ultimo ottetto. Quando scende sotto /24, si estende negli ottetti precedenti. Questo ti evita di confondere l’indirizzo del server con quello della rete.

Prendi 172.16.20.0/23. Qui la mask è 255.255.254.0. Il blocco copre due /24 contigui, quindi il range è da 172.16.20.0 a 172.16.21.255. Gli host utilizzabili vanno da 172.16.20.1 a 172.16.21.254. Se assegni 172.16.22.10, sei fuori subnet anche se “sembra vicino”.

Altro caso tipico: /28. Hai 16 indirizzi totali e 14 utilizzabili. È un taglio comune per piccoli segmenti, interfacce point-to-point, reti di management molto strette o pool minimi. Se però ti servono 15 host reali, una /28 non basta: devi passare almeno a /27, che offre 30 host utilizzabili.

Tabella pratica dei prefissi più usati

Qui sotto ci sono i tagli che tornano spesso su server, hosting e networking interno. Non serve memorizzare tutto: basta riconoscere i casi frequenti.

/24  = 255.255.255.0     = 256 totali, 254 utilizzabili
/25  = 255.255.255.128   = 128 totali, 126 utilizzabili
/26  = 255.255.255.192   = 64 totali, 62 utilizzabili
/27  = 255.255.255.224   = 32 totali, 30 utilizzabili
/28  = 255.255.255.240   = 16 totali, 14 utilizzabili
/29  = 255.255.255.248   = 8 totali, 6 utilizzabili
/30  = 255.255.255.252   = 4 totali, 2 utilizzabili

Il /30 è stato per anni la scelta classica per collegamenti point-to-point IPv4, perché lascia due host utilizzabili. Oggi spesso si preferisce il /31 per link specifici, ma va usato solo dove il protocollo e il contesto lo consentono. Se non sai già che il tuo apparato supporta /31 nel modo corretto, non improvvisarlo su una rete di produzione.

Il caso dei /31 e dei /32: quando la regola “meno 2” non basta

La formula totale meno 2 funziona quasi sempre, ma non è una legge universale da applicare a occhi chiusi. Con un /31, per esempio, ci sono solo due indirizzi totali e in molti scenari point-to-point entrambi possono essere usati, senza il concetto tradizionale di network e broadcast. È una eccezione tecnica che ha senso su link dedicati, non per una LAN generica.

Con un /32 hai un singolo indirizzo. È tipico per identificare un host preciso, una route host-specific, un loopback o una destinazione molto mirata in routing e firewall. Qui non ha senso parlare di “host utilizzabili” nel modo classico della subnet condivisa.

Quindi la regola pratica è: se stai progettando una rete normale per server o client, usa il conteggio standard. Se stai lavorando su link dedicati, loopback, policy routing o configurazioni di apparati di rete, controlla il comportamento specifico del prefisso prima di applicare formule automatiche.

Errori tipici negli ambienti server

Il primo errore è confondere l’IP del server con l’IP di rete. Se assegni a un host l’indirizzo base della subnet, il sistema può sembrare configurato ma la connettività non funziona correttamente. Un esempio classico è mettere 192.168.50.0/24 come indirizzo di una macchina: .0 non è un host valido in quella rete.

Il secondo errore è sbagliare la mask lato gateway. Se il server ha 10.10.8.20/24 ma il gateway è configurato come se la rete fosse /23, il traffico verso alcuni indirizzi resterà locale invece di uscire, o viceversa. In pratica il problema si manifesta come routing incoerente, ARP strano o pacchetti che “spariscono” senza un guasto evidente al cavo o alla scheda.

Il terzo errore è usare sottoreti troppo grandi “per stare larghi”. In un ambiente piccolo, una /16 non aiuta: amplifica il dominio di broadcast, rende più difficile il controllo e complica la segmentazione. Se hai bisogno di separare web, database, management e backup, è spesso più pulito usare più subnet piccole e ben documentate.

Il quarto errore è dimenticare che alcuni servizi non vogliono solo un IP, ma anche una rete coerente. Un reverse proxy, un firewall o un bilanciatore possono richiedere che la subnet sia corretta per ACL, NAT, policy di sicurezza o health check. Se la subnet è sbagliata, il sintomo può non essere “sito giù”, ma solo una parte delle richieste che fallisce.

Come verificare al volo una configurazione di rete

Quando hai un dubbio, la verifica più semplice è confrontare indirizzo, mask e route. Su Linux puoi vedere la configurazione attiva con strumenti standard come ip addr e ip route. Quello che ti interessa è capire se l’interfaccia è dentro la subnet attesa e se il default gateway punta fuori dal blocco corretto.

ip addr show
ip route show

Se l’host è configurato correttamente, vedrai l’indirizzo con il prefisso giusto, per esempio 192.168.10.15/24, e una route di default coerente, per esempio via 192.168.10.1. Se invece trovi una mask diversa da quella prevista, la correzione va fatta prima di toccare DNS, applicazione o firewall: altrimenti insegui il sintomo sbagliato.

Un controllo ancora più rapido è pingare il gateway e un host noto nella stessa subnet. Se il gateway risponde ma un indirizzo nello stesso segmento no, il problema può essere sull’altro host. Se invece il gateway non risponde e la subnet è corretta, il guasto può essere locale, di VLAN, di switchport o di policy di rete.

Perché il prefisso giusto conta anche per performance e sicurezza

Il taglio della subnet non è solo una questione di ordine. Ha effetti concreti su broadcast, troubleshooting e separazione dei ruoli. Una rete troppo ampia può rendere più rumorosa la scoperta degli host e aumentare l’impatto di errori di configurazione o traffico anomalo. Una rete troppo stretta, invece, può saturarsi in fretta o obbligarti a riassegnare indirizzi con più cambi di configurazione del necessario.

Dal punto di vista della sicurezza, subnet diverse aiutano a imporre confini chiari. Web server, database, monitoraggio e accesso amministrativo non dovrebbero stare tutti nello stesso segmento solo per semplicità. Separare le reti non sostituisce firewall e ACL, ma riduce il raggio d’azione di un errore o di una compromissione.

Dal punto di vista operativo, una buona convenzione di subnetting rende più facile leggere i problemi. Se sai che 10.20.0.0/24 è management, 10.20.1.0/24 è storage e 10.20.2.0/24 è frontend, un traceroute o un log di firewall diventano molto più leggibili. Senza questa disciplina, ogni incidente richiede di ricostruire la mappa da zero.

Un esempio completo da usare come riferimento

Supponiamo di dover configurare una piccola rete server con 10 host reali, un gateway e spazio per crescita minima. Una /28 offre 14 host utilizzabili, quindi basta. La rete potrebbe essere 10.50.3.0/28. Gli indirizzi utilizzabili sarebbero da 10.50.3.1 a 10.50.3.14, mentre 10.50.3.15 è broadcast.

Se invece prevedi rapidamente una dozzina di server più bilanciatori, monitoraggio e management, una /28 diventa stretta. In quel caso una /27 è spesso più sensata: 30 host utilizzabili, stesso schema mentale, meno probabilità di dover rifare il piano di indirizzamento dopo poche settimane.

Questo è il vero vantaggio del CIDR: non scegli “una maschera”, scegli una dimensione di blocco coerente con il servizio. Il prefisso diventa uno strumento di progettazione, non solo un dettaglio di configurazione.

Regola pratica finale per non sbagliare

Se devi decidere in fretta, parti da tre domande: quanti host servono oggi, quanto margine vuoi tenere e se la rete è condivisa o dedicata. Poi scegli il prefisso più piccolo che non ti costringe a cambiare tutto dopo poco. In genere è meglio una subnet ben dimensionata e documentata che una rete “larga” scelta per comodità.

Quando leggi un indirizzo come 192.168.100.77/26, non fermarti al numero finale. Chiediti: qual è il blocco? qual è il broadcast? quanti host reali entrano? Una volta che ragioni così, CIDR e subnet mask smettono di essere notazione teorica e diventano uno strumento pratico per progettare e diagnosticare reti senza andare a tentoni.