Il DHCP (Dynamic Host Configuration Protocol) è il protocollo standard utilizzato per la configurazione automatica dei computer che usano il protocollo di rete TCP/IP.
Il protocollo DHCP può essere utilizzato per assegnare automaticamente indirizzi IP, per configurare parametri di rete (default router, subnet mask, server DNS, server SMTP, etc.).
Il protocollo DHCP si basa sul protocollo di trasporto non affidabile UDP.
Un server DHCP è in ascolto, per default, sulla porta UDP 67, mentre i client DHCP attendono, per default, i messaggi di risposta del server sulla porta UDP 68.
La transazione tra un client ed un server DHCP si articola in quattro fasi:
1.Il client invia in broadcast sulla sua rete (fisica) locale un messaggio DHCP di tipo DHCPDISCOVER: il messaggio contiene come indirizzo IP sorgente 0.0.0.0, come indirizzo IP destinazione 255.255.255.255 e al suo interno il MAC Address del client.
2.Ogni server DHCP che è in ascolto su quella rete, se dispone di indirizzi IP liberi e se quel client è autorizzato a riceverli da esso, invia in broadcast sulla rete un messaggio DHCP di tipo DHCPOFFER: il messaggio contiene come indirizzo IP sorgente l'indirizzo IP del server, come indirizzo IP destinazione 255.255.255.255, e al suo interno l'indirizzo MAC del client che ha inviato la richiesta, l'indirizzo IP offerto e alcuni parametri del protocollo DHCP (subnet mask, lease-time, etd.) forniti dal server.
3.Il client sceglie uno degli indirizzi che gli sono stati offerti e invia in broadcast sulla rete un messaggio DHCP di tipo DHCPREQUEST: esso contiene come indirizzo IP sorgente 0.0.0.0, come indirizzo IP destinazione 255.255.255.255 e al suo interno il proprio indirizzo MAC, l'indirizzo IP che ha accettato e l'indirizzo IP del server DHCP che glielo ha offerto.
4.Il server DHCP a cui è destinato il messaggio, se lo riceve, risponde inviando in broadcast un messaggio DHCP di tipo DHCPACK: il messaggio contiene come indirizzo IP sorgente l'indirizzo IP del server, come indirizzo IP destinazione 255.255.255.255 e al suo interno tutti i parametri DHCP che il server può offrire.
Alla scadenza del lease-time, l'indirizzo IP del client dovrà essere rinnovato tramite un nuovo scambio di messaggi con il server con relativo aggiornamento del valore del lease-time.
Di seguito viene riportata la struttura di un pacchetto DHCP, direttamente tratta dalla RFC 2131:
Ora vengono riportati tutti i campi del pacchetto DHCP con una breve spiegazione tratta dalla RFC 2131:
In particolare si deve osservare che il campo CHADDR contiene il Mac Address del mittente:
Esso si trova al 28esimo byte
Ha lunghezza pari a 16 bytes
Nel caso di Ethernet l'indirizzo ha dimensione pari a 6 bytes, pertanto nel campo CHADDR solo i primi 6 bytes avranno un valore significativo.
Questa RFC aggiunge una nuova opzione del protocollo DHCP, chiamata "Relay Agent Information", che permette di sfruttare tale protocollo per l'assegnamento automatico degli indirizzi IP da parte di un server DHCP che risiede su una rete diversa da quella dei client.
Per fare questo è necessaria la presenza di uno specifico server DHCP sulla stessa rete del client, detto "DHCP Relayer", il quale non assegna alcun indirizzo IP, ma ha il compito di effettuare il "relay" dei messaggi DHCP tra il server e i client.
Tuttavia il server DHCP deve "capire" che i messaggi di risposta ai client di questo tipo non dovranno essere inviati in broadcast sulla rete locale e inoltre dovranno contenere le opzioni specifiche per la rete di cui essi fanno parte.
Per fare questo il Relayer modifica un campo del messaggio DHCP ricevuto dal client:
1.Campo GIADDR (4 bytes): il relayer vi mette il proprio indirizzo IP. Il server DHCP invierà i pacchetti di risposta a tale indirizzo, il quale lo emetterà in broadcast sulla rete locale. E' usato per l'assegnazione degli indirizzi IP.
2.Campo CIADDR (4 bytes): il relayer vi mette l'indirizzo IP del client che ha inviato la richiesta. Questo campo è usato solo in caso di rinnovamento dell'indirizzo IP da parte del client.
All'arrivo di ogni messaggio, il server DHCP controlla il campo GIADDR. Se questo è diverso da 0.0.0.0, allora il messaggio proviene da un Relayer e la risposta dovrà essere inviata all'indirizzo specificato nel campo GIADDR. Se invece l'indirizzo contenuto è 0.0.0.0, allora viene controllato il valore del campo CIADDR. Se tale campo è diverso da 0.0.0.0, il messaggio proviene da un relayer e la risposta sarà inviata in unicast all'indirizzo contenuto in tale campo. Infine se entrambi i campi GIADDR e CIADDR sono uguali 0.0.0.0 il messaggio di risposta sarà inviato in broadcast sulla rete locale.
NOTA
Il server DHCP deve essere conforme alle specifiche imposte dall'estensione DHCP Relay.
<top>
La rete riservata alle palazzine del settore dell'ingegneria dell'informazione è suddivisa in varie sottoreti, ognuna delle quali può possedere uno o più propri server DHCP.
In particolare, nel caso preso in esame, la situazione comprendeva 4 sottoreti, servite da 4 DHCP server indipendenti.
L'obiettivo del progetto era la centralizzazione della gestione dell'assegnamento automatico degli indirizzi IP, con l'installazione di un unico server DHCP e dei necessari DHCP Relayers.
In particolare dovevano essere soddisfatte le seguenti richieste:
1.Il server deve servire client appartenenti a diverse reti.
2.In base alla rete a cui il client appartiene il server deve fornire opzioni diverse.
3.I client autorizzati a servirsi del server DHCP sono diversi a seconda della rete a cui appartengono (in particolare i client autorizzati per la rete "staff" della palazzina 1 sono autorizzati su tutte le reti, mentre client autorizzati per altre reti non lo sono, salvo eccezioni, per la palazzina 1).
<top>
Nel nostro caso è stato sufficiente installare solo due DHCP relayers a causa della struttura interna della rete (due sottoreti sono fisicamente collegate) ed un DHCP server. E' stato inoltre necessario creare un unico database centralizzato, contenente le informazioni necessarie a riservare l'uso del server DHCP ai soli client autorizzati: il nuovo database è stato creato a partire dai database in precedenza residenti sui vari server.
<top>
Come prima cosa abbiamo provveduto all'installazione di un server DHCP. Per fare questo abbiamo utilizzato il prodotto open source dhcp3-server di ISC (Internet System Consortium), disponibile per le più recenti distribuzioni dei sistemi operativi basati su Linux.
In seguito abbiamo modificato il file di configurazione /etc/dhcp3/dhcpd.conf per adattarlo alle specifiche richieste.
Per soddisfare i punti 1 e 2 abbiamo modificato il file di configurazione creando delle opportune "subnet", una per ogni sottorete che si doveva considerare (rete 23, 27, 28 e 29).
Inoltre abbiamo dovuto creare una "shared-network" in cui sono state inserite le sottoreti che sono fisicamente collegate tra di loro (27 e 28).
Per soddisfare l'ultimo punto sono state create delle "classi" di utenti: gli utenti che appartengono ad una classe condividono gli stessi diritti di accesso alle varie reti. In ogni "subnet" vengono opportunamente abilitate solo alcune classi di utenti, mentre le altre non possono accedere al servizio collegandosi da quella sottorete.
Il maggiore problema è stato trovare un metodo per raggruppare gli utenti in classi.
Per limitare l'accesso al servizio ai soli utenti autorizzati è stato necessario impedire il servizio ai client sconosciuti, inserendo la linea
deny unknown-clients;
all'inizio del file dhcpd.conf. Così facendo il server DHCP scarterà automaticamente tutte le richieste provenienti da quei client per cui non è presente una dichiarazione di tipo "host".
In seguito si devono creare tanti "host" quanti sono i possibili client: ognuno di essi deve avere un nome, che deve essere univoco in tutto il file dhcpd.conf, l'indirizzo MAC del client, che verrà usato per autenticarlo e, se necessario, un indirizzo IP statico.
Come prima cosa, per facilitare la gestione del database dei client autorizzati, si è scelto di aggiungere al nome di ogni host un prefisso che ne identifica la classe di appartenenza del client:
"inf_staff" per gli utenti staff che appartengono alla palazzina 1.
"inf_stud" per gli utenti studenti della palazzina 1.
"tlc" per gli utenti che appartengono della palazzina 2.
"dii" per gli utenti che appartengono alla palazzina 3.
Questa soluzione ha anche il vantaggio di permettere l'esistenza di due host con lo stesso nome, purchè appartengano a due classi diverse.
In generale la definizione di un host ha la seguente struttura:
host <prefix>-<name> {
hardware ethernet <MAC_address>;
}
Se per l'host si vuole specificare un indirizzo IP che verrà assegnato staticamente la dichiarazione sarà del tipo
host <prefix>-<name> {
hardware ethernet <MAC_address>;
fixed-address <IP_address>;
}
Il nome completo di un host risulta quindi composto da uno dei prefissi, seguito dal carattere separatore '-' e dal nome dell'host.
Sempre con l'intento di semplificare la gestione si è scelto di raggruppare la definizione degli host in diversi files, ognuno dei quali contiene le definizioni di tutti gli hosts che fanno parte della stessa classe.
Dunque esisterà un file per ogni classe di utenti. I files devono risiedere nella directory /etc/dhcp3/hosts/ e finora sono presenti i seguenti files:
"inf_staff": contiene le definizioni degli hosts che appartengono alla classe "inf_staff".
"inf_stud": contiene le definizioni degli hosts che appartengono alla classe "inf_stud".
"tlc": contiene le definizioni degli hosts che appartengono alla classe "tlc".
"dii": contiene le definizioni degli hosts che appartengono alla classe "dii".
Ogni file è incluso nel file dhcpd.conf, all'interno di una dichiarazione di tipo "group", tramite una istruzione di "include": esiste un gruppo per ogni classe. In questo modo a tutti gli host della stessa classe possono venire assegnate delle opzioni comuni, le quali sono indipendenti dalla rete in cui il client si trova.
La dichiarazione di un gruppo è del seguente tipo:
group <Nome_del_gruppo> {
<Opzioni_di_gruppo>;
include "/etc/dhcp3/hosts/<Nome_file>";
}
Così facendo le dichiarazioni degli hosts non dovranno più risiedere all'interno del file dhcpd.conf stesso, rendendo la gestione, sia del file stesso sia del database di hosts, molto più semplice.
Nota
All'arrivo di un pacchetto, il server DHCP opera nel seguente modo:
1.Estrae dal pacchetto il Mac Address del client.
2.Esamina tutte le dichiarazioni di tipo "host", alla ricerca di un Mac Address uguale a quello ricevuto.
3.Se trova una dichiarazione corrispondente il client è considerato "known".
4.Se non è stata trovata alcuna dichiarazione per quel client, esso verrà considerato "unknown".
Per creare una classe all'interno del file dhcpd.conf si può procedere in due modi. Il primo metodo per dichiarare una classe è il seguente:
class "<Nome_della_Classe>" {
match if <Condizione> = "<Valore>" ;
}
Così facendo, alla classe appartiene ogni host per cui è verificata la condizione <condition>.
Nota
La condizione specificata in <condition> può soltanto riguardare informazioni contenute all'interno del pacchetto DHCPDISCOVER inviato dal client. Questo modo di procedere è perciò molto limitato e l'unica soluzione di questo tipo da noi esplorata (e poi abbandonata) era la seguente:
Il client deve inviare all'interno del pacchetto DHCPDISCOVER una opzione di tipo "user-class", la quale contenga un valore significativo e fornito da chi gestisce il server DHCP. Per fare questo è necessario che il client configuri opportunamente il proprio client DHCP.
In base al valore contenuto nel pacchetto DHCPDISCOVER ricevuto, il server può raggruppare gli hosts nelle diverse classi.
Un esempio di dichiarazione della classe è il seguente
class "prova" {
match if option user-class = "pippo" ;
}
Con questa dichiarazione, gli hosts che fanno parte della classe "prova" sono solo quelli che inviano una opzione di tipo "user-class", il cui valore è "pippo".
La soluzione in questione ha alcuni gravi svantaggi:
Ogni utente che vuole utilizzare il servizio deve configurare in modo opportuno il proprio client DHCP. Sebbene questa sia una operazione piuttosto semplice, essa è assai differente in base al software utilizzato.
In sostanza non è il server a decidere a quale classe appartiene l'host, ma l'host stesso!
Specificando valori diversi per l'opzione "user-class" il client può essere inserito in classi diverse, e quindi possedere diversi diritti sul server DHCP.
Per questi motivi questo tipo di soluzione è stato abbandonato.
Il secondo metodo per creare una classe consiste nell'utilizzare le dichiarazioni di tipo "subclass": tramite tali dichiarazioni è possibile indicare esplicitamente quali sono gli hosts che fanno parte della classe.
L'unico svantaggio di questa soluzione è che la dichiarazione della classe stessa risulta maggiormente complessa.
Una dichiarazione di questo tipo ha la seguente forma:
class "<Nome_della_Classe>" {
match <Condizione> ;
}
subclass "<Nome_della_classe>" "<Valore_della_condizione>";
subclass "<Nome_della_classe>" "<Altro_valore_della_condizione>";
In questo modo gli hosts che fanno parte della classe sono solamente quelli per i quali la condizione di "match" assume uno dei valori specificati tramite le dichiarazioni ti tipo "subclass" per quella classe.
Nel nostro caso, per creare le classi di utenti si è scelto di utilizzare il metodo di dichiarazione tramite "subclass": come condizione per raggruppare i client nelle varie classi si è scelto di utilizzare il valore del Mac Address dell'host. Come già notato in precedenza il Mac Address del mittente di un pacchetto DHCP è specificato nel campo CHADDR, il quale si trova al 28° byte ed ha una dimensione di 16 bytes. Nel caso di un indirizzo Ethernet questo è contenuto nei primi 6 bytes del campo CHADDR.
La dichiarazione di una classe ha la seguente forma:
class "prova" {
match (binary-to-ascii(16,8,":",packet(28,6)) ;
}
L'espressione di tipo "binary-to-ascii" in sostanza estrapola dal pacchetto DHCP ricevuto il Mac Address di tipo Ethernet del client.
La dichiarazione della classe è seguita da dichiarazioni di tipo "subclass" come segue
subclass "prova" "<Indirizzo_Ethernet1>";
subclass "prova" "<Indirizzo_Ethernet2>";
subclass "prova" "<Indirizzo_Ethernet3>";
Così facendo alla classe prova appartengono solamente quei client che hanno come Mac Address uno degli indirizzi specificati, mentre tutti gli altri non vi appartengono.
L'espressione binary-to-ascii e packet hanno le seguenti forme, tratte dalle man pages di dhcp-eval(5):
binary-to-ascii (<numeric-expr1>, <numeric-expr2>, <data-expr1>,<data-expr2>)
Converts the result of evaluating data-expr2 into a text string containing one number for each element of the result of evaluating data-expr2. Each number is separated from the other by the result of evaluating data-expr1. The result of evaluating numeric-expr1 specifies the base (2 through 16) into which the numbers should be converted. The result of evaluating numeric-expr2 specifies the width in bits of each number, which may be either 8, 16 or 32.
packet (offset, length)
The packet operator returns the specified portion (offset bytes from the beginning, continuing for lenght bytes) of the packet being considered, or null in contexts where no packet is being considered.
Quindi la nostra espressione la potremmo così codificare:
binary-to-ascii (<base>, <numero di bit>, "<carattere separatore>", packet(<posizione>, <lunghezza>))
Con l'espressione specificata vengono presi i primi 6 bytes (nel caso Ethernet corrispondono all'intero indirizzo) dell'indirizzo Mac del client dal pacchetto dhcp e trasformato in caratteri ascii, a due a due separati dal carattere ":".
Nota
Si deve tenere presente che nelle dichiarazioni di tipo
subclass "<Nome_della_Classe>" "<Indirizzo_Ethernet>";
è OBBLIGATORIO rispettare le seguenti convenzioni per esprimere l'indirizzo Ethernet:
- Se una coppia di bytes inizia con uno 0, lo 0 deve essere OMESSO.
- Le lettere, se presenti, devono essere MINUSCOLE.
Ad esempio
L'indirizzo 00:0A:12:05:d0:3d, secondo queste convenzioni, diventerà 0:a:12:5:d0:3d.
In totale sono state create 4 classi di hosts differenti:
- "inf_staff": gli hosts che appartengono a questa classe sono abilitati all'utilizzo del server DHCP da qualsiasi rete.
- "inf_stud": contiene gli hosts che sono abilitati all'uso del DHCP server solo dalla rete 27.
- "tlc": contiene contiene gli hosts che sono abilitati all'uso del DHCP server solo dalla rete 29.
- "dii": contiene contiene gli hosts che sono abilitati all'uso del DHCP server solo dalla rete 23.
Poiché le dichiarazioni di tipo "subclass" sono assai numerose (una per ogni host), si è scelto di raggrupparle in differenti files per facilitare la gestione: in particolare tutte le dichiarazioni che si riferiscono ad una stessa classe sono contenute nello stesso file.
I files che contengono le dichiarazioni hanno un nome del tipo:
<className>-class
Tali files risiedono nella directory "/etc/dhcp3/hosts/" e devono essere inclusi nel file dhcpd.conf attraverso opportune istruzioni di "include".
Fino ad ora sono stati creati 4 files di questo tipo, uno per ogni classe:
- "inf_staff-class": contiene le definizioni "subclass" degli hosts che appartengono alla classe "inf_staff".
- "inf_stud-class": contiene le definizioni degli hosts che appartengono alla classe "inf_stud".
- "tlc-class": contiene le definizioni degli hosts che appartengono alla classe "tlc".
- "dii-class": contiene le definizioni degli hosts che appartengono alla classe "dii".
Dunque la creazione di una classe sarà del tipo:
class "prova" {
match if (binary-to-ascii(16,8,":",packet(28,6)) ;
}
include "/etc/dhcp3/hosts/prova-class";
La dichiarazione di una subnet ha la seguente forma
subnet <Indirizzo_di_Rete> netmask <Mask> {
<opzioni_da_assegnare_ai_client>;
pool {
allow members of <Nome_classe>
deny members of <Altra_classe>
range <1°_indirizzo_da_assegnare>
<Ultimo_indirizzo_da_assegnare>;
}
}
Le clausole "allow" e "deny" specificano quali classi di hosts sono abilitate a ricevere indirizzi in quella rete.
Per chiarezza si riportano di seguito i comportamenti del server DHCP in presenza di queste clausole:
1.Sono presenti solo clausole di tipo "allow": in questo caso solo gli hosts che fanno parte delle classi abilitate sono autorizzati a ricevere indirizzi di quella rete. Tutti gli hosts che non fanno parte di almeno una delle classi abilitate non potranno ricevere alcun indirizzo.
2.Sono presenti solo clausole di tipo "deny": in questo caso, solo gli host che non fanno parte delle classi disabilitate sono autorizzati a ricevere indirizzi.
3.Sono presenti sia clausole "allow" che "deny": in quest'ultimo caso gli hosts autorizzati a ricevere indirizzi dal server DHCP sono solamente quelli che fanno parte di almeno una delle classi abilitate e non fanno parte di nessuna delle classi disabilitate.
Infine, se ci si trova in presenza di reti fisicamente collegate tra di loro, è necessario provvedere alla dichiarazione delle rispettive subnet all'interno di una "shared-network", con una struttura del tipo
shared-network <Nome _shared-network> {
<Dichiarazione_Subnet1>
<Dichiarazione_Subnet2>
…
}
Per facilitare la gestione del server dhcp e del database di host sono stati creati due eseguibili, scritti in linguaggio c++, i cui sorgenti sono stati posti nella directory /etc/dhcp3/script/
I sorgenti da scaricare sono disponibili qui
import.cpp
addhost.cpp
import: permette di importare un elenco di hosts, dichiarati secondo la convenzione usata per dhcp3, da un file, generando i files necessari in /etc/dhcp3/hosts/
Con il comando
./import <Nome_file> <Nome_Classe>
Se esiste già il file /etc/dhcp3/hosts/<Nome_Classe> ad esso vengono aggiunte le dichiarazioni degli hosts presenti nel file <Nome_file>.
Se il file non esiste verrà creato.
Al nome di ogni host viene aggiunto il prefisso "<Nome_Classe>-"
Se esiste già il file <Nome_Classe>-class ad esso vengono aggiunte tutte le dichiarazioni di tipo subclass necessarie, una per ogni host, contenenti l'indirizzo Ethernet dell'host, tradotto nella convenzione utilizzata.
Se il file non esiste verrà creato.
addhost: facilita l'inserimento di un nuovo host, generando automaticamente le dichiarazioni necessarie, sia quella di tipo host che quella di tipo subclass.
Con il comando
./addhost /etc/dhcp3/hosts/<Nome_Classe> <Nome_Host>
viene lanciato il programma per l'inserimento di un nuovo host di nome <Nome_Host>.
In seguito:
1.Viene effettuata una scansione del file /etc/dhcp3/hosts/<Nome_Classe> per verificare che non esista già un host con lo stesso nome. Nel caso venga trovato un host omonimo il programma termina con un messaggio di errore, altrimenti continua la sua esecuzione.
2.Viene richiesto l'inserimento dell'indirizzo ethernet dell'host.
3.Viene richiesto all'utente se l'host dovrà avere un indirizzo variabile oppure statico. Nel caso di indirizzo statico verrà richiesto l'indirizzo che si vuole assegnare.
4.Viene richiesto l'inserimento di un commento riguardante l'host
5.Viene richiesta la conferma prima di procedere alla scrittura sul file
Se l'utente completa con successo l'inserimento viene aggiunta nel file /etc/dhcp3/hosts/<Nome_Classe> la dichiarazione relativa al nuovo host e viene generata la dichirazione di tipo subclass nel file /etc/dhcp3/hosts/<Nome_Classe>-class, la quale abilita l'host a fare parte della classe <Nome_Classe>.
Di seguito è riportato il contenuto del file dhcpd.conf, con l'aggiunta di alcuni commenti:
####################################################################
# Amministrazione di Reti A anno accademico 2004/2005
# dhcpd.conf
# Studenti: Gatti Luca, Minari Andrea
####################################################################
# Opzioni globali
deny unknown-clients;
option domain-name "unipr.it";
default-lease-time 28800;
max-lease-time 86400;
# Classi di utenti
class "inf_staff" {
match (binary-to-ascii(16,8,":",packet(28,6)));
}
include "/etc/dhcp3/hosts/inf_staff-class";
class "inf_stud" {
match (binary-to-ascii(16,8,":",packet(28,6)));
}
include "/etc/dhcp3/hosts/inf_stud-class";
class "tlc" {
match (binary-to-ascii(16,8,":",packet(28,6)));
}
include "/etc/dhcp3/hosts/tlc-class";
class "dii" {
match (binary-to-ascii(16,8,":",packet(28,6)));
}
include "/etc/dhcp3/hosts/dii-class";
#
# Inizio dichiarazione reti
#
# Rete della palazzina 1
shared-network inf-network {
option domain-name "ce.unipr.it";
option nis-domain "BInfo.Eng.UniPR.IT";
option smtp-server mail.ce.unipr.it;
option pop-server mail.ce.unipr.it;
option www-server www.ce.unipr.it;
option time-servers 160.78.253.254;
option ntp-servers 160.78.253.254;
option nntp-server news.unipr.it;
# Sottorete Staff Palazzina 1
subnet 160.78.28.0 netmask 255.255.255.0 {
#deny bootp;
option lpr-servers downlaser.ce.unipr.it, aida.ce.unipr.it;
option routers 160.78.28.1;
option domain-name "ce.unipr.it";
option domain-name-servers 160.78.28.83, 160.78.31.139;
option broadcast-address 160.78.28.255;
option subnet-mask 255.255.255.0;
pool{
allow members of "inf_staff";
range 160.78.28.200 160.78.28.239;
}
}
# Fine Sottorete Staff
# Sottorete Studenti Palazzina 1
subnet 160.78.27.128 netmask 255.255.255.128 {
deny bootp;
option lpr-servers downlaser.ce.unipr.it;
option routers 160.78.27.254;
option domain-name-servers 160.78.28.83, 160.78.31.139;
option broadcast-address 160.78.27.255;
option subnet-mask 255.255.255.128;
pool {
allow members of "inf_stud";
range 160.78.27.130 160.78.27.190;
}
}
# Fine Sottorete Studenti
}
# Fine Palazzina 1
#
# Rete Palazzina 2
#
subnet 160.78.29.0 netmask 255.255.255.0 {
option routers 160.78.29.254;
option domain-name-servers 160.78.28.83, 160.78.31.139;
option broadcast-address 160.78.29.255;
option subnet-mask 255.255.255.0;
pool {
allow members of "tlc";
allow members of "inf_staff";
range 160.78.29.109 160.78.29.110;
}
}
# Fine Palazzina 2
#
# Rete Palazzina 3
#
subnet 160.78.23.0 netmask 255.255.255.0 {
default-lease-time 86400; #one day
max-lease-time 604800; #one week
option routers 160.78.23.254;
option broadcast-address 160.78.23.255;
option subnet-mask 255.255.255.0;
option domain-name "dii.unipr.it";
option domain-name-servers 160.78.31.139, 192.135.11.20;
pool {
allow members of "dii";
allow members of "inf_staff";
range 160.78.23.200 160.78.23.230;
}
}
# Fine Palazzina 3
#
# Inizio dichiarazione Gruppi
# Serve per aggiungere opzioni a seconda del gruppo (diverso Lease-Time), ecc...
#
group inf_staff {
include "/etc/dhcp3/hosts/inf_staff";
}
group inf_stud {
include "/etc/dhcp3/hosts/inf_stud";
}
group tlc {
include "/etc/dhcp3/hosts/tlc";
}
group dii {
include "/etc/dhcp3/hosts/dii";
}
# Fine Dichiarazione Gruppi
# Fine File
<top>
Per installare un DHCP Relayer si deve installare il pacchetto dhcp3-relay e lanciare il programma con la riga di comando
dhcprelay3 -i <interface> <dhcp_server>
dove:
<interface> è l'interfaccia di rete del Relayer sulla quale è in ascolto.
<dhcp_server> è l'indirizzo IP o il nome del server dhcp a cui verranno inoltrate le richieste.
Nota
E' necessario che la macchina sulla quale è installato il dhcp3-relay possieda una tabella di routing ben configurata: in particolare si deve poter raggiungere il server dhcp a cui si vogliono inoltrare le richieste ricevute.
<top>
Se tra Dhcp server e Relayer è presente un firewall si deve provvedere all'apertura delle porte UDP 67 sul DHCP server e della porta UDP 68 su tutti i DHCP Relayers.