Configurare a mano indirizzo IP, maschera, gateway e DNS su tre computer è noioso ma fattibile. Farlo su cinquanta postazioni, telefoni, stampanti e access point diventa rapidamente ingestibile. DHCP nasce per centralizzare proprio questa parte della configurazione di rete.
Il client che si collega non conosce ancora né il proprio indirizzo né quello del server DHCP. Per questo la fase iniziale usa broadcast. Il classico scambio viene spesso riassunto come DORA: Discover, Offer, Request, Acknowledge. Il client cerca un server, il server propone una configurazione, il client la richiede e il server conferma il lease.
Il broadcast non attraversa il router
Questa caratteristica diventa importante non appena segmentiamo la rete. Ufficio e VoIP sono subnet differenti e il router non inoltra normalmente i broadcast DHCP da una VLAN all’altra. Non significa che serva un server DHCP per ogni rete: significa che serve un relay.
Il relay riceve la richiesta nella VLAN locale e la inoltra unicast al server centrale aggiungendo l’informazione necessaria a capire da quale rete provenga. Il server può così scegliere il pool corretto e restituire gateway, DNS e opzioni specifiche di quella subnet.
DHCP non fa routing
È qui che il vecchio articolo conteneva l’errore concettuale più importante: allargare la netmask a /16 per consentire a due reti 192.168.1.0 e 192.168.3.0 di “vedersi”. Una netmask dice all’host quali destinazioni considera locali; non è uno strumento per definire policy tra reti. Se due VLAN devono comunicare, devono farlo passando dal router, che potrà anche filtrare quella comunicazione.
Pool e reservation sono due cose diverse
Il pool contiene gli indirizzi dinamici che possono essere concessi ai client generici. Una reservation lega invece un identificatore, tipicamente il MAC address, a un indirizzo preciso. È molto utile per stampanti, telefoni o appliance che vogliamo mantenere stabili senza configurare manualmente l’IP sul dispositivo.
Con questi concetti chiari possiamo costruire il server centrale con Kea e i relay sulle diverse VLAN.
Lease: un indirizzo non viene “regalato” per sempre
DHCP assegna un indirizzo sotto forma di lease, cioè una concessione con una durata. Durante la vita del lease il client tenta di rinnovarlo prima della scadenza. Questo evita che un indirizzo rimanga occupato per sempre da un dispositivo che non esiste più e permette al server di riutilizzare gradualmente il pool.
La durata va scelta in funzione della rete. In una LAN aziendale stabile possiamo usare lease relativamente lunghi; in una guest network con dispositivi che entrano ed escono continuamente ha più senso ridurre il tempo. Lease troppo brevi aumentano il traffico DHCP e le scritture di stato, mentre lease eccessivamente lunghi rallentano il recupero degli indirizzi.
Come fa il server a capire da quale VLAN arriva il client?
Quando il client e il server sono sulla stessa rete, il server può usare l’interfaccia su cui ha ricevuto la richiesta. Quando invece c’è un relay, questo valorizza il campo giaddr del pacchetto DHCP con un indirizzo appartenente al link del client. Kea usa questa informazione per selezionare la subnet corretta e quindi il relativo pool, gateway e insieme di opzioni. È il meccanismo che rende possibile centralizzare il servizio DHCP senza fondere artificialmente le reti.
Questo dettaglio spiega anche perché il relay deve essere configurato sul router che conosce realmente la VLAN del client. Se inoltrassimo tutte le richieste senza un’identità di link coerente, il server non avrebbe abbastanza informazioni per scegliere in modo affidabile la subnet.
Topologia
Ufficio 192.168.1.0/24 gateway 192.168.1.254
Guest 192.168.2.0/24 gateway 192.168.2.254
VoIP 192.168.3.0/24 gateway 192.168.3.254
DHCP server: 192.168.1.100Il server è nella rete Ufficio. I broadcast DHCP delle altre VLAN non attraversano il router, quindi sul dispositivo L3 serve un DHCP relay che inoltri le richieste al server.
Perché Kea
Per una configurazione nuova è preferibile Kea rispetto al vecchio ISC DHCP Server. La configurazione è JSON e supporta pool, prenotazioni e backend moderni.
Installazione
apt update
apt search kea | grep dhcp4
# con i pacchetti ISC ufficiali:
apt install isc-kea-dhcp4Configurazione DHCPv4
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth0" ]
},
"valid-lifetime": 3600,
"option-data": [
{ "name": "domain-name-servers", "data": "192.168.1.100" }
],
"subnet4": [
{
"id": 1,
"subnet": "192.168.1.0/24",
"pools": [
{ "pool": "192.168.1.210 - 192.168.1.230" }
],
"option-data": [
{ "name": "routers", "data": "192.168.1.254" }
],
"reservations": [
{
"hw-address": "bc:ae:c5:91:2d:2f",
"ip-address": "192.168.1.201",
"hostname": "pc-ufficio-01"
}
]
},
{
"id": 2,
"subnet": "192.168.2.0/24",
"pools": [
{ "pool": "192.168.2.20 - 192.168.2.200" }
],
"option-data": [
{ "name": "routers", "data": "192.168.2.254" }
]
},
{
"id": 3,
"subnet": "192.168.3.0/24",
"pools": [
{ "pool": "192.168.3.20 - 192.168.3.100" }
],
"option-data": [
{ "name": "routers", "data": "192.168.3.254" }
]
}
]
}
}Validare prima del riavvio
kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
systemctl restart kea-dhcp4-server 2>/dev/null || systemctl restart isc-kea-dhcp4-server
journalctl -u kea-dhcp4-server -n 100 --no-pagerRelay
Sul router/switch L3 delle VLAN Guest e VoIP impostiamo come helper/relay l’indirizzo del server DHCP, 192.168.1.100. Il relay identifica la rete di provenienza e Kea seleziona la corretta subnet4.
Firewall e diagnostica
Il relay deve poter raggiungere il server su UDP 67. I client usano UDP 68. Non è necessario aprire tutta la VLAN verso il server.
tcpdump -ni any 'udp port 67 or udp port 68'
journalctl -u kea-dhcp4-server -f
ss -lunp | grep ':67'Se vediamo il DHCPDISCOVER arrivare ma non il DHCPOFFER, guardiamo Kea. Se non arriva nulla, il problema è nel relay, nel routing o nel firewall.
La correzione fondamentale
Ufficio 192.168.1.0/24 e VoIP 192.168.3.0/24 possono comunicare senza fingere di appartenere a una grande /16. Il router conosce entrambe le reti e il firewall decide quali flussi autorizzare. DHCP assegna parametri; non sostituisce il routing.
Riferimento
Kea DHCPv4 Server documentation.
Approfondimenti collegati
- Segmentare una rete con OpenWrt, per VLAN, zone e policy tra subnet.
- DNS autorevoli ridondati con BIND 9, per separare DHCP, DNS e routing senza confonderne i ruoli.
- Port scanning con Nmap, per verificare dall’esterno che il relay e gli altri servizi siano esposti solo dove previsto.
