Michele PinassiIl DHCP, Dynamic Host Configuration Protocol, è un meccanismo che permette ai dispositivi di rete di acquisire un indirizzo IP per poter comunicare con tutti gli altri peers della rete attraverso il protocollo TCP/IP.
Anche se il DHCP è pressoché sconosciuto ai più, è il meccanismo che permette ad uno smartphone di navigare in rete via LTE o ad un PC portatile di poter accedere alla Rete attraverso un access point Wi-Fi: attraverso questo protocollo possiamo ignorare i parametri di rete quali router, maschera di rete, IP, DNS ed altre impostazioni di configurazione necessarie ai nostri dispositivi.
In dettaglio, quando un dispositivo di rete desidera “connettersi in rete” invia un pacchetto UDP chiamato “DHCPDISCOVER” in broadcast 255.255.255.255 da IP 0.0.0.0 (nel frame IP c’è il suo MAC address univoco). Se un server DHCP è in ascolto, dopo le opportune verifiche (questo MAC è abilitato ad avere un IP ? Ci sono slot liberi nella rete ?), risponde con un DHCPOFFER contenente un indirizzo IP “da offrire” al dispositivo, che può rispondere con un REQUEST esplicito (“Ok, questo IP mi piace: lo accetto !“). Il server DHCP a questo punto risponde con un ACK (“Ok, questo IP è il tuo !“) o con un NACK (“No, questo IP non può essere tuo“).
Con l’utility tcpdump (“tcpdump port 67 -v“) è possibile analizzare il traffico DHCP e visualizzare una richiesta:
0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from [MAC client] (oui Unknown), length 548, xid 0x6129aaa5, secs 16, Flags [Broadcast] Client-Ethernet-Address [MAC client] (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 24: Subnet-Mask, Time-Zone, Default-Gateway, IEN-Name-Server
al quale il server DHCP risponde assegnando l’IP che il dispositivo può usare ed il lease time, letteralmente “tempo di noleggio”, per il quale quel dispositivo può usare l’IP (generalmente al termine del lease time il terminale rinnova la richiesta di IP): questo sistema impedisce che un indirizzo IP rimanga allocato all’infinito per terminali non più connessi.
Comunque, non volevo dilungarmi troppo nel funzionamento del protocollo DHCP perché in questo articolo volevo spiegare come impostare due server DHCP in master/slave per assicurare maggiore continuità al servizio.
Un chiarimento: essendo il protocollo DHCP progettato per inviare richieste in broadcast via UDP, il contesto di operatività è limitato alla propria rete interna, non potendo “transitare” attraverso gateway se non esplicitamente (ad es. con l’uso di DHCP relayer). Questo comporta che in ogni rete deve esserci un unico server DHCP attivo (o, perlomeno, un solo server DHCP che risponde ad una certa classe di MAC address) poiché risposte multiple possono dare problemi e causare conflitto di indirizzo IP (errore “IP duplicato sulla rete”). Può comunque esserci la necessità, in ambienti dove l’affidabilità è importante, di avere un server DHCP “di scorta” da affiancare a quello ufficiale, in configurazione master/slave.
Nel nostro contesto di prova abbiamo due server DHCP 1 e DHCP 2, rispettivamente con IP 192.168.0.1 e 192.168.0.2, che assegnano IP in un pool tra 192.168.0.10 e 192.168.0.100, con il server DHCP dell’ISC installato (“apt-get install isc-dhcpd-server“):
Questa configurazione di esempio è la medesima su entrambi i server, da sostituire al dhcpd.conf nella directory /etc/dhcp/:
a questo punto dobbiamo configurare il meccanismo master/slave creando il file dhcpd_failover.conf e copiando il contenuto seguente nel server principale DHCP 1:
ed il seguente sul server di backup DHCP 2:
Adesso riavviate/eseguire i demoni DHCP su entrambi i server e nel log vedrete:
dhcp-01 dhcpd: failover peer voip: I move from normal to startup dhcp-01 dhcpd: Server starting service. dhcp-01 dhcpd: failover peer voip: peer moves from normal to communications-interrupted dhcp-01 dhcpd: failover peer voip: I move from startup to normal
nel caso uno dei due server dovesse “andare giù” il log vi segnalerà:
dhcp-01 dhcpd: peer voip: disconnected dhcp-01 dhcpd: failover peer voip: I move from normal to communications-interrupted
e non appena tornerà disponibile, il log indicherà:
dhcp-01 dhcpd: failover peer voip: peer moves from normal to normal dhcp-01 dhcpd: failover peer voip: I move from communications-interrupted to normal dhcp-01 dhcpd: failover peer voip: Both servers normal dhcp-01 dhcpd: balancing pool b95c1c58 192.167.0.0/24 total 12 free 13 backup 12 lts 0 max-own (+/-)4 dhcp-01 dhcpd: balanced pool b95c1c58 192.168.0.0/24 total 12 free 13 backup 12 lts 0 max-misbal 4 dhcp-01 dhcpd: Sending updates to voip.
Come potete notare, non appena la comunicazione sarà ripristinata, i due server DHCP sincronizzano le proprie tabelle di assegnazione: operazione che avviene attraverso la porta TCP 647 (assicuratevi che l’eventuale firewall sia configurato adeguatamente).
Ultima nota sul parametro split nella configurazione del server DHCP master: deve essere indicato un valore tra 0 e 255, che indica la “quota” in carico al server DHCP primario (0 = 0%, 255 = 100%), ovvero la ratio di risposta del primario e del secondario. Impostando 255, come nel mio esempio, si configura un vero e proprio failover: in assenza del primario, la palla passa al secondario. Inserendo, ad esempio, un valore di 127 (50%), i due server si passano la “palla” ogni tot secondo indicati dal parametro mclt: quando questo avviene, sul log del server che diventa “slave” vedrete voci tipo “dhcpd: DHCPDISCOVER from [MAC]: load balance to peer voip”.
Hai trovato utile questo articolo?
