Un server DNS e DHCP su Debian: differenze tra le versioni
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
Riga 680: | Riga 680: | ||
Digitare da terminale: | Digitare da terminale: | ||
<pre>systemctl status isc-dhcp-server.service</pre> | <pre># systemctl status isc-dhcp-server.service</pre> | ||
Se compaiono uno o più dei seguenti errori | Se compaiono uno o più dei seguenti errori | ||
<pre>No subnet declaration for ...</pre> | <pre>No subnet declaration for ...</pre> | ||
Riga 690: | Riga 690: | ||
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!). | 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!). | ||
Prima di riavviare il demone digitare anche: | Prima di riavviare il demone digitare anche: | ||
<pre>journalctl -xe</pre> | <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: | 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 | # arrestare il server |
Versione delle 19:19, 21 giu 2017
Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.
Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione. |
Versioni Compatibili Debian 6 "squeeze" Debian 7 "wheezy" |
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.
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
L'ordine di risoluzione dei nomi è sempre:
- Lettura del file
/etc/hosts
(oC:\Windows\System32\Drivers\etc\hosts
in windows). - Se al precedente punto non si è ottenuto quanto desiderato segue un interrogazione del server DNS primario, che ai fini di questa guida non potrà che essere il server privato dell'utente. Si noti che qualora il server primario fosse non raggiungibile verrà contattato quello secondario ove specificato; a tal proposito val la pena specificare che se il secondario è un altro server privato dell'utente, ovvero uno slave, allora sarà possibile risolvere qualsiasi nome, viceversa se pubblico evidentemente non sarà possibile risolvere nomi associati alla propria LAN (o comunque non correttamente in caso di omonimia).
- Se anche al punto due non è stato possibile risolvere il nome, per esempio perché non associato ad un IP della propria LAN (ipotizzato naturalmente di aver configurato correttamente il tutto), allora il proprio server DNS privato inoltrerà la richiesta ad altri server DNS pubblici (opportunamente specificati nel file di configurazione).
Dalla sequenza appena descritta risulta evidente che se un utente vuole impedire la risoluzione corretta di un certo specifico nome su una certa macchina, allora è sufficiente specificare nel file hosts
di quel PC una corrispondenza errata IP/NOME.
Un ultima nota: mentre in debian qualsiasi cambiamento del file hosts
è istantaneo, in windows potrebbe non esserlo, come nel seguente esempio. Si supponga che sul server DNS sia fatta l'associazione (corretta) 'IP/NOME1' e che un utente tramite il proprio file hosts
la modifichi in 'IP/NOME2' (fittizia); se dopo tale modifica quest'utente esegue il comando ping NOME2
egli raggiungerà correttamente e immediatamente IP. Ipotizzando ora che tale utente elimini dal proprio file hosts
l'associazione fittizia 'IP/NOME2' e che successivamente esegua il comando ping NOME1
, potrebbe accadere che IP risulti irraggiungibile per diverso tempo, anche mezz'ora.
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:
# apt-get install bind9 dnsutils
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 /etc/resolv.conf
.
Successivamente bisogna modificare il file principale di configurazione di Bind, ovvero nel caso di Lenny e precedenti /etc/bind/named.conf
, mentre nel caso di Squeeze /etc/bind/named.conf.local
. È 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.
Sebbene in Lenny e precedenti sia possibile definire tutto nel file /etc/bind/named.conf
in questa guida si opterà per inserire le nostre zone "locali" in un file apposito, chiamato /etc/bind/named.conf.local
(metodologia divenuta standard in Squeeze, come già detto).
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test
ed uno chiamato /etc/bind/db.192.168.1
, che rappresenta il file in cui inserire i record PTR ("Domain Name Pointer", quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf
, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf
, ed infine esamineremo i file di zona /etc/bind/db.test
e /etc/bind/db.192.168.1
, che rappresentano la zona che descrive la nostra rete LAN:
/etc/resolv.conf
Per quanto riguarda il server:
search test.lan nameserver 127.0.0.1
Nel caso delle macchine client dipende, infatti per PC linux con connessioni di rete gestite attraverso 'network-manager' non è necessario effettuare alcuna modifica in quanto è lo stesso applicativo ad alterarlo in base alla configurazione della connessione in uso (si veda una guida di 'network-manager' per sapere come configurarlo). Men che meno evidentemente nel caso di client windows, dove è sufficiente editare le impostazioni della scheda di rete indicando come DNS primario il proprio server privato.
Nel caso di macchine linux prive di 'network-manager' (o altro applicativo equivalente) allora sarà necessario modificare /etc/resolv.conf
manualmente come indicato sopra, ma indicando al posto di 127.0.0.1
l'indirizzo LAN del server (192.168.1.1
nel caso di questa guida).
/etc/bind/named.conf
Lenny e precedenti
Le seguenti modifiche sono necessarie solo in Lenny (o precedenti).
include "/etc/bind/named.conf.options"; // prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; include "/etc/bind/named.conf.local"
Da Squeeze in poi
NESSUNA modifica necessaria:
... include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";
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
zone "test.lan" { type master; file "/etc/bind/db.test"; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.1"; };
/etc/bind/db.test
Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind
, ma va creato con un editor di testo.
$ORIGIN . ; ---Area 1--- $TTL 86400 ; 1 day ; ---Area 2--- test.lan IN SOA ns1.test.lan. hostmaster.test.lan. ( 2007081501 ; serial 86400 ; refresh (1 giorno) 28800 ; retry (8 ore) 604800 ; expire (1 settimana) 86400 ; minimum (1 giorno) ); ; ---Area 3--- IN NS ns1.test.lan. ; ---Area 4--- $ORIGIN test.lan. ;NOTA: ns1 è il nome del server che funge da DNS server ns1 IN A 192.168.1.1 ; Qui potete inserire gli IP dei client-server che hanno un IP statico client IN A 192.168.1.3
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.
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ì:
$TTL 7200 caio IN A 192.168.1.X $TTL 86400
Area 2
Le linee successive indicano il SOA (Start Of Authority); il formato di questi record è il seguente:
<domain name>. IN SOA <primary nameserver>. <email address of admin>. ( <serial number> <time to refresh> <time to retry> <time to expire> <negative caching ttl> )
dove
- domain name - indica il nome del dominio, seguito da un punto; specificando invece '@' vale quanto detto nel paragrafo dedicato alla sintassi generale.
- 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
- 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.
- refresh - è l'intervallo di tempo che deve trascorrere prima che un server slave ricontatti il proprio master
- retry - è il numero di tentativi di connessione che un server slave deve effettuare prima di chiudere il tentativo di aggiornamento
- expire - indica quanto tempo lo slave server deve continuare a fornire dati dopo che si è verificato un errore negli aggiornamenti da un master server
- negative caching ttl - è il periodo di tempo in cui uno slave server fornisce risposte negative alle interrogazioni
Area 3
Seguono poi le linee che indicano i Server DNS della rete, nel formato:
<domain name>. IN NS <nameserver1>. <domain name>. IN NS <nameserver2>.
NS significa Name Server, i quali possono essere specificati sia tramite FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama ns1
e pertanto la linea diventa:
IN NS ns1.test.lan.
Si noti che omettendo di specificare un 'name' (si veda il paragrafo sulla sintassi generale) bind userà l'ultimo specificato, in questo caso il test.lan.
specificato con la precedente direttiva 'SOA'.
Area 4
Infine vengono specificati gli indirizzi delle macchine locali che posseggono un indirizzo IP statico, con la seguente sintassi:
<full domain name>. IN A <IP address>
Sintassi generale
Con l'esclusione dell'area 1, vale la seguente sintassi:
NAME TTL CLASS RR VARIE
- NAME, che può essere:
- FQDN, per esempio
test.lan.
nel caso 'RR=NS'; - Non qualificato, per esempio
client
nel caso 'RR=A'; - @, nei soli caso 'RR=NS' e 'RR=SOA'; con questo carattere bind userà il valore specificato nella variabile $origin dell'area 1, oppure qualora non presente uno specificato nella direttiva 'zone' del file 'named.conf.local'.
- Omesso, è potenzialmente fonte di confusione. Se 'RR=A' bind userà l'ultimo valore di NAME precedente specificato, se invece 'RR=NS' bind userà sempre l'ultimo valore di NAME precedente specificato, ma se assente bind userà quello specificato nella variabile $origin dell'area 1, oppure qualora anche'esso non presente uno specificato nella direttiva 'zone' del file 'named.conf.local'.
- FQDN, per esempio
- TTL, generalmente omesso se si usa quello definito nell'area 1;
- CLASS, per esempio
IN
; - RR, ovvero "DNS Resource Record", per esempio
A
oNS
; - VARIE, dipende dal parametro RR, per esempio un IP se 'RR=A'.
Misure di Tempo
In generale tutte le misure di tempo possono essere espresse come segue:
- s = secondi = # x 1 secondi, es.:
$TTL 86400s
equivale a$TTL 86400
, ovvero un giorno - m = minuti = # x 60 secondi, es.:
$TTL 1440m
, ovvero un giorno - h = ore = # x 3600 secondi, es.:
$TTL 24h
, ovvero un giorno - d = giorni = # x 86400 secondi, es.:
$TTL 1d
, ovvero un giorno - w = settimane = # x 604800 secondi
Si noti che tali unità possono essere combinate, per esempio 90s = 1m30s.
/etc/bind/db.192.168.1:
Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind
, ma va creato con un editor di testo.
; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA ns1.test.lan. hostmaster.test.lan. ( 2007081501 ; serial 604800 ; refresh 86400 ; retry 2419200 ; expire 604800 ; negative cache ttl ); @ IN NS ns1.test.lan. 1 IN PTR ns1.test.lan. 3 IN PTR client.test.lan.
Il file segue la stessa sintassi vista analizzando il file db.test
precedente, con l'unica differenza che nel campo 'name' deve essere indicata l'ultima parte dell'indirizzo IP (o un carattere jolly come @); si noti ad esempio come
ns1 IN A 192.168.1.1 client IN A 192.168.1.3
divenga
1 IN PTR ns1.test.lan. 3 IN PTR client.test.lan.
Altri file
/etc/bind/db.0
db.127
db.255
db.empty
db.local
Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.
Riavvio del server
Fatta la configurazione, bisogna riavviare il demone bind9:
# /etc/init.d/bind9 restart
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 /etc/bind/named.conf.options
aggiungendo queste righe:
allow-query { 127.0.0.1; 192.168.1.0/24; } ; allow-transfer { none; } ; allow-recursion { 127.0.0.1; 192.168.1.0/24; } ; forwarders { 208.67.222.222; 208.67.220.220; };
all'interno della sezione principale del file:
options { directory "/var/cache/bind"; ... ... ... auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.
Per aumentare il livello di protezione sono state aggiunte anche le direttive allow
, permettendo le interrogazioni DNS solo dall'interno della lan e impedendo i trasferimenti di zona.
Installazione e configurazione del server DHCP
A questo punto prendiamo in considerazione l'ipotesi di necessitare dello stesso tipo di configurazione, per esempio nel caso di una rete locale con 10 o più host oppure nel caso di utenti che devono potersi connettere a più reti, ecc.
In questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi. È sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l'assegnazione dell'indirizzo IP ad un host, per cui va a farsi benedire la comodità dell'utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell'assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev'essere configurato per accettare gli aggiornamenti inviati dal server DHCP.
Installazione
Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell'installazione ed attivazione del server DHCP, senza per il momento prendere in esame l'aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:
- Debian Etch/Lenny
# apt-get install dhcp3-common dhcp3-server
- Da Debian Squeeze
# apt-get install isc-dhcp-common isc-dhcp-server
Configurazione
Fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:
- Debian Etch/Lenny
# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old # touch /etc/dhcpd3/dhcpd.conf # nano /etc/dhcp3/dhcpd.conf
- Da Debian Squeeze
# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.old # touch /etc/dhcp/dhcpd.conf # nano /etc/dhcp/dhcpd.conf
Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:
authoritative; server-identifier 192.168.1.1; ignore client-updates; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.150; range 192.168.1.200 192.168.1.250; option subnet-mask 255.255.255.0; default-lease-time 604800; # cioè una settimana max-lease-time 2592000; # cioè 30 giorni option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name-servers 192.168.1.1; option domain-name "test.lan"; option netbios-name-servers 192.168.1.1; option netbios-node-type 8; } # Assegnare un IP fisso ad un particolare client host pc_fisso { hardware ethernet 00:0D:87:B3:AE:A6; fixed-address 192.168.1.150; }
- Authoritative, obbligatorio se si tratta dell'unico server dhcp (a tal fine contano anche quelli di router e simili).
- server-identifier, utile se la propria interfaccia di rete possiede più di un indirizzo IP.
- 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.
- 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.
- 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.
A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:
- Debian Etch/Lenny
# /etc/init.d/dhcp3-server start
- Da Debian Squeeze
# /etc/init.d/isc-dhcp-server start
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 /etc/bind/named.conf.local
per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:
include "/etc/bind/rndc.key"; controls { inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; }; };
Un'ulteriore modifica da fare al file /etc/bind/named.conf.local
è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l'aggiornamento solamente tramite l'utilizzo della chiave segreta:
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; }; };
Il file completo, dopo l'aggiunta delle ACL per la gestione del traffico interno e esterno, dovrebbe avere questo contenuto:
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; }; }; };
Poichè nel file /etc/bind/named.conf.local
abbiamo utilizzato la direttiva view
, è necessario che tutte le zone di Bind siano configurate all'interno di una propria view
. Perciò dobbiamo modificare anche il file /etc/bind/named.conf.default-zones
aggiungendo all'inizio del file le righe:
view "external" { match-clients { any; }; recursion yes;
e alla fine del file la corrispondente chiusura di istruzione:
};
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 /etc/bind/rndc.key
. Ciò si traduce nell'aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf (/etc/dhcp/dhcpd.conf da Squeeze):
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; }
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:
# chmod 775 /etc/bind
Verificare che anche i file db.test
e db.192.168.1
siano scrivibili da bind (potrebbe succedere che uno o entrambi i file abbiano come proprietario root:bind
e che i permessi di gruppo siano di sola lettura).
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).
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.
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.
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.
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
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.
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 /var/lib/dhcp/
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Creiamo quindi questo file:
# touch /var/www/wpad.dat # chmod 644 /var/www/wpad.dat # nano /var/www/wpad.dat
e diamogli il contenuto:
function FindProxyForURL(url, host) { if (!isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0")) return "DIRECT"; return "PROXY 192.168.1.1:3128"; }
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:
server A 192.168.1.1 wpad CNAME server
A questo punto dobbiamo configurare il server DHCP, agendo sul suo file di configurazione:
# nano /etc/dhcp/dhcpd.conf
e aggiungendo le opzioni:
option local-proxy-config code 252 = text; option local-proxy-config "http://server/wpad.dat";
nella sezione generale del file.
Infine modifichiamo il file /etc/mime.types
affinchè Apache serva correttamente il file, aggiungendo la riga:
application/x-ns-proxy-autoconfig pac dat
Troubleshooting Bind
Bind non riparte dopo un riavvio
Utilizzando il comando rndc reload
qualche volta Bind può rifiutarsi di partire:
metaserver:/etc/bind# rndc reload rndc: connection to remote host closed
Questo può indicare che
- il server sta usando una vecchia versione del protocollo
- l'host da cui tentiamo di connetterci non è autorizzato alla connessione a Bind
- i clock non sono sincronizzati
- la chiave non è valida
Bind non riparte dopo un aggiornamento di sistema
Digitare:
# journalctl -xe
Se compare questo errore:
/etc/bind/named.conf.local:5: open: /etc/bind/rndc.key: permission denied loading configuration: permission denied exiting (due to fatal error)
È probabile che si siano cambiato il proprietario del file /etc/bind/rndc.key
. 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
Una volta che Bind è ripartito, con il comando /etc/init.d/bind9 restart
il passo successivo è controllare il file /var/log/syslog
in cerca di eventuali errori. Qui sotto proverò ad elencare i più comuni. Ricordatevi di riavviare Bind ogni volta che correggete un errore.
Missing Period in a Zone File
Questo errore indica che ci siamo dimenticati di inserire un punto .
alla fine della dichiarazione del FQDN all'interno dei files:
/etc/bind/db.test
/etc/bind/db.192.168.1
Filename Typo
I nomi dei files delle zone creati in /etc/bind
non corrispondono a quelli specificati nel file /etc/bind/named.conf.local
. Dovreste trovare anche un errore come il seguente:
Jul 3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file /etc/bind/db.1.169.192 failed: file not found
Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS?
Questo è un po' criptico:
Jul 3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:3: ignoring out-of-zone data (raptor.loc) Jul 3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:12: ignoring out-of-zone data (raptor.loc) Jul 3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has 0 SOA records Jul 3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has no NS records
Probabilmente uno dei files di zona non contiene le corrette dichiarazioni SOA.
Has no address records
zone 1.168.192.in-addr.arpa/IN: NS 'ns1.test.lan.1.168.192.in-addr.arpa' has no address records (A or AAAA) zone 1.168.192.in-addr.arpa/IN: not loaded due to errors
Controllare di non aver dimenticato il punto finale nel file db.192.168.1
, ovvero che ci sia scritto:
@ IN NS ns1.test.lan.
Turning Logging On/Off
Quando siamo alla ricerca di errori, può essere comodo abilitare temporaneamente il log di tutte le operazioni DNS sul file /var/log/syslog
usando il comando:
rndc querylog
Questo porterà alla registrazione di numerose linee come le seguenti:
Jul 3 21:25:40 eyrie named[3189]: client 192.168.1.200#32793: query: eyrie.raptor.loc IN A + Jul 3 21:25:41 eyrie named[3189]: client 192.168.1.200#32793: query: gyrfalcon.raptor.loc IN A +
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 /etc/bind/named.conf.options
aggiungendo le linee:
dnssec-enable no; dnssec-validation no;
Test di funzionamento
Una volta eliminati gli errori dai log possiamo testare il corretto funzionamento del server DNS, con i comandi
$ host
oppure
$ dig
Qui di seguito sono elencati alcuni problemi comuni:
Host Does not exist
Authoritative answer
gyrfalcon:~# host eyrie eyrie.raptor.loc does not exist (Authoritative answer)
Di solito questo indica un problema con il Forward DNS, oppure che è stato dimenticato un punto finale in uno di questi files:
/etc/bind/db.test
/etc/bind/db.192.168.1
Try Again
eyrie:~# host eyrie eyrie does not exist, try again
Occorre specificare il dominio di ricerca all'interno del file /etc/resolv.conf
.
Host Not Found
Diretto
caio@sempronio:~$ host sempronio sempronio has address 67.215.65.132 Host sempronio not found: 3(NXDOMAIN)
L'IP 67.215.65.132
è quello cui OpenDNS reindirizza in caso di errore nella risoluzione dei nomi; tale errore potrebbe quindi comparire solo se oltre ad aver errato qualcosa avete indicato tra i forwarders uno dei server di OpenDNS.
Un simile errore potrebbe essere dovuto ad un'errata definizione di sempronio nel file db.test
se l'host è statico, oppure all'impossibilità di dhcpd di aggiornare il file db.test
. In ogni caso consultare il file /var/log/syslog
per avere maggiori informazioni.
Inverso, SERVFAIL
caio@sempronio:~$ host 192.168.1.X Host X.1.168.192.in-addr.arpa not found: 2(SERVFAIL)
Controllare di aver definito correttamente tutti i client nel file db.192.168.1
, per esempio di non aver scritto qualcosa del tipo:
X IN PTR sempronio.test.lan
mancando evidentemente il punto finale, cioè sempronio.test.lan.
Nel solito file di log dovreste trovare un errore di questo tipo:
unable to add reverse map from X.1.168.192.1.168.192.in-addr.arpa. to sempronio.test.lan: timed out
Inverso, NXDOMAIN
caio@sempronio:~$ host 192.168.1.X Host X.1.168.192.in-addr.arpa not found: 3(NXDOMAIN)
Il suddetto IP non è presente nel file db.192.168.1
, nel caso di indirizzo dinamico ciò potrebbe essere dovuto o all'impossibilita di DHCP di aggiornare tale file, o alla presenza di errori di sintassi nel file che ne impediscono il caricamento o infine ad un inserimento errato da parte del server DHCP. In quest'ultimo caso potrebbe capitare di trovare un record indicato come
192.168.1.X PTR sempronio.test.lan.
invece di
X PTR sempronio.test.lan.
Se nel file dhcpd.conf
è stata inclusa la riga ddns-rev-domainname "1.168.192.in-addr.arpa.";
eliminatela, infatti quello che il DHCP fa è appendere 1.168.192.in-addr.arpa.
a X.1.168.192
. L'errore dovrebbe risultare evidente dal log, dove dovrebbe comparire la riga
added reverse map from X.1.168.192.1.168.192.in-addr.arpa. to sempronio.test.lan
quando invece quella corretta è
added reverse map from X.1.168.192.in-addr.arpa. to sempronio.test.lan
Record not found
eyrie:~# host eyrie eyrie A record not found, server failure
Il client non sta usando il corretto server DNS. Occorre modificare il file /etc/resolv.conf
oppure agire sulla configurazione di Network Manager.
Record query refused
eyrie:~# host eyrie eyrie.raptor.loc A record query refused
Dopo aver ottenuto questo errore comparirà una linea in /var/log/syslog
sul server DNS:
eyrie:~# tail /var/log/daemon.log Jul 3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied
Questo indica un problema con la direttiva allow-query { }
in /etc/bind/named.conf.options
, ad esempio è indicato male il range di IP della nostra LAN.
Troubleshooting dhcpd
isc-dhcp-server non riparte dopo un aggiornamento di sistema
Digitare da terminale:
# systemctl status isc-dhcp-server.service
Se compaiono uno o più dei seguenti errori
No subnet declaration for ...
oppure
No subnet6 declaration for ...
e voi siete sicuri che la prima o entrambe (se usate anche IPv6) le dichiarazioni sono presenti, allora è necessario controllare il file nano /etc/default/isc-dhcp-server
assicurandosi che sia presente (e non commentata) in coda la seguente dichiarazione (valida per IPv4):
INTERFACESv4="nome_interfacce"
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!). Prima di riavviare il demone digitare anche:
# journalctl -xe
Se nel log compaiono sia Failed to start LSB: DHCP server.
che Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!
è necessario:
- arrestare il server
- eliminare manualmente il file
/var/run/dhcpd.pid
A questo punto riavviare il demone e gli errori dovrebbero essere scomparsi.
dhcp3
Il demone non parte automaticamente all'avvio
Se sul proprio computer è configurato un bridge di rete è possibile che dhcp3-server parta prima che l'interfaccia di rete sia pronta, con conseguente errore e terminazione immediata del demone. Questo significa che avviandolo manualmente il demone partirà regolarmente.
Una possibile soluzione al problema è:
- rinominare lo script presente in
/etc/rc.2
daS##dhcp3-server
aK##dhcp3-server
, in modo da impedirne l'avvio automatico. - editare il file
/etc/network/interfaces
aggiungendo in coda all'interfaccia bridge
post-up /etc/init.d/dhcp3-server start pre-down /etc/init.d/dhcp3-server stop
Si avrà quindi un qualcosa del tipo:
iface br0 inet static bridge_ports eth0 eth1 address 192.168.1.X broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.Y post-up /etc/init.d/dhcp3-server start pre-down /etc/init.d/dhcp3-server stop
post-up avvia il demone subito dopo aver attivato l'interfaccia br0, mentre pre-down lo termina prima di disattivarla.
Impossibile accedere al file rndc.key
Può capitare che il demone dhcpd non riesca ad accedere al file /etc/bind/rndc.key
, il che costituisce un errore critico (cioè il demone non si avvia) se dhcpd è stato configurato per aggiornare automaticamente i DNS.
Una semplice soluzione è cambiare il gruppo proprietario del file da bind a dhcpd
# chown bind:dhcpd /etc/bind/rndc.key
Assicurarsi anche che i permessi sul file siano sufficienti, ad esempio 640.
Esempi
Piccola LAN
Ipotesi
- Una decina di dispositivi con indirizzi statici tra computer (client windows e debian squeeze, un server debian squeeze) e stampanti di rete. Visto il ridotto numero si opta per un inserimento manuale dei relativi record DNS, pur essendo abilitato l'aggiornamento automatico tramite DHCP.
- Un portatile con indirizzo prefissato tramite dhcp, ma DNS inserito manualmente, e un portatile con MAC address conosciuto, ma indirizzo assegnato dinamicamente. In entrambi i casi la connessione può essere si via cavo che senza fili.
- Alcuni utenti saltuari cui si vuole garantire l'accesso a internet, ma non alla propria LAN. Si presume che tali utenti si colleghino via wireless, ma teoricamente potrebero collegarsi anche tramite cavo.
- Si ipotizza l'assenza di utenti malintenzionati, ovvero di utenti che cerchino attivamente di superare con ogni mezzo i limiti imposti.
resolv.conf
Non definito per i client debian, poiché gestito tramite network-manager (men che meno per quelli windows).
Definito nel caso del server come:
search small.lan nameserver 127.0.0.1
named.conf.local
// // Do any local configuration here // include "/etc/bind/rndc.key"; controls { inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; }; }; zone "small.lan" { type master; file "/etc/bind/db.small"; 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; }; }; // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918";
named.conf.options
options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 allow-query { 127.0.0.1; 192.168.1/24; } ; allow-transfer { none; } ; allow-recursion { 127.0.0.1; 192.168.1/24; } ; // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder. forwarders { 208.67.220.220; 212.216.112.112; 208.67.222.222; 212.216.172.62; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
db.small
$ORIGIN . $TTL 2592000 ; 30 giorni small.lan IN SOA server.small.lan. admin.small.lan. ( 2012020713 ; serial 86400 ; refresh (1 day) 28800 ; retry (8 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) IN NS server.small.lan. $ORIGIN small.lan. router IN A 192.168.1.1 server IN A 192.168.1.100 PC1 IN A 192.168.1.105 PC2 IN A 192.168.1.106 PC3 IN A 192.168.1.107 PC4 IN A 192.168.1.108 PC5 IN A 192.168.1.109 PC6 IN A 192.168.1.110 PC7 IN A 192.168.1.111 ST1 IN A 192.168.1.116 ST2 IN A 192.168.1.117 ST3 IN A 192.168.1.118 alias1 IN CNAME server alias2 IN CNAME server
Attraverso CNAME è possibile definire degli alias per dei record precedentemente definiti, fatto che torna utile se per esempio si ha necessità di accedere ad una macchina attraverso differenti nomi, come nel caso di un server che ospiti diversi servizi (web server, server di posta, server ftp, ecc.). Alternativamente si potrebbero inserire altri record associando all'ip differenti nomi.
db.192.168.1
$ORIGIN . $TTL 2592000 ; 30 giorni 1.168.192.in-addr.arpa IN SOA server.small.lan. admin.small.lan. ( 2012020713 ; serial 86400 ; refresh (1 day) 28800 ; retry (8 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) IN NS server.small.lan. $ORIGIN 1.168.192.in-addr.arpa. 1 IN PTR router.small.lan. 100 IN PTR server.small.lan. 105 IN PTR PC1.small.lan. 106 IN PTR PC2.small.lan. 107 IN PTR PC3.small.lan. 108 IN PTR PC4.small.lan. 109 IN PTR PC5.small.lan. 110 IN PTR PC6.small.lan. 111 IN PTR PC7.small.lan. 116 IN PTR ST1.small.lan. 117 IN PTR ST2.small.lan. 118 IN PTR ST3.small.lan.
NON è possibile associare ad un indirizzo IP più di un nome di rete, diversamente dal file db.dune. Quindi non più di una direttiva PTR per IP e niente alias.
dhcpd.conf
# Parametri globali authoritative; ignore client-updates; # Parametri per l'aggiornamento automatico di Bind ddns-updates on; ddns-update-style interim; update-static-leases off; ddns-domainname "small.lan."; include "/etc/bind/rndc.key"; zone small.lan. { primary 192.168.1.100; key rndc-key; } zone 1.168.192.in-addr.arpa. { primary 192.168.1.100; key rndc-key; } # Fine zona aggiornamento automatico di Bind # Fine area parametri globali # Definizione rete shared-network piccolalan { subnet 192.168.1.0 netmask 255.255.255.0 { option broadcast-address 192.168.1.255; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option ip-forwarding off; option domain-name "small.lan"; option domain-search "small.lan"; option domain-name-servers 192.168.1.100; default-lease-time 604800; max-lease-time 1209600; } pool { deny unknown-clients; range 192.168.1.131 192.168.1.140; } pool { deny known-clients; range 192.168.1.151 192.168.1.160; default-lease-time 14400; max-lease-time 28800; option domain-name "none"; option domain-search "none"; option domain-name-servers 208.67.220.220, 212.216.112.112; } } # Definizione host noti host PC7C { hardware ethernet XX:XX:XX:XX:XX:XX; fixed-address 192.168.1.111; } host PC7W { hardware ethernet YY:YY:YY:YY:YY:YY; fixed-address 192.168.1.111; } host PC8C { hardware ethernet ZZ:ZZ:ZZ:ZZ:ZZ:ZZ; ddns-hostname PC8C; } host PC8W { hardware ethernet WW:WW:WW:WW:WW:WW; ddns-hostname PC8W; }
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.
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.
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).
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).
Approfondimenti
Manpages
man dhcpd.conf
man dhcpd-options
Sitografia
Zytrax DNS open guide
Bind9, documentazione varia
Dhcp, documentazione varia
Guida scritta da: Ferdybassi | Debianized 80% |
Estesa da:
| |
Verificata da: | |
Verificare ed estendere la guida | Cos'è una guida Debianized |