Guide@Debianizzati.Org

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

Pagina Discussione

Un server DNS e DHCP su Debian (visualizza wikitesto)

Versione delle 20:46, 8 mag 2019

13 821 byte aggiunti ,  8 mag 2019
m
nessun oggetto della modifica
mNessun oggetto della modifica
 
(69 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|}}
{{Versioni compatibili|Squeeze|Wheezy}}{{Gateway-Router}}
<br/>
{{Warningbox|Per le versioni supportate di Debian si vedano le seguenti guide: [[Bind]] e [[ISC DHCP]]}}
 
== Introduzione ==
== Introduzione ==
In una rete locale con un server Linux e client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete. Linux risponde benissimo a quest'esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.
In una rete locale con un server Linux e client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete. Linux risponde benissimo a quest'esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.


Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Debian Etch/Lenny, isc-dhcp su Debian Squeeze), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l'intervento manuale dell'amministratore di sistema sia ridotto al minimo. Il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.
Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Debian Etch/Lenny, isc-dhcp da Debian Squeeze), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l'intervento manuale dell'amministratore di sistema sia ridotto al minimo. Il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.


=== IMPORTANTE ===
=== IMPORTANTE ===
Riga 16: Riga 19:


== Installazione e configurazione del server DNS ==
== Installazione e configurazione del server DNS ==
=== Installazione ===
Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux e le relative utilità, col comando:
Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux e le relative utilità, col comando:
<pre>
<pre>
# apt-get install bind9 dnsutils
# apt-get install bind9 dnsutils
</pre>
</pre>
=== Configurazione ===
A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev'essere delegata a se stesso, editando opportunamente il file <code>/etc/resolv.conf</code>.<br />
A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev'essere delegata a se stesso, editando opportunamente il file <code>/etc/resolv.conf</code>.<br />
Successivamente bisogna modificare il file principale di configurazione di Bind, ovvero nel caso di Lenny e precedenti <code>/etc/bind/named.conf</code>, mentre nel caso di Squeeze <code>/etc/bind/named.conf.local</code>. È tramite questi file che si definisce dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare nonché i diversi parametri in generale.<br />
Successivamente bisogna modificare il file principale di configurazione di Bind, ovvero nel caso di Lenny e precedenti <code>/etc/bind/named.conf</code>, mentre nel caso di Squeeze <code>/etc/bind/named.conf.local</code>. È tramite questi file che si definisce dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare nonché i diversi parametri in generale.<br />
Riga 26: Riga 33:
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato <code>/etc/bind/db.test</code> ed uno chiamato <code>/etc/bind/db.192.168.1</code>, che rappresenta il file in cui inserire i record PTR ("Domain Name Pointer", quelli di ricerca inversa). Di seguito vediamo come impostare il file <code>/etc/resolv.conf</code>, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 <code>/etc/bind/named.conf</code>, ed infine esamineremo i file di zona <code>/etc/bind/db.test</code> e <code>/etc/bind/db.192.168.1</code>, che rappresentano la zona che descrive la nostra rete LAN:
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato <code>/etc/bind/db.test</code> ed uno chiamato <code>/etc/bind/db.192.168.1</code>, che rappresenta il file in cui inserire i record PTR ("Domain Name Pointer", quelli di ricerca inversa). Di seguito vediamo come impostare il file <code>/etc/resolv.conf</code>, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 <code>/etc/bind/named.conf</code>, ed infine esamineremo i file di zona <code>/etc/bind/db.test</code> e <code>/etc/bind/db.192.168.1</code>, che rappresentano la zona che descrive la nostra rete LAN:


=== /etc/resolv.conf: ===
==== /etc/resolv.conf ====
Per quanto riguarda il server:
Per quanto riguarda il server:
<pre>
<pre>
Riga 35: Riga 42:
Nel caso di macchine linux prive di 'network-manager' (o altro applicativo equivalente) allora sarà necessario modificare <code>/etc/resolv.conf</code> manualmente come indicato sopra, ma indicando al posto di <code>127.0.0.1</code> l'indirizzo LAN del server (<code>192.168.1.1</code> nel caso di questa guida).
Nel caso di macchine linux prive di 'network-manager' (o altro applicativo equivalente) allora sarà necessario modificare <code>/etc/resolv.conf</code> manualmente come indicato sopra, ma indicando al posto di <code>127.0.0.1</code> l'indirizzo LAN del server (<code>192.168.1.1</code> nel caso di questa guida).


=== /etc/bind/named.conf: ===
==== /etc/bind/named.conf ====
====Lenny e precedenti====
===== Lenny e precedenti =====
Le seguenti modifiche sono necessarie solo in Lenny (o precedenti).
Le seguenti modifiche sono necessarie solo in Lenny (o precedenti).
<pre>
<pre>
Riga 63: Riga 70:
include "/etc/bind/named.conf.local"
include "/etc/bind/named.conf.local"
</pre>
</pre>
====Squeeze====
===== Da Squeeze in poi =====
'''NESSUNA''' modifica necessaria:
NESSUNA modifica necessaria:
<pre>
<pre>
...
...
Riga 71: Riga 78:
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.default-zones";
</pre>
</pre>
Come si vede le modifiche proposte per Lenny e precedenti non sono altro che lo standard in Squeeze (in buona sostanza si è passati da un unico file di configurazione a tre distinti).
Come si vede le modifiche proposte per Lenny e precedenti non sono altro che lo standard da Squeeze (in buona sostanza si è passati da un unico file di configurazione a tre distinti).


=== /etc/bind/named.conf.local: ===
==== /etc/bind/named.conf.local ====
<pre>
<pre>
zone "test.lan" {
zone "test.lan" {
Riga 85: Riga 92:
</pre>
</pre>


=== /etc/bind/db.test: ===
==== /etc/bind/db.test ====
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo.
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo.
<pre>
<pre>
$ORIGIN .
; ---Area 1---
; ---Area 1---
$TTL 86400      ; 1 day
$TTL 86400      ; 1 day
; ---Area 2---
; ---Area 2---
test.lan.       IN      SOA    ns1.test.lan. hostmaster.test.lan. (
test.lan      IN      SOA    ns1.test.lan. hostmaster.test.lan. (
                                   2007081501 ; serial
                                   2007081501 ; serial
                                   86400      ; refresh (1 giorno)
                                   86400      ; refresh (1 giorno)
Riga 100: Riga 109:
; ---Area 3---
; ---Area 3---
                 IN      NS      ns1.test.lan.
                 IN      NS      ns1.test.lan.
; ---Area 4---
; ---Area 4---
$ORIGIN test.lan.
;NOTA: ns1 è il nome del server che funge da DNS server
;NOTA: ns1 è il nome del server che funge da DNS server
ns1            IN      A      192.168.1.1
ns1            IN      A      192.168.1.1
Riga 106: Riga 117:
client          IN      A      192.168.1.3
client          IN      A      192.168.1.3
</pre>
</pre>
====Area 1====
===== Area 1 =====
La prima linea del file specifica il '''TTL''' (Time To Live) di questa zona e indica quanto tempo deve trascorrere prima che Bind controlli i file locali per verificare eventuali cambiamenti. Il valore di default è espresso in secondi, ma potrebbe essere espresso anche secondo altre unità di tempo.<br>
La prima linea del file specifica il '''TTL''' (Time To Live) di questa zona e indica quanto tempo deve trascorrere prima che Bind controlli i file locali per verificare eventuali cambiamenti. Il valore di default è espresso in secondi, ma potrebbe essere espresso anche secondo altre unità di tempo.<br>
Nel caso si sia configurato DHCP per aggiornare automaticamente bind, questo oltre ad inserire nuovi record provvederà anche a dichiare nuovi valori di ''$TTL''. Se per esempio ad un client è stato concesso un lease pari a 7200 secondi nel suddetto file il relativo record apparirà così:
Nel caso si sia configurato DHCP per aggiornare automaticamente bind, questo oltre ad inserire nuovi record provvederà anche a dichiare nuovi valori di ''$TTL''. Se per esempio ad un client è stato concesso un lease pari a 7200 secondi nel suddetto file il relativo record apparirà così:
Riga 115: Riga 126:
</pre>
</pre>


====Area 2====
===== Area 2 =====
Le linee successive indicano il '''SOA''' (Start Of Authority); il formato di questi record è il seguente:
Le linee successive indicano il '''SOA''' (Start Of Authority); il formato di questi record è il seguente:
<pre>
<pre>
Riga 130: Riga 141:
* IN e SOA indicano che il server è un SOA e un DNS per internet
* IN e SOA indicano che il server è un SOA e un DNS per internet
* primary nameserver - è il nome di dominio del server che stiamo installando
* primary nameserver - è il nome di dominio del server che stiamo installando
* email address of admin - l'email dell'amministratore del server
* email address of admin - l'email dell'amministratore del server, in cui il simbolo @ è sostituito da un .
* serial number - è il valore utilizzato dai server DNS slave per determinare se sono occorsi cambiamenti dall'ultima volta che hanno contattato il master DNS. È del tutto arbitrario (valore minimo 1, valore massimo molto grande) e nel caso di IP statici deve essere modificato manualmente dall'amministratore ogni volta che compie delle modifiche. In questa guida si è scelto un formato del tipo anno-mese-giorno-numero.
* serial number - è il valore utilizzato dai server DNS slave per determinare se sono occorsi cambiamenti dall'ultima volta che hanno contattato il master DNS. È del tutto arbitrario (valore minimo 1, valore massimo molto grande) e nel caso di IP statici deve essere modificato manualmente dall'amministratore ogni volta che compie delle modifiche. In questa guida si è scelto un formato del tipo anno-mese-giorno-numero.
* refresh - è l'intervallo di tempo che deve trascorrere prima che un server slave ricontatti il proprio master
* refresh - è l'intervallo di tempo che deve trascorrere prima che un server slave ricontatti il proprio master
Riga 137: Riga 148:
* negative caching ttl - è il periodo di tempo in cui uno slave server fornisce risposte negative alle interrogazioni
* negative caching ttl - è il periodo di tempo in cui uno slave server fornisce risposte negative alle interrogazioni


====Area 3====
===== Area 3 =====
Seguono poi le linee che indicano i Server DNS della rete, nel formato:
Seguono poi le linee che indicano i Server DNS della rete, nel formato:
<pre>
<pre>
Riga 149: Riga 160:
Si noti che omettendo di specificare un 'name' (si veda il paragrafo sulla sintassi generale) bind userà l'ultimo specificato, in questo caso il <code>test.lan.</code> specificato con la precedente direttiva 'SOA'.
Si noti che omettendo di specificare un 'name' (si veda il paragrafo sulla sintassi generale) bind userà l'ultimo specificato, in questo caso il <code>test.lan.</code> specificato con la precedente direttiva 'SOA'.


====Area 4====
===== Area 4 =====
Infine vengono specificati gli indirizzi delle macchine locali che posseggono un indirizzo IP statico, con la seguente sintassi:
Infine vengono specificati gli indirizzi delle macchine locali che posseggono un indirizzo IP statico, con la seguente sintassi:
<pre>
<pre>
Riga 155: Riga 166:
</pre>
</pre>


====Sintassi generale====
===== Sintassi generale =====
Con l'esclusione dell'area 1, vale la seguente sintassi:
Con l'esclusione dell'area 1, vale la seguente sintassi:
<pre>NAME    TTL    CLASS    RR    VARIE</pre>
<pre>NAME    TTL    CLASS    RR    VARIE</pre>
Riga 168: Riga 179:
* '''VARIE''', dipende dal parametro RR, per esempio un IP se 'RR=A'.
* '''VARIE''', dipende dal parametro RR, per esempio un IP se 'RR=A'.


====Misure di Tempo====
===== Misure di Tempo =====
In generale tutte le misure di tempo possono essere espresse come segue:
In generale tutte le misure di tempo possono essere espresse come segue:
* '''s''' = secondi = # x 1 secondi, es.: <code>$TTL 86400s</code> equivale a <code>$TTL 86400</code>, ovvero un giorno
* '''s''' = secondi = # x 1 secondi, es.: <code>$TTL 86400s</code> equivale a <code>$TTL 86400</code>, ovvero un giorno
Riga 177: Riga 188:
Si noti che tali unità possono essere combinate, per esempio 90s = 1m30s.
Si noti che tali unità possono essere combinate, per esempio 90s = 1m30s.


=== /etc/bind/db.192.168.1: ===
==== /etc/bind/db.192.168.1: ====
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo.
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo.
<pre>
<pre>
Riga 184: Riga 195:
;
;
$TTL    604800
$TTL    604800
@      IN      SOA    test.lan.      hostmaster.test.lan. (
@      IN      SOA    ns1.test.lan.      hostmaster.test.lan. (
                                 2007081501  ; serial
                                 2007081501  ; serial
                                 604800      ; refresh
                                 604800      ; refresh
Riga 206: Riga 217:
</pre>
</pre>


=== /etc/bind/db.0, db.127, db.255, db.empty, db.local ===
==== Altri file ====
* <code>/etc/bind/db.0</code>
* <code>db.127</code>
* <code>db.255</code>
* <code>db.empty</code>
* <code>db.local</code>
Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.
Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.


=== Riavvio del server ===
==== Riavvio del server ====
Fatta la configurazione, bisogna riavviare il demone bind9:
Fatta la configurazione, bisogna riavviare il demone bind9:
<pre>
<pre>
Riga 215: Riga 231:
</pre>
</pre>


=== Risoluzione di indirizzi internet ===
==== Risoluzione di indirizzi internet ====
Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l'utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file <code>/etc/bind/named.conf.options</code> aggiungendo queste righe:
Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l'utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file <code>/etc/bind/named.conf.options</code> aggiungendo queste righe:
<pre>
<pre>
allow-query { 127.0.0.1; 192.168.1/24; } ;
allow-query { 127.0.0.1; 192.168.1.0/24; } ;
allow-transfer { none; } ;  
allow-transfer { none; } ;  
allow-recursion { 127.0.0.1; 192.168.1/24; } ;
allow-recursion { 127.0.0.1; 192.168.1.0/24; } ;


forwarders {
forwarders {
Riga 253: Riga 269:
# apt-get install dhcp3-common dhcp3-server
# apt-get install dhcp3-common dhcp3-server
</pre>
</pre>
* '''Debian Squeeze'''
* '''Da Debian Squeeze'''
<pre>
<pre>
# apt-get install isc-dhcp-common isc-dhcp-server
# apt-get install isc-dhcp-common isc-dhcp-server
</pre>
</pre>
{{Warningbox|Il server DHCP appena installato tenterà subito di avviarsi, ma fallirà, non essendo ancora stato configurato. Non spaventatevi quindi se subito dopo l'installazione ricevete il messaggio "<code>Starting ISC DHCP server: dhcpdcheck syslog for diagnostics. ... failed!</code>".<br/>Basta proseguire nella lettura della guida e tutto andrà a posto}}


=== Configurazione ===
=== Configurazione ===
Riga 266: Riga 283:
# nano /etc/dhcp3/dhcpd.conf
# nano /etc/dhcp3/dhcpd.conf
</pre>
</pre>
* '''Debian Squeeze'''
* '''Da Debian Squeeze'''
<pre>
<pre>
# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.old
# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.old
Riga 302: Riga 319:
* '''ignore client-updates''', nega eventuali richieste da parte dei client di aggiornare autonomamente i record DNS.
* '''ignore client-updates''', nega eventuali richieste da parte dei client di aggiornare autonomamente i record DNS.
* '''subnet... netmask''', dichiarazione obbligatoria per ogni subnet che il server dhcp andrà a servire.
* '''subnet... netmask''', dichiarazione obbligatoria per ogni subnet che il server dhcp andrà a servire.
* '''range''', parametro obbligatorio se si intende assegnare degli indirizzi dinamici; è possibile specificare più di un intervallo come in quest'esempio, oppure anche nessuno se non si prevede di assegnare indirizzi dinamici.
* '''range''', parametro obbligatorio se si intende assegnare degli indirizzi dinamici; è possibile specificare più di un intervallo come in quest'esempio, oppure anche nessuno se non si prevede di assegnare indirizzi dinamici. È buona pratica evitare di dichiarare intervalli in cui figurino IP statici e/o staticamente assegnati dal server DHCP.
* '''default-lease-time''', la durata predefinita dell'assegnazione di un indirizzo IP ai client, ovvero quanti secondi devono passare prima che il server rinegozi nuovamente l'IP col client. Si noti che i client possono richiedere durate di assegnazione differente.
* '''default-lease-time''', la durata predefinita dell'assegnazione di un indirizzo IP ai client, ovvero quanti secondi devono passare prima che il server rinegozi nuovamente l'IP col client. Si noti che i client possono richiedere durate di assegnazione differente.
* '''max-lease-time''', la massima durata dell'assegnazione di un indirizzo IP che il server può concedere; in poche parole un client può chiedere che un certo indirizzo IP gli sia assegnato per un numero di secondi compreso tra 1 e ''max-lease-time''.<br>
* '''max-lease-time''', la massima durata dell'assegnazione di un indirizzo IP che il server può concedere; in poche parole un client può chiedere che un certo indirizzo IP gli sia assegnato per un numero di secondi compreso tra 1 e ''max-lease-time''.<br>
Riga 310: Riga 327:
# /etc/init.d/dhcp3-server start
# /etc/init.d/dhcp3-server start
</pre>
</pre>
* Debian Squeeze
* Da Debian Squeeze
<pre>
<pre>
# /etc/init.d/isc-dhcp-server start
# /etc/init.d/isc-dhcp-server start
</pre>
</pre>


=== Alcune note generali ===
=== Aggiornamento dinamico DNS ===
Visionando i manuali  ''dhcpd.conf'' e ''dhcpd-options'' si sarà probabilmente soppraffatti  dall'enorme mole di dati. Qui si vogliono sottolineare alcuni concetti  presenti nell'introduzione del manuale di ''dhcpd.conf'' (che fornisce molte informazioni importanti sulla logica di funzionamento di dhcp).<br>
Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all'aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l'aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all'installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file <code>/etc/bind/named.conf.local</code> per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:
Esistono due tipi di direttive utilizzabili nel file ''dhcpd.conf'':
* '''Parametri''': quantificano o dicono come fare qualcosa, definiscono se una certa operazione è permessa o meno. Per alcuni parametri è possibile assegnare un valore che non sia solo una costante, ma il risultato dell'elaborazione di una o più espressioni. È poi possibile distingeure tra parametri che influiscono esclusivamente sul server e parametri che riguardano i client; il nome di questi ultimi è composto in genere da due parti, la prima fissa e pari a "option" la seconda variabile. Si noti che questi parametri possono spesso essere definiti anche lato client attraverso il file ''dhclient.conf'', almeno su macchine linux. Naturalmente nessun client può imporre i valori di un parametro "option" al server a meno che l'amministratore non abbia deciso di permettere una cosa simile; vale anche il contrario, ma in tal caso perderebbe di significato la scelta di permettere una configurazione di rete automatica tramite dhcp.
* '''Dichiarazioni''': forniscono informazioni sulla topologia della rete, descrivono client e subnet, permettono di raggruppare parametri o altre dichiarazioni.
Nel caso di parametri d'avvio (boot parameters) definiti più volte, ma all'interno di differenti dichiarazioni, per determinare quali di questi un client deve adottare vale il principio di maggior specificità; per esempio un parametro presente all'interno della dichiarazione ''host'' prevale su qualsiasi parametro definito altrove: ''class'', ''pool'', ''subnet'', ''shared-network''.<br>
Segue una breve descrizione di alcune dichiarazioni disponibili:
* '''host''', contiene parametri e dichiarazioni relative ad uno specifico dispositivo fisico. Perché questo sia identificato univocamente è necessario dare un nome unico alla dichiarazione ''host'' e definire al suo interno il parametro ''hardware''. Si noti che il nome dato ad una dichiarazione ''host'' è del tutto arbitrario poiché completamente slegato dall'hostname del dispositivo fisico cui si fa riferimento; in caso di aggiornamento dinamico dei record DNS è possibile sostituire all'hostname del dispositivo uno di propria scelta attraverso il parametro ''ddns-hostname''. Dispositivi privi di una dichiarazione host vengono classificati come sconosciuti, cioè ''unknown-clients''.
* '''class''', permette di attribuire uno stesso set di parametri e o dichiarazioni a più dispositivi che non siano definiti dalla direttiva ''host''.
* '''pool''', associa set di parametri e/o dichiarazioni a specifici gruppi di indirizzi dinamici. Ogni dichiarazione ''pool'' deve contenere almeno uno di questi gruppi di indirizzi specificati attraverso la direttiva ''range'' ed è possibile regolarne l'accesso da parte dei vari client attraverso i parametri ''allow'', ''deny'' e ''ignore''. Ogni ''pool'' deve necessariamente essere inserita dopo le dichiarazioni ''subnet'' cui fa riferimento attraverso la definizione di ''range'', o al limite all'interno delle stesse (prestare attenzione alle pool che contengono intervalli di indirizzi appartenenti a più subnet).
* '''subnet''', dichiarazione obbligatoria per ogni subnet che il server dhcp dovrà gestire. Eventuali parametri e dichiarazioni di valità generale, purché strettamente legati alla subnet, possono essere inclusi nella specifica dichiarazione ''subnet''. Si noti che i parametri ''allow'', ''deny'' e ''ignore'' se definiti all'interno di questa dichiarazione prevalgono su quelli omonimi eventualmente specificati all'interno delle dichiarazioni ''pool''. L'assegnazione di un client ad una certa subnet avviene esclusivamente sulla base dell'indirizzo IP associato al medesimo.
* '''shared-network''', è obbligatorio fare una dichiarazione di questo tipo per ogni gruppo di subnet che condividono la stessa infrastruttura fisica. Si noti che in ogni caso dhcp provvede a creare autonomamente una dichiarazione ''shared-network'' nel caso si dichiari una sola subnet.
* '''group''', questa dichiarazione permette di raggruppare come le precedenti parametri e dichiarazioni di vario tipo, tuttavia se ne raccomanda l'utilizzo solo per accorpare quei parametri e dichiarazioni non strettamente legate ad una subnet.
 
==== Allow e Deny known/unknown clients ====
È importante prestare molta attenzione al parametro '''deny''' ''known/unknown clients'', infatti quando viene dichiarato in un certo ambito seguirà necessariamente che tutti gli ambiti più specifici ne saranno influenzati. Supponiamo per esempio di avere diversi intervalli di indirizzi IP e che la maggior parte di essi non debbano essere accessibili ai dispositivi sconosciuti; si potrebbe allora essere tentati di piazzare un bel ''deny unknown-clients'' a livello di ''shared-network'' o ''subnet'' e poi di dichiare ''allow unknown-clients'' nei singoli intervalli. Grave errore.<br>Quando un client contatta il server dhcp questi cerca un indirizzo IP e inizializza i vari parametri da passare al client; il server cerca una dichiarazione ''host'' per il client e non trovandola lo classifica come sconosciuto; successivamente valuta le dichiarazioni ''class'' (che supponiamo assenti) e poi quelle di tipo ''pool'', dove risulta che per tutte è possibile l'accesso da parte di client sconosciuti, poiché se non viene dichiarato ne ''allow'' ne ''deny'' chiunque ha accesso al range di indirizzi in oggetto.<br>
Il passo successivo è valutare le dichiarazioni ''subnet'' e ''shared-network'', dove per ipotesi il server troverà sicuramente la dichiarazione ''deny unknown-hosts''; poiché tale parametro non è mai stato definito in precedenza segue immediatamente che ''subnet'' o ''shared-network'' sono gli ambiti di definizione più specifici per il parametro, quindi quelli dove viene determinato il valore di ''deny'' per quanto riguarda l'accesso ai range di indirizzi (''allow'' e ''deny'' possono essere contemporaneamente usati anche per valutare altri aspetti) di tutte le ''pool''<br>
Ricapitolando si ha che per la maggioranza delle dichiarazioni ''pool'' risulta definito il solo parametro ''deny unknown-clients'' come effettivamente desiderato, mentre per le rimanenti risultano definiti contemporaneamente ''deny unknown-clients'' e ''allow unknown-clients''. Come esplicitamente scritto nel manuale, qualora per un range di IP risultino definiti sia i parametri ''allow'' che ''deny'' il client può averne accesso solo se appartiene alla lista dei client permessi e contemporaneamente NON appartiene a quella dei client impediti. Risulta quindi evidente che avendo scelto di discriminare l'accesso sulla base di conosciuto/sconosciuto tutti i client sconosciuti si vedranno impedito l'accesso ad ogni ''pool'', poiché al più soddisfano la condizione ''allow'', ma non quella ''deny''.<br>L'unica soluzione, a meno di non optare per una valutazione basata sull'utilizzo delle classi invece della parola chiave conosciuto/sconosciuto, è quella di definire il solo parametro ''deny unknown-clients'' nelle ''pool'' dove si vuole negare l'accesso ai client sconosciuti.
 
==== 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.
 
== Configurazione del DNS Dinamico ==
Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all'aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l'aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all'installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file <code>/etc/bind/named.conf.local</code> per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:
<pre>
<pre>
include "/etc/bind/rndc.key";
include "/etc/bind/rndc.key";
Riga 345: Riga 340:
};
};
</pre>
</pre>
Un'ulteriore modifica da fare al file <code>/etc/bind/named.conf.local</code> è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l'aggiornamento solamente tramite l'utilizzo della chiave segreta:  
Un'ulteriore modifica da fare al file <code>/etc/bind/named.conf.local</code> è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l'aggiornamento solamente tramite l'utilizzo della chiave segreta:  
<pre>
<pre>
zone "test.lan" {
zone "test.lan" {
Riga 358: Riga 353:
};
};
</pre>
</pre>
Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta <code>/etc/bind/rndc.key</code>. Ciò si traduce nell'aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf (/etc/dhcp/dhcpd.conf da Squeeze):
Il file completo, dopo l'aggiunta delle ACL per la gestione del traffico interno e esterno, dovrebbe avere questo contenuto:
<pre>
acl internals {
    127.0.0.0/8;
    192.168.1.0/24;
};
 
 
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
 
 
view "internal" {
        match-clients { internals; };
        recursion yes;
        zone "test.lan" {
          type master;
          file "/etc/bind/db.test";
          journal "/var/cache/bind/db.test.jnl";
          allow-update { key rndc-key; };
        };
        zone "1.168.192.in-addr.arpa" {
          type master;
          file "/etc/bind/db.192.168.1";
          journal "/var/cache/bind/db.192.168.1.jnl";
          allow-update { key rndc-key; };
        };
};
</pre>
Poichè nel file <code>/etc/bind/named.conf.local</code> abbiamo utilizzato la direttiva <code>view</code>, è necessario che tutte le zone di Bind siano configurate all'interno di una propria <code>view</code>. Perciò dobbiamo modificare anche il file <code>/etc/bind/named.conf.default-zones</code> aggiungendo all'inizio del file le righe:
<pre>
view "external" {
        match-clients { any; };
        recursion yes;
</pre>
e alla fine del file la corrispondente chiusura di istruzione:
<pre>
};
</pre>
Fatto questo, far ripartire il demone bind9.
<br/>
Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta <code>/etc/bind/rndc.key</code>. Ciò si traduce nell'aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf (/etc/dhcp/dhcpd.conf da Squeeze):
<pre>
<pre>
ddns-updates on;
ddns-updates on;
Riga 364: Riga 402:
ddns-update-style interim;
ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-domainname "test.lan.";
ddns-rev-domainname "1.168.192.in-addr.arpa.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
include "/etc/bind/rndc.key";
zone test.lan. {
zone test.lan. {
Riga 375: Riga 413:
         }
         }
</pre>
</pre>
L'ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l'utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l'aggiornamento di Bind da parte del server DHCP:
L'ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l'utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l'aggiornamento di Bind da parte del server DHCP:
<pre>
<pre>
# chmod 775 /etc/bind
# chmod 775 /etc/bind
</pre>
</pre>
Verificare che anche i file <code>db.test</code> e <code>db.192.168.1</code> siano scrivibili da bind (potrebbe succedere che uno o entrambi i file abbiano come proprietario <code>root:bind</code> e che i permessi di gruppo siano di sola lettura).<br />
Verificare che anche i file <code>db.test</code> e <code>db.192.168.1</code> siano scrivibili da bind (potrebbe succedere che uno o entrambi i file abbiano come proprietario <code>root:bind</code> e che i permessi di gruppo siano di sola lettura).<br />
Ora, un riavvio del demone dhcp3-server (isc-dhcp-server da Squeeze) completerà l'opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull'intera rete locale. Il vantaggio di questa soluzione è l'elevata automatizzazione dei processi descritti, che comporta un intervento dell'amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.
Ora, un riavvio del demone dhcp3-server (isc-dhcp-server da Squeeze) completerà l'opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull'intera rete locale. Il vantaggio di questa soluzione è l'elevata automatizzazione dei processi descritti, che comporta un intervento dell'amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.
 
=== Alcune note generali ===
Visionando i manuali  ''dhcpd.conf'' e ''dhcpd-options'' si sarà probabilmente soppraffatti  dall'enorme mole di dati. Qui si vogliono sottolineare alcuni concetti  presenti nell'introduzione del manuale di ''dhcpd.conf'' (che fornisce molte informazioni importanti sulla logica di funzionamento di dhcp).<br>
Esistono due tipi di direttive utilizzabili nel file ''dhcpd.conf'':
* '''Parametri''': quantificano o dicono come fare qualcosa, definiscono se una certa operazione è permessa o meno. Per alcuni parametri è possibile assegnare un valore che non sia solo una costante, ma il risultato dell'elaborazione di una o più espressioni. È poi possibile distingeure tra parametri che influiscono esclusivamente sul server e parametri che riguardano i client; il nome di questi ultimi è composto in genere da due parti, la prima fissa e pari a "option" la seconda variabile. Si noti che questi parametri possono spesso essere definiti anche lato client attraverso il file ''dhclient.conf'', almeno su macchine linux. Naturalmente nessun client può imporre i valori di un parametro "option" al server a meno che l'amministratore non abbia deciso di permettere una cosa simile; vale anche il contrario, ma in tal caso perderebbe di significato la scelta di permettere una configurazione di rete automatica tramite dhcp.
* '''Dichiarazioni''': forniscono informazioni sulla topologia della rete, descrivono client e subnet, permettono di raggruppare parametri o altre dichiarazioni.
Nel caso di parametri d'avvio (boot parameters) definiti più volte, ma all'interno di differenti dichiarazioni, per determinare quali di questi un client deve adottare vale il principio di maggior specificità; per esempio un parametro presente all'interno della dichiarazione ''host'' prevale su qualsiasi parametro definito altrove: ''class'', ''pool'', ''subnet'', ''shared-network''.<br>
Segue una breve descrizione di alcune dichiarazioni disponibili:
* '''host''', contiene parametri e dichiarazioni relative ad uno specifico dispositivo fisico. Perché questo sia identificato univocamente è necessario dare un nome unico alla dichiarazione ''host'' e definire al suo interno il parametro ''hardware''. Si noti che il nome dato ad una dichiarazione ''host'' è del tutto arbitrario poiché completamente slegato dall'hostname del dispositivo fisico cui si fa riferimento; in caso di aggiornamento dinamico dei record DNS è possibile sostituire all'hostname del dispositivo uno di propria scelta attraverso il parametro ''ddns-hostname''. Dispositivi privi di una dichiarazione host vengono classificati come sconosciuti, cioè ''unknown-clients''.
* '''class''', permette di attribuire uno stesso set di parametri e o dichiarazioni a più dispositivi che non siano definiti dalla direttiva ''host''.
* '''pool''', associa set di parametri e/o dichiarazioni a specifici gruppi di indirizzi dinamici. Ogni dichiarazione ''pool'' deve contenere almeno uno di questi gruppi di indirizzi specificati attraverso la direttiva ''range'' ed è possibile regolarne l'accesso da parte dei vari client attraverso i parametri ''allow'', ''deny'' e ''ignore''. Ogni ''pool'' deve necessariamente essere inserita dopo le dichiarazioni ''subnet'' cui fa riferimento attraverso la definizione di ''range'', o al limite all'interno delle stesse (prestare attenzione alle pool che contengono intervalli di indirizzi appartenenti a più subnet).
* '''subnet''', dichiarazione obbligatoria per ogni subnet che il server dhcp dovrà gestire. Eventuali parametri e dichiarazioni di valità generale, purché strettamente legati alla subnet, possono essere inclusi nella specifica dichiarazione ''subnet''. Si noti che i parametri ''allow'', ''deny'' e ''ignore'' se definiti all'interno di questa dichiarazione prevalgono su quelli omonimi eventualmente specificati all'interno delle dichiarazioni ''pool''. L'assegnazione di un client ad una certa subnet avviene esclusivamente sulla base dell'indirizzo IP associato al medesimo.
* '''shared-network''', è obbligatorio fare una dichiarazione di questo tipo per ogni gruppo di subnet che condividono la stessa infrastruttura fisica. Si noti che in ogni caso dhcp provvede a creare autonomamente una dichiarazione ''shared-network'' nel caso si dichiari una sola subnet.
* '''group''', questa dichiarazione permette di raggruppare come le precedenti parametri e dichiarazioni di vario tipo, tuttavia se ne raccomanda l'utilizzo solo per accorpare quei parametri e dichiarazioni non strettamente legate ad una subnet.
 
==== Allow e Deny known/unknown clients ====
È importante prestare molta attenzione al parametro '''deny''' ''known/unknown clients'', infatti quando viene dichiarato in un certo ambito seguirà necessariamente che tutti gli ambiti più specifici ne saranno influenzati. Supponiamo per esempio di avere diversi intervalli di indirizzi IP e che la maggior parte di essi non debbano essere accessibili ai dispositivi sconosciuti; si potrebbe allora essere tentati di piazzare un bel ''deny unknown-clients'' a livello di ''shared-network'' o ''subnet'' e poi di dichiare ''allow unknown-clients'' nei singoli intervalli. Grave errore.<br>Quando un client contatta il server dhcp questi cerca un indirizzo IP e inizializza i vari parametri da passare al client; il server cerca una dichiarazione ''host'' per il client e non trovandola lo classifica come sconosciuto; successivamente valuta le dichiarazioni ''class'' (che supponiamo assenti) e poi quelle di tipo ''pool'', dove risulta che per tutte è possibile l'accesso da parte di client sconosciuti, poiché se non viene dichiarato ne ''allow'' ne ''deny'' chiunque ha accesso al range di indirizzi in oggetto.<br>
Il passo successivo è valutare le dichiarazioni ''subnet'' e ''shared-network'', dove per ipotesi il server troverà sicuramente la dichiarazione ''deny unknown-hosts''; poiché tale parametro non è mai stato definito in precedenza segue immediatamente che ''subnet'' o ''shared-network'' sono gli ambiti di definizione più specifici per il parametro, quindi quelli dove viene determinato il valore di ''deny'' per quanto riguarda l'accesso ai range di indirizzi (''allow'' e ''deny'' possono essere contemporaneamente usati anche per valutare altri aspetti) di tutte le ''pool''<br>
Ricapitolando si ha che per la maggioranza delle dichiarazioni ''pool'' risulta definito il solo parametro ''deny unknown-clients'' come effettivamente desiderato, mentre per le rimanenti risultano definiti contemporaneamente ''deny unknown-clients'' e ''allow unknown-clients''. Come esplicitamente scritto nel manuale, qualora per un range di IP risultino definiti sia i parametri ''allow'' che ''deny'' il client può averne accesso solo se appartiene alla lista dei client permessi e contemporaneamente NON appartiene a quella dei client impediti. Risulta quindi evidente che avendo scelto di discriminare l'accesso sulla base di conosciuto/sconosciuto tutti i client sconosciuti si vedranno impedito l'accesso ad ogni ''pool'', poiché al più soddisfano la condizione ''allow'', ma non quella ''deny''.<br>L'unica soluzione, a meno di non optare per una valutazione basata sull'utilizzo delle classi invece della parola chiave conosciuto/sconosciuto, è quella di definire il solo parametro ''deny unknown-clients'' nelle ''pool'' dove si vuole negare l'accesso ai client sconosciuti.
 
==== 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.
 
==== 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.
 
{{Box|NOTA| 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 (traduzione) ====
 
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.
 
== Impostare la configurazione del Proxy ==
Oltre ai parametri già visti, è possibile impostare il DHCP Server affinchè rilasci automaticamente anche delle informazioni sulla configurazione del proxy in uso nella LAN. Questo può diventare utile quando sulla LAN è impostato un proxy con autenticazione, ma desideriamo evitare la configurazione manuale di tutti i client della rete.
<br/>
=== Proxy Auto Configuration (PAC) ===
Attraverso un file Javascript collocato nella root di un webserver Apache della LAN è possibile rilasciare automaticamente ai client le istruzioni per l'autoconfigurazione di un proxy server.
<br/>
Creiamo quindi questo file:
<pre>
# touch /var/www/wpad.dat
# chmod 644 /var/www/wpad.dat
# nano /var/www/wpad.dat
</pre>
e diamogli il contenuto:
<pre>
function FindProxyForURL(url, host)
{
if (!isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0"))
return "DIRECT";
 
return "PROXY 192.168.1.1:3128";
}
</pre>
dove:
* abilitiamo la navigazione sui siti web interni alla LAN senza passare dal proxy
* per la navigazione al di fuori della LAN configuriamo automaticamente il proxy con indirizzo IP 192.168.1.1 e in ascolto sulla porta 3128
Aggiungiamo un puntatore nel file di configurazione della zona di Bind:
<pre>
server        A      192.168.1.1
wpad          CNAME  server
</pre>
A questo punto dobbiamo configurare il server DHCP, agendo sul suo file di configurazione:
<pre>
# nano /etc/dhcp/dhcpd.conf
</pre>
e aggiungendo le opzioni:
<pre>
    option local-proxy-config code 252 = text;
    option local-proxy-config "http://server/wpad.dat";
</pre>
nella sezione generale del file.
<br/>
Infine modifichiamo il file <code>/etc/mime.types</code> affinchè Apache serva correttamente il file, aggiungendo la riga:
<pre>
application/x-ns-proxy-autoconfig              pac dat
</pre>


== Troubleshooting Bind ==
== Troubleshooting Bind ==
Riga 394: Riga 539:
* i clock non sono sincronizzati
* i clock non sono sincronizzati
* la chiave non è valida
* la chiave non è valida
=== Bind non riparte dopo un aggiornamento di sistema ===
Digitare:
<pre># journalctl -xe</pre>
Se compare questo errore:
<pre>
/etc/bind/named.conf.local:5: open: /etc/bind/rndc.key: permission denied
loading configuration: permission denied
exiting (due to fatal error)
</pre>
È probabile che si siano cambiato il proprietario del file <code>/etc/bind/rndc.key</code>. Verificare che il proprietario sia root e che il gruppo sia bind. Verificare inoltre che i permessi del file siano 640.


=== Errori in /var/log/syslog ===
=== Errori in /var/log/syslog ===
Riga 439: Riga 594:
</pre>
</pre>
Per disabilitare il log occorre ridare il comando precedente.
Per disabilitare il log occorre ridare il comando precedente.
==== error (no valid RRSIG) resolving nome.dominio ====
Il problema è nella funzione DNSSEC di Bind, che fa in modo che il server rifiuti di restituire risposte non validate. Per eliminare l'errore è sufficiente aggiungere al file <code>/etc/bind/named.conf.options</code> aggiungendo le linee:
<pre>
dnssec-enable no;
dnssec-validation no;
</pre>


=== Test di funzionamento ===
=== Test di funzionamento ===
Riga 513: Riga 675:
Jul  3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied
Jul  3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied
</pre>
</pre>
Questo indica un problema con la direttiva <code>allow-query { }</code> in <code>/etc/bind/named.conf.options</code>.
Questo indica un problema con la direttiva <code>allow-query { }</code> in <code>/etc/bind/named.conf.options</code>, ad esempio è indicato male il range di IP della nostra LAN.


== Troubleshooting dhcpd ==
== Troubleshooting dhcpd ==
=== isc-dhcp-server non riparte dopo un aggiornamento di sistema ===
Digitare da terminale:
<pre># systemctl status isc-dhcp-server.service</pre>
Se compaiono uno o più dei seguenti errori
<pre>No subnet declaration for ...</pre>
oppure
<pre>No subnet6 declaration for ...</pre>
e voi siete sicuri che la prima o entrambe (se usate anche IPv6) le dichiarazioni sono presenti, allora è necessario controllare il file <code>nano /etc/default/isc-dhcp-server</code> assicurandosi che sia presente (e non commentata) in coda la seguente dichiarazione (valida per IPv4):
<pre>INTERFACESv4="nome_interfacce"</pre>
dove nome_interfaccia è appunto il nome dell'interfaccia di rete su cui dhcpd deve rimanere in ascolto, ad es. "eth0" (NON omettere i doppi apici!). Si noti che è <code>INTERFACESv4</code> e non semplicemente <code>INTERFACES</code> come per le versioni più vecchie.
Prima di riavviare il demone digitare anche:
<pre># journalctl -xe</pre>
Se nel log compaiono sia <code>Failed to start LSB: DHCP server.</code> che <code>Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!</code> è necessario:
# arrestare il server
# eliminare manualmente il file <code>/var/run/dhcpd.pid</code>
A questo punto riavviare il demone e gli errori dovrebbero scomparire.


=== dhcp3 ===
=== dhcp3 ===
Riga 548: Riga 731:


== Esempi ==
== Esempi ==
=== Comandi utili ===
Elencare gli indirizzi IP dati in prestito da bind9:
<pre># dhcp-lease-list --lease /var/lib/dhcp/dhcpd.leases</pre>


=== Piccola LAN ===
=== Piccola LAN ===
Riga 679: Riga 866:
==== dhcpd.conf ====
==== dhcpd.conf ====
<pre>
<pre>
# Parametri globali
authoritative;
authoritative;
ignore client-updates;
ignore client-updates;
Riga 687: Riga 875:
ddns-domainname "small.lan.";
ddns-domainname "small.lan.";
include "/etc/bind/rndc.key";
include "/etc/bind/rndc.key";
zone dune.lan. {
zone small.lan. {
     primary 192.168.1.100;
     primary 192.168.1.100;
     key rndc-key;
     key rndc-key;
Riga 696: Riga 884:
}
}
# Fine zona aggiornamento automatico di Bind
# Fine zona aggiornamento automatico di Bind
# Fine area parametri globali
# Definizione rete
# Definizione rete
subnet 192.168.1.0 netmask 255.255.255.0 {
shared-network piccolalan {
    option broadcast-address 192.168.1.255;
    subnet 192.168.1.0 netmask 255.255.255.0 {
    option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.1.255;
    option routers 192.168.1.1;
        option subnet-mask 255.255.255.0;
    option ip-forwarding off;
        option routers 192.168.1.1;
    option domain-name "small.lan";
        option ip-forwarding off;
    option domain-search "small.lan";
        option domain-name "small.lan";
    option domain-name-servers 192.168.1.100;
        option domain-search "small.lan";
    default-lease-time 604800;
        option domain-name-servers 192.168.1.100;
    max-lease-time 1209600;
        default-lease-time 604800;
        max-lease-time 1209600;
    }
     pool {
     pool {
         deny unknown-clients;
         deny unknown-clients;
Riga 739: Riga 930:
}
}
</pre>
</pre>
Con questa configurazione i client che ricevono un indirizzo dinamico e che non sono raggruppati all'interno della direttiva group utilizzeranno direttamente server dns pubblici e non avranno accesso al server dns locale, non potendo così sapere nulla della LAN. Ovviamente tutto ciò non va interpretato come una procedura di sicurezza, ma solo come un artificio per non rendere immediatamente disponibili certe informazioni. Le variabili dichiarate all'interno della direttiva ''group'' prevalgono infatti su quelle omonime indicate nella direttiva ''subnet''.<br>
Con questa configurazione i client che ricevono un indirizzo dinamico e che sono sconosciuti (ovvero per cui non esiste una direttiva ''host'') utilizzeranno direttamente server dns pubblici e non avranno accesso al server dns locale, non potendo così sapere nulla della LAN. Ovviamente tutto ciò non va interpretato come una procedura di sicurezza, ma solo come un artificio per non rendere immediatamente disponibili certe informazioni.<br>
Nella direttiva ''group'' sono dichiarati quattro host, che in realtà corrispondono ai due portatili citati nella premessa iniziale; in sintesi una dichiarazione host per ogni interfaccia di rete. Sarebbe stato in teoria possibile dichiarare più di un mac address per host, ma pare che tale soluzione renda più lenta di un paio di minuti l'acquisizione/conferma dell'indirizzo IP assegnato da dhcp.<br>
Nella parte finale sono dichiarati quattro host, che in realtà corrispondono ai due portatili citati nella premessa iniziale; in sintesi una dichiarazione host per ogni interfaccia di rete. Sarebbe stato in teoria possibile dichiarare più di un mac address per host, ma pare che tale soluzione renda più lenta di un paio di minuti l'acquisizione/conferma dell'indirizzo IP assegnato da dhcp.<br>
Mentre a PC7 è stato assegnato un indirizzo prefissato (a prescindere dall'interfaccia usata), a PC8 non è stato assegnato alcun IP; questo significa che si vedrà assegnato un indirizzo IP dinamico dal range definito nella subnet, tuttavia per quanto già spiegato avrà comunque accesso al server DNS locale risultando quindi in grado di risolvere correttamente i nomi di ''small.lan''. L'opzione ''ddns-hostname'' fa si che il server DNS associ al suo IP non il nome host della macchina, ma quello qui definito, ovvero "PC8C" o "PC8W" a seconda dell'interfaccia usata per connettersi. Tale scelta è stata fatta a scopo puramente esemplicativo in quanto sarebbe stato molto più semplice associargli direttamente un IP statico ed inserire manulmente i relativi record nei file del server DNS (come fatto per PC7).<br>
Mentre a PC7 è stato assegnato un indirizzo prefissato (a prescindere dall'interfaccia usata), a PC8 non è stato assegnato alcun IP; questo significa che si vedrà assegnato un indirizzo IP dinamico dal range definito nella subnet, tuttavia per quanto già spiegato avrà comunque accesso al server DNS locale risultando quindi in grado di risolvere correttamente i nomi di ''small.lan''. L'opzione ''ddns-hostname'' fa si che il server DNS associ al suo IP non il nome host della macchina, ma quello qui definito, ovvero "PC8C" o "PC8W" a seconda dell'interfaccia usata per connettersi. Tale scelta è stata fatta a scopo puramente esemplicativo in quanto sarebbe stato molto più semplice associargli direttamente un IP statico ed inserire manulmente i relativi record nei file del server DNS (come fatto per PC7).<br>
In ultimo si fa presente che ogni computer per cui siano definite più dichiarazioni host deve accedere alla LAN con una sola interfaccia per volta, mai con due contemporaneamente (a meno che non siano associate a differenti subnet).
In ultimo si fa presente che ogni computer per cui siano definite più dichiarazioni host deve accedere alla LAN con una sola interfaccia per volta, mai con due contemporaneamente (a meno che non siano associate a differenti subnet).


==Riferimenti Esterni==
== Approfondimenti ==
[http://manpages.debian.net/cgi-bin/man.cgi?query=dhcpd.conf&apropos=0&sektion=0&manpath=Debian+6.0+squeeze&format=html&locale=en dhcpd.conf squeeze manpage]<br />
=== Manpages ===
[http://manpages.debian.net/cgi-bin/man.cgi?query=dhcp-options&sektion=5&apropos=0&manpath=Debian+6.0+squeeze&locale= dhcp-options squeeze manpage]
<code>man dhcpd.conf</code><br />
<code>man dhcpd-options</code><br />


=== Sitografia ===
[http://www.zytrax.com/books/dns/ Zytrax DNS open guide]<br />
[http://www.zytrax.com/books/dns/ Zytrax DNS open guide]<br />
[http://www.bind9.net/links Bind9, documentazione varia]<br />
[http://www.bind9.net/links Bind9, documentazione varia]<br />
[http://www.bind9.net/dhcp Dhcp, documentazione varia]
[http://www.bind9.net/dhcp Dhcp, documentazione varia]


{{Box|NOTE|Autore: [[Utente:Ferdybassi|Ferdybassi]]
{{Autori
: Esteso da [[Utente:Wtf|Wtf]] 11:52, 6 feb 2012 (CET)
|Autore = [[Utente:Ferdybassi|Ferdybassi]]
|Estesa_da =
: [[Utente:Wtf|Wtf]] 19:50, 12 feb 2012 (CET)
|Verificata_da=
: [[Utente:Wtf|Wtf]]
: [[Utente:gmc|gmc]]
: [[Utente:fexice|fexice]]
|Numero_revisori = 3
}}
}}


----
[[Categoria:DNS e DHCP]]
[[Categoria:DNS e DHCP]]
Wtf
2 894

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/27461...42759"