ISC DHCP – Serveur DHCP primaire

untitled2

ISC DHCP est une implémentation Open Source du protocole DHCP (Dynamic Host Configuration Protocol), sous licence ISC License, écrite à l’origine par Ted Lem, sous contrat avec Vixie Labs, et dont le projet fut financé par l’Internet Systems Consortium (ISC).
La version 1 vit le jour en décembre 1997; elle ne comportait que la version serveur.
La version 2, de juin 1999, ajouta la partie cliente et l’agent de relais BOOTP/DHCP.
La version 3, sortie en octobre 2001 et financée par Nominum Inc., comportait de nombreux ajouts : support de la redondance pour la continuité de service, OMAPI, Dynamic DNS, le comportement conditionnel, la division des clients en classes, et bien plus encore…
La version 4, la dernière en date, sortie en décembre 2007, ajoutait enfin le support de l’IPv6 pour les parties cliente et serveur.

 

Objectif

 
L’objectif de cet article est l’installation et la configuration d’un serveur DHCP primaire, ou master, utilisant l’implémentation ISC DHCP, sur une distribution Linux Debian Jessie 8.4 32bits.
 

Schéma logique

 

dora

 

NOUVEAU BAIL
Serveur DHCP Communication Client DHCP

UDP 67

Broadcast L3
Broadcast L2

DHCPDISCOVER

DHCPOFFER

Broadcast L3
Unicast L2

UDP 68

UDP 67

Broadcast L3
Broadcast L2

DHCPREQUEST

DHCPACK

Broadcast L3
Unicast L2

UDP 68
  1. DHCPDISCOVER : Le client DHCP envoie une requête d’IP en UDP sur son sous-réseau (broadcast Layer 3, broadcast Layer 2). Son message DHCP s’accompagne éventuellement de certaines options comme son dhcp-client-identifier (option 61), son vendor-class-identifier (option 60) et son client-hostname (option 12). Fournir son identifiant vendeur permet au client de recevoir éventuellement une configuration réseau sur-mesure, avec des options particulières. Par exemple, les Windows 2000 et au-delà possèdent comme vendor-class-identifier la valeur "MSFT 5.0". Les clients Windows envoient, par défaut, cet identifiant au serveur alors que les clients Linux devront être modifiés pour l’envoyer (fichier /etc/dhcp/dhclient.conf, send vendor-class-identifier "valeur-a-envoyer";).
    • IP source : 0.0.0.0
    • MAC source : MAC-client
    • IP destination : 255.255.255.255
    • MAC destination : FF:FF:FF:FF:FF:FF
  2. DHCPOFFER : Chaque serveur DHCP reçoit la requête sur son port 67 et renvoie une proposition d’IP potentielle, accompagnée de quelques paramètres de configuration et de son ID l’identifiant de manière unique (broadcast Layer 3, unicast Layer 2)
    • IP source : IP-serveur
    • MAC source : MAC-serveur
    • IP destination : 255.255.255.255 (le client n’a pas encore d’IP validée)
    • MAC destination : MAC-client
  3. DHCPREQUEST : Le client reçoit la proposition d’IP en UDP sur son port 68 et, pour confirmer qu’il valide la proposition, renvoie un message broadcasté reçu de l’ensemble des serveurs DHCP du sous-réseau (chacun ayant pu faire une proposition via DHCPOFFER) pour les informer qu’il valide la proposition du serveur dont il spécifie l’ID (broadcast Layer 3, broadcast Layer 2). Son message DHCP s’accompagne éventuellement de certaines options comme son dhcp-client-identifier (option 61), son vendor-class-identifier (option 60) et son host-name (option 12)
    • IP source : 0.0.0.0
    • MAC source : MAC-client
    • IP destination : 255.255.255.255
    • MAC destination : FF:FF:FF:FF:FF:FF
  4. DHCPACK : Le serveur enfin valide la demande du client en lui retournant l’ensemble des paramètres réseaux (IP, masque, domaine, durée du bail, etc.) en broadcast puisque le client n’a pas encore reçu cette configuration (broadcast Layer 3, broadcast Layer 2)
    • IP source : IP-serveur
    • MAC source : MAC-serveur
    • IP destination : 255.255.255.255 (le client n’a pas encore d’IP validée)
    • MAC destination : MAC-client
RENOUVELLEMENT BAIL
Serveur DHCP Communication Client DHCP

UDP 67

Unicast L3
Unicast L2

DHCPREQUEST

DHCPACK

Unicast L3
Unicast L2

UDP 68

Concernant les options des messages DHCP, se référer à la RFC 2132 :

 

Pré-requis

 

Pré-requis avant réalisation

 

  • Un serveur Debian Jessie 8.4 32 bits fonctionnel (installation basique avec utilitaires usuels du système et service SSH) qui hébergera le service DHCP primaire ou master
  • Packages de base supplémentaires : sudo, resolvconf, aptitude
  • Domaine utilisé : opensharing.priv

Rmq : Ici, même si cela ne présente absolument aucun caractère obligatoire, nous utiliserons un serveur DHCP master hébergeant également un service DNS master.
 

Installation et configuration du service NTP

Si un failover est mis en place, pour la redondance du service DHCP, il est fondamental que les deux serveurs (master et slave DHCP) soient synchronisés au niveau de l’heure. Le cas échéant, leur communication sera interrompue si le décalage est trop important.
On peut, par exemple, synchroniser le serveur master avec une source externe de temps, et le serveur slave avec le master.
 
Installation du service NTP et de l’utilitaire ntpstat :

# aptitude install ntp ntpstat

Configuration du service NTP :

# nano /etc/ntp.conf
[...]
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org
[...]
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
[...]

Rmq : Pour se référer à l’heure locale du système, sans serveurs de temps externes ou conjointement avec eux :

server 127.127.0.1                        # se réfère à l'heure locale du système (LOCL)
fudge 127.127.0.1 stratum 10              # optionnel : si des serveurs de temps externes ont été spécifiés

L’option fudge 127.127.0.1 stratum 10 signifie que si aucun serveur de temps (déconnexion par exemple) n’est joignable, alors se référer à l’heure locale.

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   50   64    1    0.000    0.000   0.000
 178.63.9.110    131.188.3.222    2 u   49   64    1   21.692  454.316   0.000
 178.63.135.195  36.224.68.195    2 u   48   64    1   20.871  469.096   0.000
 2a01:788:a000:0 193.67.79.202    2 u   47   64    1   19.804  486.637   0.000
 176.9.1.211     235.106.237.243  3 u   46   64    1   21.139  499.488   0.000

 

Activation au démarrage et relance du service NTP :

# systemctl enable ntp
# service ntp restart

Le service NTP devrait fonctionner mais, si ce n’est pas le cas, les observations qui suivent peuvent être utiles.
Le synchronisation via NTP se fait-elle ?

# ntpstat
unsynchronised
  time server re-starting
   polling server every 8 s

En effet, les serveurs NTP définis sont listés, mais aucun n’est sélectionné (une étoile devrait apparaître devant son nom) :

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 roliath.nonexis 5.45.97.110      3 u   31   64    7    6.382  -11.574  18.403
 sismox.com      45.215.33.249    3 u   23   64    7    8.887  111.760  79.564
 x.ns.gin.ntt.ne 249.224.99.213   2 u   27   64    7    6.457   41.750  30.810
 dalek.roflcopte 195.83.222.27    2 u   24   64    7    6.088   92.384  55.526

Le service NTP ne semble pas actif :

# timedatectl
[...]
     NTP enabled: no
[...]

Observation d’un message d’erreur relatif au fuseau horaire dans les logs système :

dns1-test systemd-timedated[2190]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/

Correction des anomalies constatées :

# dpkg-reconfigure tzdata     # Réinitialisation du fuseau horaire : Europe/Paris
ou
# timedatectl set-timezone Europe/Paris

# timedatectl set-ntp true    # Activation du service NTP
# service ntp restart          # Relance du service NTP

Le service NTP est activé :

# timedatectl
[...]
     NTP enabled: yes
[...]

Attente de 6 minutes pour que le serveur NTP soit défini :

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+roliath.nonexis 5.45.97.110      3 u   45   64  377    5.654  128.954  95.795
xsismox.com      45.215.33.249    3 u   21   64  377    9.615    1.454 322.398
+x.ns.gin.ntt.ne 249.224.99.213   2 u   39   64  377    7.172  215.463 119.756
*dalek.roflcopte 195.83.222.27    2 u   42   64  377    5.733  174.681  44.489

Mais la synchronisation n’est pas encore active :

# ntpstat
unsynchronised
   polling server every 64 s

Elle peut nécessiter plusieurs minutes, au bout desquelles on observe la synchronisation effective :

# ntpstat
synchronised to NTP server (37.187.7.160) at stratum 3
   time correct to within 607 ms
   polling server every 64 s

 

Configuration réseau initiale

 

Serveur DHCP Master
FQDN dns1-test.opensharing.priv
Adresse IP 192.168.1.11
Réseau 192.168.1.0/24
Passerelle 192.168.1.1
dns-nameservers 127.0.0.1
dns-search opensharing.priv

 

Contenu initial du fichier /etc/network/interfaces :

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
	address 192.168.1.11
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	gateway 192.168.1.1
	dns-search opensharing.priv
	dns-nameservers 127.0.0.1

 

Contenu initial du fichier /etc/hosts :

127.0.0.1	localhost.localdomain	localhost
192.168.1.11	dns1-test.opensharing.priv	dns1-test

Rmq : L’adresse 127.0.1.1 doit être retirée sur un serveur à IP fixe et remplacée par cette dernière, tel que l’exemple ci-dessus.
 
Contenu initial du fichier /etc/host.conf :

order hosts, bind
multi on

 

Contenu initial du fichier /etc/resolv.conf :

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search opensharing.priv

Rmq :
Le fichier /etc/resolv.conf ne doit pas être édité dès lors que le paquet resolvconf a été installé.

Extrait des enregistrements de la zone DNS opensharing.priv sur le DNS master (lui-même) :

# cat /var/cache/bind/db.opensharing.priv
[...]
dns1-test	IN	A	192.168.1.11
dns1		IN	CNAME	dns1-test
dhcp1		IN	CNAME	dns1-test
[...]

 

Réalisation

 

0. Mise à jour préalable du système et des paquets installés

# aptitude update
# aptitude upgrade

 

1. Installation du serveur DHCP

# aptitude install isc-dhcp-server

L’installation du service ISC DHCP génère son fichier de configuration dhcpd.conf dans le répertoire /etc/dhcp/ :

# tree /etc/dhcp/
/etc/dhcp/
├── dhclient.conf
├── dhclient-enter-hooks.d
│   ├── debug
│   └── resolvconf
├── dhclient-exit-hooks.d
│   ├── debug
│   ├── ntpdate
│   └── rfc3442-classless-routes
└── dhcpd.conf

Rmq : La commande tree nécessite l’installation du paquet tree.
 

Contenu par défaut du fichier /etc/dhcp/dhcpd.conf (options globales, hors commentaires et lignes vides)

# grep -v -E "^#|^$" /etc/dhcp/dhcpd.conf
ddns-update-style none;                                             1
option domain-name "example.org";                                   2
option domain-name-servers ns1.example.org, ns2.example.org;        3
default-lease-time 600;                                             4
max-lease-time 7200;                                                5
log-facility local7;                                                6

1 ddns-update-style none
Indique si le serveur DHCP doit mettre à jour dynamiquement les enregistrements du serveur DNS lorsqu’un bail est validé ou révoqué. Valeurs possibles : ad-hoc, interim, standard et none.
2 option domain-name "example.org"
Indique le domaine qui sera attribué aux clients
3 option domain-name-servers ns1.example.org, ns2.example.org
Indique les serveurs DNS qui seront attribués aux clients
4 default-lease-time 600
Durée minimale d’un bail : ici 10 minutes (600 secondes) par défaut
5 max-lease-time 7200
Durée maximale d’un bail (après plusieurs renouvellement jusqu’à cette valeur) : ici 2h (7200 secondes) par défaut
6 log-facility local7
Niveau de logs maximal. Tout sera notifié dans /var/log/syslog
 

Modification du fichier de configuration /etc/dhcp/dhcpd.conf

On peut, avant d’aller plus loin dans la configuration du serveur DHCP, adapter les options globales à nos besoins.

ddns-update-style standard;
option domain-name "opensharing.priv";
option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

 

2. Configuration du serveur DHCP

 

Synthétisons les informations que devront recevoir les clients DHCP

  • Le domaine de recherche opensharing.priv
  • Une adresse IP dans la gamme 192.168.1.100 à 192.168.1.199 pour les postes client (pas de réservation DHCP)
  • Une adresse IP fixe à partir de 192.168.1.200 pour les imprimantes (réservation DHCP)
  • Un bail de 10 minutes, extensible jusqu’à 2h
  • La passerelle 192.168.1.1
  • Les serveurs de noms dns1.opensharing.priv et dns2.opensharing.priv

 

Ajout d’options globales nécessaires à la configuration temporaire du serveur DHCP

authoritative;                                                                                      1
ddns-update-style standard;
update-static-leases off;                                                                           2
option domain-name "opensharing.priv";                                                              3
option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;                            4
ignore client-updates;                                                                              5
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
failover {}                                                                                         6
subnet {}                                                                                           7

1 authoritative
Le serveur fait autorité pour délivrer des adresses IP pour l’ensemble des réseaux spécifiés par la suite.
2 update-static-leases off
Désactive la mise à jour DNS pour les enregistrements ayant une IP fixe, c’est à dire les réservations DHCP.
Ces enregistrements doivent être ajoutés manuellement ou via nsupdate si les mises à jour dynamiques DNS sont actives globalement.
3 option domain-name "opensharing.priv"
Désigne le domaine par défaut qui sera attribué aux clients.
Nous le retirons globalement pour le déplacer au niveau sous-réseau.
4 option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv
Désigne les serveurs de noms par défaut qui seront attribués aux clients
Nous le retirons globalement pour le déplacer au niveau sous-réseau.
5 ignore client-updates
Seul le serveur DHCP est autorisé à mettre à jour les enregistrements DNS.
Il ajoutera un enregistrement de type A et un enregistrement de type PTR en concaténant le nom d’hôte fourni par le client et le domaine défini par le paramètre option domain-name.
6 failover {}
On déclare une redondance, pour le moment vide, elle sera remplie par la suite.
7 subnet {}
On déclare un sous-réseau vide, il sera rempli par la suite
 

Ajout d’une définition de failover pour la redondance dans le service DHCP

failover peer "opensharing-failover" {                                                              1
        primary;                                                                                    2
        address 192.168.1.11;                                                                       3
        port 647;                                                                                   4
        peer address 192.168.1.12;                                                                  5
        peer port 647;                                                                              6
        max-response-delay 30;                                                                      7
        max-unacked-updates 10;                                                                     8
        load balance max seconds 3;                                                                 9
        mclt 1800;                                                                                  10
        split 128;                                                                                  11
}

1 failover peer "opensharing-failover"
Nom arbitraire donné à la définition du failover.
Le même nom devra être utilisé pour le serveur DHCP slave.
Ce nom sera également utilisé dans chaque déclaration pool nécessitant une redondance.
2 primary
Ce serveur est désigné comme master.
3 address 192.168.1.11
L’adresse IP du serveur maître.
4 port 647
Port d’écoute du serveur maître pour le DHCP-Failover.
5 peer address 192.168.1.12
Adresse IP du partenaire, le serveur DHCP slave, assurant la redondance du service DHCP.
6 peer port 647
Port d’écoute du serveur esclave pour le DHCP-Failover.
7 max-response-delay 30
Temps en secondes au bout duquel si un des serveurs ne reçoit pas de réponses de son partenaire la connexion sera considérée comme interrompue.
8 max-unacked-updates 10
Nombre maximal de messages BNDUPD (un bail a été attribué et doit être synchronisé avec le partenaire) que peut envoyer un des serveurs DHCP sans recevoir d’acquittement BNDACK (accusé de réception du bail attribué) de son partenaire. Si ce nombre est dépassé, le partenaire à l’initiative des messages BNDUPD considère la connexion interrompue.
9 load balance max seconds 3
Temps au bout duquel, si un client ne reçoit pas de réponse à son message de type DHCPDISCOVER ou DHCPREQUEST par un serveur DHCP, le serveur partenaire prend le relai et traite la demande de ce client.
10 mclt 1800
Temps pendant lequel, suite à la défaillance d’un des serveurs DHCP, son partenaire assure seul le rôle de serveur DHCP (délégation temporaire).
 

Ajout d’une définition de sous-réseau centralisant les informations envoyées aux clients DHCP

subnet 192.168.1.0 netmask 255.255.255.0 {                                                          1
	option subnet-mask 255.255.255.0;                                                           2
	option routers 192.168.1.1;                                                                 3
	ddns-domainname "opensharing.priv";                                                         4
	ddns-rev-domainname "in-addr.arpa";                                                         5
	option domain-name "opensharing.priv";                                                      6
	option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;                    7
	pool {
                failover peer "opensharing-failover";                                               8
		range 192.168.1.100 192.168.1.199;                                                  9
		allow unknown-clients;                                                              10
	}
	
	group {
		use-host-decl-names true;                                                           11
		host printer1 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.200; } 12
		host printer2 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.201; }
	}
}

1 subnet 192.168.1.0 netmask 255.255.255.0
Initie la définition d’un sous-réseau en spécifiant son IP et son masque.
2 option subnet-mask 255.255.255.0
Désigne le masque de sous-réseau qui sera attribué aux clients DHCP.
3 option routers 192.168.1.1
Désigne la passerelle qui sera attribuée aux clients DHCP.
4 ddns-domainname "opensharing.priv"
Spécifie la zone de recherche directe où devront être enregistrés les FQDN des clients DHCP de ce sous-réseau dans le cadre de la mise à jour dynamique du DNS.
5 ddns-rev-domainname "in-addr.arpa"
Spécifie la zone de recherche inversée où devront être enregistrés les FQDN des clients DHCP de ce sous-réseau dans le cadre de la mise à jour dynamique du DNS. En fait, ce suffixe sera concaténé à l’adresse IP inversée affectée au client. Par exemple, pour un client d’IP 192.168.1.150, le bail produira la valeur :

set ddns-rev-name = "150.1.168.192.in-addr.arpa";

Donc, si nous choisissons intuitivement une valeur ddns-domainname "1.168.192.in-addr.arpa", nous obtiendrons un enregistrement PTR erroné :

set ddns-rev-name = "150.1.168.192.1.168.192.in-addr.arpa";

6 option domain-name "opensharing.priv"
Désigne le domaine qui sera attribué aux clients DHCP.
7 option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv
Désigne les serveurs de noms qui seront attribués aux clients DHCP.
8 failover peer "opensharing-failover"
Spécifie le nom du failover défini dans la configuration DHCP qui sera utilisé pour ce pool.
Le nom du failover doit être le même que celui qui a été défini au préalable.
9 range 192.168.1.100 192.168.1.199
Spécifie l’intervalle d’adresses IP qui pourront être affectées lors de la génération d’un bail à un client DHCP.
10 allow unknown-clients
Autorise les clients non connus à se voir attribuer une IP de l’intervalle spécifié.
Un client non connu ne possède pas d’enregistrement de type host dans la configuration DHCP.
11 use-host-decl-names true
Si activé, ce paramètre signifie aux clients DHCP possédant un enregistrement de type host dans la configuration DHCP, que le nom spécifié lui sera affecté (ex : host john-doe)
Toutefois, la majorité des clients DHCP ignorent ce paramètre et gardent leur nom d’hôte propre.
11 host printer1 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.200; }
Déclare un hôte de nom arbitrairement choisi et identifié par son adresse unique MAC se voyant attribuer une IP fixe (réservation DHCP).
 

Paramétrage de la mise à jour dynamique du DNS

include "/etc/bind/tsig.key";

zone opensharing.priv {
	primary 192.168.1.11;
	key "tsig-key";
}

zone 1.168.192.in-addr.arpa. {
	primary 192.168.1.11;
	key "tsig-key";
}

On inclut la clef TSIG mise en place pour la mise à jour dynamique du DNS.
Voir l’article ISC Bind9 – Serveur DNS primaire, à la section Pour aller plus loin, pour savoir comment générer cette clef.
Chaque zone à mettre à jour dynamiquement a été définie et déclarée sur le serveur DNS master. L’adresse IP de ce dernier est précisée tout comme la clef TSIG qui a été déclarée dans la configuration du serveur DNS pour chaque zone au paramètre allow-update.
 

Fichier dhcpd.conf final

include "/etc/bind/tsig.key";

authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;

failover peer "opensharing-failover" {
        primary;
        address 192.168.1.11;
        port 647;
        peer address 192.168.1.12;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 192.168.1.1;
	ddns-domainname "opensharing.priv";
	ddns-rev-domainname "in-addr.arpa";
	option domain-name "opensharing.priv";
	option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
	pool {
                failover peer "opensharing-failover";
		range 192.168.1.100 192.168.1.199;
		allow unknown-clients;
	}
	
	group {
		use-host-decl-names true;
		host printer1 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.200; }
		host printer2 { hardware ethernet 01:23:45:00:00:01; fixed-address 192.168.1.201; }
	}
}

zone opensharing.priv {
	primary 192.168.1.11;
	key "tsig-key";
}

zone 1.168.192.in-addr.arpa. {
	primary 192.168.1.11;
	key "tsig-key";
}

 

Fichier /etc/default/isc-dhcp-server modifié

INTERFACES="eth0"

 

Pour aller plus loin

 

Visualiser les baux attribués

Les baux générés et attribués aux clients DHCP sont centralisés dans un fichier unique : /var/lib/dhcp/dhcpd.leases
S’il existe un failover, les fichiers sont (quasi-)identiques pour ce qui est des IP relatives au pool concerné. En effet, après chaque bail attribué par l’un des partenaires, le deux serveurs se synchronisent pour posséder une base de données identique.

Exemple de bail attribué :

lease 192.168.1.149 {
  starts epoch 1471265185; # Mon Aug 15 14:46:25 2016
  ends epoch 1471265785; # Mon Aug 15 14:56:25 2016
  tstp epoch 1471266085; # Mon Aug 15 15:01:25 2016
  tsfp epoch 1471266085; # Mon Aug 15 15:01:25 2016
  atsfp epoch 1471266085; # Mon Aug 15 15:01:25 2016
  cltt epoch 1471265185; # Mon Aug 15 14:46:25 2016
  binding state active;
  next binding state expired;
  hardware ethernet 00:11:43:a2:d7:aa;
  uid "\001\000\021C\242\327\252";
  set ddns-rev-name = "149.1.168.192.in-addr.arpa";
  set ddns-dhcid = "\000\001\001_\013dR\237\271\306\"\260\210P#\005\352Wv\276\303\3371Z\010\342yr}\206\311\321\303\242j";
  set ddns-fwd-name = "xptest.opensharing.priv";
  client-hostname "xptest";
}

On trouve dans ce bail :

  • durée du bail : 10 minutes (delta starts et ends)
  • l’état du bail : active
  • son prochain état à la fin du bail (ends) : expired
  • l’adresse MAC du client
  • l’identifiant unique du client (uid)
  • les informations générées par le serveur pour la mise à jour dynamique du DNS

Ici, c’est un bail attribué par le slave car cette IP relève de sa charge en terme de load-balancing. Le master possède les mêmes informations, mais un peu moins détaillées :

lease 192.168.1.149 {
  starts epoch 1471265185; # Mon Aug 15 14:46:25 2016
  ends epoch 1471265785; # Mon Aug 15 14:56:25 2016
  tstp epoch 1471262212; # Mon Aug 15 13:56:52 2016
  tsfp epoch 1471266085; # Mon Aug 15 15:01:25 2016
  atsfp epoch 1471266085; # Mon Aug 15 15:01:25 2016
  binding state active;
  next binding state expired;
  hardware ethernet 00:11:43:a2:d7:aa;
  uid "\001\000\021C\242\327\252";
}

En effet, les informations relatives à la mise à jour dynamique du DNS pour ce client (ddns-rev-name, ddns-dhcid et ddns-fwd-name) sont générées par le serveur qui en a la charge. Ces informations sont transmises au serveur primaire pour les zones déclarées (déclarations de type zone) et ce dernier se charge de créer les enregistrements correspondants, dans la zone directe et la zone inverse.
Rmq : Le mot epoch que l’on trouve pour les heures de début et de fin de bail correspond à une heure locale du système (ex : UTC + 0200) (paramètre db-time-format local). Son absence correspond à un réglage en UTC (paramètre db-time-format default).
 


 

Monitorer les baux attribués

Pour visualiser les baux actifs, et les IP libres, plusieurs possibilités :

Consulter le fichier source

Comme nous l’avons vu, le meilleur moyen reste de consulter le fichier source où les baux sont centralisés : /var/lib/dhcp/dhcpd.leases
La contrepartie est que les données sont ajoutées séquentiellement, qu’elles ne sont pas forcément très lisibles et qu’il faut fouiller un peu.
Par contre, les données que l’on y trouve sont fiables.
 
dhcp2
dhcp1
L’heure est ici en UTC.

Utiliser la commande dhcp-lease-list

Pour une explication de son utilisation, suivre le lien suivant : dhcp-lease-list
Le retour est structuré sous forme d’un tableau des baux actifs, donc on va à l’essentiel et la commande présente l’avantage d’être installée avec le paquet isc-dhcp-server.
Toutefois, après plusieurs tests, des retours incohérents ont parfois été constatés : bail absent ou incomplet, adresse MAC tronquée sur un terminal de plus de 78 caractères de large, des baux non actualisés, etc. Les tests ont été effectués sur le terminal d’un serveur graphique, certains bugs d’affichage y sont peut-être liés.
 
dhcp11
L’heure est ici en UTC.

Utiliser la commande dhcpstatus

Pour une explication de son utilisation, suivre le lien suivant : dhcpstatus
Les données seront structurées et complètes, fiables et sans doublons, sous forme d’un listing synthétique.
Il est possible de visualiser les baux en ligne de commande, ou en version HTML via le navigateur.
Inconvénient, il faut installer l’utilitaire à la main et procéder à de légères modifications.
Pour la visualisation HTML, il faudra installer un service http comme Apache2.
La commande dhcpstatus fonctionnera uniquement si l’heure des baux est en UTC, donc le paramètre db-time-format doit être à default.
Toutefois, l’affichage se fera avec l’heure locale du système.
 
dhcp3
dhcp4
dhcp5
dhcp6
 
Si les clients ne sont pas synchronisés au niveau du temps avec les serveurs DHCP, on observe un léger décalage dans l’heure des baux :
 
dhcp7
dhcp8
 


 

Aller encore plus loin

Pour continuer à explorer la configuration de ISC DHCP, voir les articles suivants :

 

Annexes

PAPLxx : fait référence à un sujet développé dans la section Pour aller plus loin

 

Références

 

Fermer le menu
%d blogueurs aiment cette page :