Differences

This shows you the differences between two versions of the page.

--- informatique:logiciels:dhcpd [2016/10/11 14:18] – Diagnostique pteu
+++ informatique:logiciels:dhcpd [2019/12/02 09:23] (current) – [Boot BIOS vs UEFI] pteu
@@ Line 1: / Line 1: @@
-Installation :
+=====Installation=====
 <code bash>
 aptitude install isc-dhcp-server
@@ Line 9: / Line 11: @@
   * ''/usr/share/doc/dhcp*/dhcpd.conf.sample'' : exemple de fichier de configuration
-Exemple de configuration simple (''/etc/dhcp/dhcpd.conf''):
+=====Configuration simple=====
+Exemple de configuration simple (''/etc/dhcp/dhcpd.conf''): pour un serveur desservant le service DHCP sur 3 interfaces (disons eth0, eth1 et eth2) :
 <code bash>
 # option globales s'appliquant par défaut à tous les subnets
@@ Line 19: / Line 24: @@
 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 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;
 }
-# ce réseau est découper en plusieurs pools, par fonction
+# eth1 ; ce réseau est découpé en plusieurs pools
 subnet 10.1.0.0 netmask 255.255.255.0 {
    # pool default
-   range 10.1.0.1 10.1.0.100;
+   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
-   range dynamic-bootp 10.1.0.101 10.1.0.150;
+   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;
@@ Line 40: / Line 54: @@
    }
+# eth2
 subnet 10.2.0.0 netmask 255.255.255.0 {
   option domain-name "lan-srv";
@@ Line 47: / Line 62: @@
 </code>
-Pour réserver une IP à un PC, 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) :
+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) :
 <code bash>
 # liste des réservations d'IPs
@@ Line 53: / Line 68: @@
    hardware ethernet 00:01:02:03:04:05;
    fixed-address 10.1.0.1;
+   option host-name "pc-patron";
 }
-host pc-grouillot {
+# on utilise un group pour mutualiser les options
-   hardware ethernet 00:00:00:00:00:01;
+group {
-   fixed-address 10.1.0.101;
+   # 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; }
+   }
 </code>
@@ Line 75: / Line 96: @@
 include "/etc/dhcp/hosts-lan.conf";
 </code>
+=====Diverses options=====
+=====DHCP relay=====
+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 :
+<code>
+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)
+</code>
+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 :
+<code bash>
+[..]
+# 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;
+   }
+}
+</code>
+=====DHCP Forticlient=====
+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 :
+<code bash>
+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; }
+</code>
+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).
+=====Failover=====
 Exemple de configuration failover :
@@ Line 115: / Line 200: @@
 </code>
+=====Boot BIOS vs UEFI=====
-=====Diagnostique====
+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) :
+<code bash>
+# 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";
+   }
+}
+</code>
+======Diagnostic=====
 <code bash>
@@ Line 125: / Line 246: @@
 dhcpd -t -cf /etc/dhcpd/dhcpd-perso.conf
 </code>
+====Client désobéissant====
+Dans le cas d'une transaction comme celle-ci (vu dans le fichier de log du serveur DHCP) :
+<code bash>
+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
+</code>
+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à.
+====Client poli====
+Si un client choisi bien une offre mais fini par la décliner (''DHCPDISCOVER-DHCPOFFER-DHCPREQUEST-DHCPACK'' puis ''DHCPDECLINE'') :
+<code bash>
+Oct 4 14:50:59 monserveur dhcpd: DHCPDECLINE of 10.40.0.12 from 10:65:30:00:11:22 via eth0: not found
+</code>
+.. 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.