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

m
Riga 363: Riga 363:
* ignorare il messaggio ''DHCPREQUEST'' del client;
* 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 ''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''.
* 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>
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>
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>
2 894

contributi