Un server DNS e DHCP su Debian: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
Riga 340: Riga 340:
==== Conoscere i dettagli del ''lease'' concesso da client ====
==== Conoscere i dettagli del ''lease'' concesso da client ====
È possibile visualizzare i dettagli dei dati che il proprio client ha ricevuto dal server dhcp leggendo i file contenuti nella cartella <code>/var/lib/dhcp/</code> del client stesso.
È possibile visualizzare i dettagli dei dati che il proprio client ha ricevuto dal server dhcp leggendo i file contenuti nella cartella <code>/var/lib/dhcp/</code> del client stesso.
==== Assegnazione dinamica degli IP ====
Prima di presentare quella che è una traduzione dell'omonimo paragrafo del manuale si vuole riportare sinteticamente un paio di sequenze tipiche di una procedura per l'ottenimento di un IP da parte di un client.<br>
'''Caso A'''
# Il client invia un messaggio ''DHCPDISCOVER'' al server.
# Il server riesce a trovare un indirizzo valido e lo propone al client con un messaggio ''DHCPOFFER''.
# Il client accetta l'offerta e risponde al server con un messaggio ''DHCPREQUEST''.# Il server conferma il ''lease'' ("prestito") dell'indirizzo IP al client tramite un messaggio ''DHCPACK''.
# Il client può usare l'IP alle condizioni definite dal ''lease'' senza bisogno di contattare ulteriormente il server.
'''Caso B'''
# Il client ritiene di essere già in possesso di un ''lease'' valido ed invia un messaggio ''DHCPREQUEST'' al server.
# Il server risponde che la sua richiesta non è valida e gli invia un messaggio ''DHCPNAK''.
# Il client invia un messaggio ''DHCPDISCOVER'' al server.
# Se non ci sono problemi si prosegue esattamente come nel caso A.
Quello che preme sottolineare è che la procedura di assegnazione di un indirizzo IP non può che iniziare dai client, pertanto dispositivi configurati staticamente e server DHCP non si parleranno mai, se non in forma assai limita come descritto nel paragrafo relativo alla prevenzione dei conflitti tra indirizzi IP.
===== Traduzione =====
''
L'allocazione dinamica avviene effettivamente quando il client si trova nello stato INIT e ha già inviato al server un messaggio di tipo ''DHCPDISCOVER''. Qualora il client ritenga di possedere già un ''lease'' valido ed abbia già provveduto ad inviare un messaggio di tipo ''DHCPREQUEST'' per inizializzare o rinnovare il predetto ''lease'', si hanno tre modi in cui il server può comportarsi:
* ignorare il messaggio ''DHCPREQUEST'' del client;
* rispondere con un messaggio ''DHCPNAK'' per informare il client di non usare più quell'indirizzo;
* rispondere con un messaggio ''DHCPPACK'' per informare il client che può continuare ad usarlo per un po';Se il server trova l'indirizzo che il client richiede e quell'indirizzo è disponibile per il client, il server manderà un "DHCPACK". Se l'indirizzo non è più disponibile, o se al client non è permesso di usarlo, il server manderà un "DHCPNAK".
Se il server non ha alcun tipo di informazione sull'indirizzo eviterà di rispondere, a meno che l'indirizzo non sia corretto per il segmento di rete al quale il client è collegato e il server sia responsabile (''authoritative'', NdT) per il suddetto segmento di rete, nel qual caso invierà un "DHCPNAK" pur non avendo alcuna informazione sull'indirizzo.<br>Potrebbe esserci una dichiarazione ''host'' compatibile con l'identificazione del client se tale dichiarazione ''host'' include una dichiarazione ''fixed-address'' che specifichi un indirizzo IP valido per il segmento di rete al quale il client è connesso. In tal caso il server DHCP non gli allocherà mai dinamicamente un indirizzo, ma gli imporrà di usare l'indirizzo indicato nella dichiarazione ''host''. Qualora il client inviasse altri ''DHCPREQUEST'' per un qualsiasi altro indirizzo, il server risponderà con un  "DHCPNAK".<br>
Quando il server DHCP alloca un nuovo indirizzo per un client (si ricordi che ciò può avvenire solo se il client ha precedentemente inviato un ''DHCPDISCOVER''), per prima cosa controlla se il client possiede già un ''lease'' valido oppure se esiste un vecchio indirizzo IP già rilasciato al client, ma non ancora riassegnato ad altri. In quest'ultima circostanza il server verificherà in primis che tale indirizzo possa ancora essere usato dal client e, in caso negativo, provvederà a inserirlo nuovamente nell'elenco degli indirizzi disponibili per essere assegnati. Del resto il fatto che il client abbia mandato un ''DHCPDISCOVER'' prova inequivocabilmente che tale ''lease'' non fosse più utilizzato dallo stesso.<br>
Se nessun precedente ''lease'' viene individuato, o se al client è fatto divieto di ricevere tale ''lease'' preesistente, allora il server esaminerà i gruppi di indirizzi associati al segmento di rete del client in cerca di un ulteriore ''lease'' non occupato e per cui soddisfi i requisiti di assegnazione.Per fare ciò il server esaminerà sequenzialmente ogni dichiarazione ''pool'' (eventuali dichiarazioni ''range'' non incluse in dichiarazioni ''pool'' sono raggruppate in una dichiarazione ''pool'' priva di una lista permessi). Quando viene trovata una ''pool'' la cui lista permessi consente di allocare un indirizzo appartenente ad un intervallo di sua competenza il server verifica che esista un indirizzo non occupato e, se così è, prova ad assegnarglielo.<br>
In caso contrario procede ad esaminare una a una le ''pool'' successive finché non riesce ad assegnare un indirizzo al client. Se al termine della ricerca non è stato possibile individuare alcun indirizzo assegnabile il server si limita a non fornire alcuna risposta.<br>
Qualora venga trovato un indirizzo per cui il client ha i permessi e che non sia mai stato assegnato in precedenza, allora tale indirizzo gli viene allocato immediatamente. Se cade la seconda condizione il server continuerà a cercare un indirizzo sperando di trovarne uno che non sia mai stato dato in uso.<br>
Il server DHCP genera la lista degli IP disponibili a partire da una tabella ''hash'', pertanto gli indirizzi non vengono ordinati seguendo un particolare criterio e risulta impossibile predire l'ordine con cui il server DHCP provvederà ad allocarli. Sebbene gli utenti delle precedenti versioni di ISC DHCP Server possano essersi abituati ad un allocazione degli indirizzi in ordine ascendente, si ribadisce che dalla versione 3 ciò non è più possibile in alcun modo.
''
==== Prevenzione di possibili conflitti tra indirizzi IP ====
Quella che segue è una traduzione dell'omonimo paragrafo del manuale.<br><br>
Il server DHCP prima di allocare gli indirizzi IP controlla che questi non siano in uso inviando una richiesta ''ICMP Echo'' all'indirizzo che sta per essere allocato; se entro un secondo non viene ricevuta alcuno risposta ''ICMP Echo'' l'indirizzo viene ritenuto libero. Questa procedura scatta solo per quei ''lease'' specificati nelle varie dichiarazioni ''range'' e soltanto se il server riteneva tale ''lease' libero, come quando un server DHCP o la sua controparte d'emergenza non ha contrassegnato un certo lease come occupato.<br>
Se al contrario il server riceve una risposta ad una richiesta ''ICMP Echo'', allora ipotizza la presenza di un errore di configurazione dovuto al fatto che l'indirizzo IP in questione sia in uso presso un dispositivo di rete che non è un client DHCP. In tale situazione il suddetto indirizzo viene contrassegnato come abbandonato così che non possa essere assegnato ai client.<br>
Se non risultano indirizzi disponibili quando un client ne fa richiesta, il server tenterà di utilizzare uno degli indirizzi contrassegnati come abbandonati. Dopo aver contrassegnato detto indirizzo come libero si ripete la precedente procedura; se non viene ricevuta alcuna risposta ''ICMP Echo'' allora il server procede alla sua assegnazione presso il client.<br>
Il server DHCP non effettua alcuna iterazione degli indirizzi IP abbandonati se il primo che tenta di reclamare risulta libero. Piuttosto, quando riceve il successivo ''DHCPDISCOVER'' dal client tenterà tipicamente una nuova allocazione usando lo stesso metodo qui descritto, ma su un nuovo indirizzo IP.


== Configurazione del DNS Dinamico ==
== Configurazione del DNS Dinamico ==
3 155

contributi

Menu di navigazione