aptitude install isc-dhcp-server

Fichiers :

• /etc/dhcp/dhcpd.conf : fichier de configuration
• /var/lib/dhcpd/dhcpd.leases : fichier des concessions = base des attributions d'IPs ; ne pas modifier à la main
• /usr/share/doc/dhcp*/dhcpd.conf.sample : exemple de fichier de configuration

Exemple de configuration simple (/etc/dhcp/dhcpd.conf): pour un serveur desservant le service DHCP sur 3 interfaces (disons eth0, eth1 et eth2) :

# option globales s'appliquant par défaut à tous les subnets
option domain-name "lan";
option domain-name-servers 10.1.2.108, 10.1.2.24;
option netbios-name-servers 10.1.2.250, 10.1.2.251;
option ntp-servers 10.1.2.100;
default-lease-time 86400;
max-lease-time 86400;
log-facility local7;
 
# eth0
subnet 10.0.0.0 netmask 255.255.255.0 {
   range 10.0.0.1 10.0.0.10;    # range est utiliser pour déclarer des plages adressées dynamiquement
   range 10.0.0.20 10.0.0.29;   # on peut attribuer différentes plages d'IP dans un subnet
   option routers 10.0.0.254; 
}
 
# eth1 ; ce réseau est découpé en plusieurs pools
subnet 10.1.0.0 netmask 255.255.255.0 {
   # pool default
   pool {
      range 10.1.0.1 10.1.0.100;
      # on interdit les PC dont l'adresse MAC n'est pas renseignée dans une directive "host"
      deny unknown-clients;
      }
 
   # pool masterisation de PCs
   pool {
      range dynamic-bootp 10.1.0.101 10.1.0.150;
      allow unknown-clients;
      max-lease-time 7200; # 2h
      }
 
   option routers 10.1.0.254;
   option subnet-mask 255.255.255.0;
   option broadcast-address 10.1.0.255;
   option domain-name "lan-tech";
   }
 
# eth2
subnet 10.2.0.0 netmask 255.255.255.0 {
  option domain-name "lan-srv";
  range 10.2.0.1 10.2.0.200;
  option routers 10.2.0.254;
}

Pour réserver une IP à un PC (on parle d'adressage DHCP statique) on l'associe à son adresse MAC (pour être propre on le déclarera dans un fichier dédié, /etc/dhcp/hosts-lan.conf par exemple) :

# liste des réservations d'IPs
host pc-patron {
   hardware ethernet 00:01:02:03:04:05;
   fixed-address 10.1.0.1;
   option host-name "pc-patron";
}
# on utilise un group pour mutualiser les options
group {
   # permet d'utiliser le nom des hosts comme "option host-name"
   # ce qui nous évite de les préciser en double pour chaque host !
   use-host-decl-names on;
 
   host pc-grouillot1 { hardware ethernet 00:00:00:00:00:01; fixed-address 10.1.0.101; }
   host pc-grouillot2 { hardware ethernet 00:00:00:00:00:02; fixed-address 10.1.0.102; }
   }

Pour les clients bootp, il faut en plus spécifier au moins le fichier de boot :

host pc-techos {
   hardware ethernet 00:00:00:00:00:02;
   fixed-address 10.1.0.102;
   filename "pxelinux.0";
   next-server 10.1.0.2;
}

Ne pas oublier d'inclure ce fichier dans la conf

# à ajouter dans dhcp.conf
include "/etc/dhcp/hosts-lan.conf";

Pour desservir des réseaux qui ne sont pas directement connectés au serveur DHCP, on utilisera le DHCP Relay. Cela fonctionne ainsi :

• quelque part un client broadcaste un DHCPDISCOVER
• une bonne âme (un routeur par exemple) branchée sur ce réseau, est configurée pour relayer cette requête vers notre serveur : c'est un “DHCP relay”, ou “IP helper”. Son rôle consiste à convertir la requête broadcastée en un paquet unicast, et de le router vers le serveur DHCP. Ce paquet unicast sera envoyé avec l'IP du routeur comme GIADDR, permettant au serveur DHCP d'identifier le réseau du client, et contiendra toutes les infos du client (notamment son adresse MAC, dans le champs CHADDR).
• le serveur DHCP reçoit le DHCPDISCOVER “via” une de ces interfaces, et traite la transaction comme normalement, mais en envoyant ses réponses au routeur.

Exemple de cas pratique :

client <----10.0.0.0/24----> (10.0.0.1) routeur (192.168.0.1/24) <---> serveur DHCP (192.168.0.2/24 sur eth0)

Le routeur devra être configuré pour relayer les requêtes DHCP reçues sur le réseau 10.0.0.0/24 à destination du serveur DHCP 192.168.0.2.

Exemple de configuration du serveur DHCP :

[..]
# eth0
# ici, le serveur n'attribue aucune IP sur le réseau 192.168.0.0/24
# qui ne sert que de transit pour recevoir les requêtes relayées
shared-network {
   subnet 192.168.0.0 netmask 255.255.255.0 {
   }
   subnet 10.0.0.0 netmask 255.255.255.0 {
      option subnet-mask 255.255.255.0;
      option broadcast-address 10.0.0.255;
      option routers 10.0.0.1;
      option domain-name "remote-network.example";
      range 10.0.0.2 10.0.0.100;
   }
}

Ce que je veux faire :

• un concentrateur VPN sur un firewall Fortigate
• des clients qui établisse des VPN IPSec “dialup” avec un Forticlient
• ces derniers reçoivent leurs IP en DHCP depuis le serveur DHCP centralisé
• seuls les clients connus = déclarés sur le serveur DHCP reçoivent leurs propres IPs (réservées = adressage DHCP statique)

Pour avoir passé un peu de temps à comprendre pourquoi ça ne marche pas, il faut savoir que le type de hardware envoyé dans la requête DHCP relayée n'est pas “ethernet” mais “unknown-31” (en tout cas avec un client VPN Forticlient v5.6.0 !). ne sont pas de type “hardware ethernet”. Donc si on veut faire de l'adressage statique et interdire les clients inconnus :

subnet forticlient [...] {
   # interdire les clients inconnus
   deny unknown-clients;
}
 
# pas bien : (vos clients seront traités comme "unknown client" = pas d'IP pour eux ;
# voir même "no free leases" car aucune directive "range" n'est présente !)
host toto { hardware ethernet 00:11:22:33:44:55; fixed-address 10.0.0.1; }
# bien :
host toto { hardware unknown-31 00:11:22:33:44:55; fixed-address 10.0.0.1; }

Pour s'assurer du type de hardware d'un client, supprimer “deny unknown-clients;”, ajouter un “range” d'IP à attribuer aux clients inconnus, se connecter avec le client, et (enfin) regarder dans le fichier /var/lib/dhcpd/dhcpd.leases le type de hardware de notre client (on le retrouve avec son adresse MAC ou IP).

Exemple de configuration failover :

# sur le primaire dhcp1.local
failover peer "failover-partner" {
   primary;
   address dhcp1.local;
   port 519;
   peer address dhcp2.local;
   peer port 520;
   max‐response‐delay 60;
   max‐unacked‐updates 10;
   mclt 3600;
   split 128;
   load balance max seconds 3;
}
 
# sur le secondaire dhcp2.local
failover peer "failover-partner" {
   secondary;
   address dhcp2.local;
   port 520;
   peer address dhcp1.local;
   peer port 519;
   max‐response‐delay 60;
   max‐unacked‐updates 10;
   load balance max seconds 3;
}
 
 
# Pour chaque range, il faut l'inclure dans un paragraphe "pool"
# et ajouter une référence au failover
[..]
   pool {
       failover peer "failover-partner";
       range 10.2.0.1 10.2.0.200;
       [..]
   }

Pour prendre en compte le PXE avec des machines UEFI : on doit utiliser des fichiers différents en fonction de l'architecture (ia32 et x64) :

# Definition of PXE-specific options
# Code 1: Multicast IP address of bootfile
# Code 2: UDP port that client should monitor for MTFTP responses
# Code 3: UDP port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of secondes a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of secondes a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
 option PXE.mtftp-ip    code 1 = ip-address;
 option PXE.mtftp-cport code 2 = unsigned integer 16;
 option PXE.mtftp-sport code 3 = unsigned integer 16;
 option PXE.mtftp-tmout code 4 = unsigned integer 8;
 option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16; # RFC4578
#
# [..]
class "pxeclients" {
   match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
   next-server 10.1.0.2;
   # 6    EFI IA32
   #<-> match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
   if option arch = 00:06 {
      filename "uefi/bootia32.efi";
   # 7    EFI BC (EFI Byte Code)
   } else if option arch = 00:07 {
      filename "uefi/bootx64.efi";
   # Défaut (cas des machines avec BIOS classiques)
   } else {
      filename "pxelinux.0";
   }
}

# tester le fichier de configuration par défaut (/etc/dhcp/dhcpd.conf) sans relancer le service :
dhcpd -t
 
# tester le fichier de configuration spécifié :
dhcpd -t -cf /etc/dhcpd/dhcpd-perso.conf

Dans le cas d'une transaction comme celle-ci (vu dans le fichier de log du serveur DHCP) :

Feb 20 16:06:11 srv1 dhcpd: DHCPDISCOVER from 90:b1:1c:00:00:01 via eth0
Feb 20 16:06:11 srv1 dhcpd: DHCPOFFER on 10.40.2.173 to 90:b1:1c:00:00:01 via eth0
Feb 20 16:06:11 srv1 dhcpd: DHCPREQUEST for 10.40.22.67 (10.40.0.79) from 90:b1:1c:00:00:01 via eth0: lease 10.40.22.67 unavailable.
Feb 20 16:06:11 srv1 dhcpd: DHCPNAK on 10.40.22.67 to 90:b1:1c:00:00:01 via eth0
Feb 20 16:06:14 srv1 dhcpd: DHCPACK to 10.40.22.67 (90:b1:1c:00:00:01) via eth0

On voit que le client demande une IP, le serveur lui en propose une (10.40.2.173), mais le client “désobéit” et continue d'utiliser 10.40.22.67 alors qu'on le lui a interdit (DHCPNAK). C'est le cas typique d'un autre serveur DHCP (rogue DHCPd) sur le réseau qui, lui, valide cette IP-là.

Si un client choisi bien une offre mais fini par la décliner (DHCPDISCOVER-DHCPOFFER-DHCPREQUEST-DHCPACK puis DHCPDECLINE) :

Oct 4 14:50:59 monserveur dhcpd: DHCPDECLINE of 10.40.0.12 from 10:65:30:00:11:22 via eth0: not found

.. cela peut être dû à une autre machine qui utilise déjà cette adresse sur le réseau. En effet, avant d'utiliser l'IP demandée au serveur, la plupart des clients DHCP pinguent cette adresse pour vérifier si elle n'est pas déjà utilisée. Si tel est le cas, ce dernier déclinera au final la proposition.