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

Vai alla navigazione Vai alla ricerca

Un server DNS e DHCP su Debian (visualizza wikitesto)

Versione delle 20:46, 8 mag 2019

5 989 byte aggiunti ,  8 mag 2019
m
nessun oggetto della modifica
mNessun oggetto della modifica
 
(58 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 30: 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 39: 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).
Riga 67: 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 75: 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 89: 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 104: 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 134: 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 188: 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 210: 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.


Riga 222: Riga 234:
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 257: 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 270: 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 314: 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>
=== Aggiornamento dinamico DNS ===
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>
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
</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:
<pre>
zone "test.lan" {
        type master;
        file "/etc/bind/db.test";
        allow-update { key rndc-key; };
};
zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
        allow-update { key rndc-key; };
};
</pre>
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>
ddns-updates on;
update-static-leases on;    # i client con ip statico sono compresi negli aggiornamenti 
ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
zone test.lan. {
        primary 192.168.1.1;
        key rndc-key;
        }
zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.1;
        key rndc-key;
        }
</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:
<pre>
# chmod 775 /etc/bind
</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 />
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 ===  
=== Alcune note generali ===  
Riga 356: Riga 457:
# Il client invia un messaggio ''DHCPDISCOVER'' al server.
# Il client invia un messaggio ''DHCPDISCOVER'' al server.
# Se non ci sono problemi si prosegue esattamente come nel caso A.
# 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.
 
{{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 =====
===== Traduzione =====
Riga 363: Riga 465:
* 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>
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>
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>
Riga 379: Riga 481:
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.
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 ==
== Impostare la configurazione del Proxy ==
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:
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>
<pre>
include "/etc/bind/rndc.key";
function FindProxyForURL(url, host)
controls {
{
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
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>
</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:  
A questo punto dobbiamo configurare il server DHCP, agendo sul suo file di configurazione:
<pre>
<pre>
zone "test.lan" {
# nano /etc/dhcp/dhcpd.conf
        type master;
        file "/etc/bind/db.test";
        allow-update { key rndc-key; };
};
zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
        allow-update { key rndc-key; };
};
</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):
e aggiungendo le opzioni:
<pre>
<pre>
ddns-updates on;
    option local-proxy-config code 252 = text;
update-static-leases on;    # i client con ip statico sono compresi negli aggiornamenti 
    option local-proxy-config "http://server/wpad.dat";  
ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "1.168.192.in-addr.arpa.";
include "/etc/bind/rndc.key";
zone test.lan. {
        primary 192.168.1.1;
        key rndc-key;
        }
zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.1;
        key rndc-key;
        }
</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:
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>
<pre>
# chmod 775 /etc/bind
application/x-ns-proxy-autoconfig              pac dat
</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 />
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.


== Troubleshooting Bind ==
== Troubleshooting Bind ==
Riga 436: 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 481: 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 555: 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 590: 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 785: 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
3 155

contributi

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

Menu di navigazione