Erreur lors d'attribution d'addresse statique via DHCP

Support Debian
,
Tags: #<Tag:0x00007fc9f139f860> #<Tag:0x00007fc9f139f568>
#1

Bonjour,

J’ai depuis hier des problèmes avec mon serveur DHCP, celui-ci n’arrive plus à attribuer une adresse IP à l’un de mes clients.

Pour information, voici le fichier de configuration du serveur :

# DHCPD Configuration file
authoritative;
deny duplicates;
deny unknown-clients;
ddns-update-style interim;
ddns-updates off;
ignore client-updates;
update-static-leases on;
option arch code 93 = unsigned integer 16;

subnet 192.168.1.0 netmask 255.255.255.0 {
	range 192.168.1.16 192.168.1.254;
	option subnet-mask 255.255.255.0;
	option broadcast-address 192.168.1.255;
	option routers 192.168.1.1;
	option domain-name "domaine.lan";
	option domain-name-servers 192.168.1.1;
	option netbios-node-type 8;
	option netbios-name-servers 192.168.1.1;
	option ntp-servers 192.168.1.1;
	option tftp-server-name "192.168.1.1";
	option root-path "/srv/tftp/";
	next-server 192.168.1.1;

	if option arch = 00:06 {
		filename "efi32/syslinux.efi";
	} else if option arch = 00:07 {
		filename "efi64/syslinux.efi";
	} else if option arch = 00:09 {
		filename "efi64/syslinux.efi";
	} else {
		filename "bios/pxelinux.0";
	}
}

# Premier client
host client1-eth0 {
	hardware ethernet 00:11:22:33:44:55;
	fixed-address 192.168.1.16;
	option host-name "client1";
}
host client1-wlan0 {
	hardware ethernet 11:22:33:44:55:66;
	fixed-address 192.168.1.16;
	option host-name "client1";
}
# Second client
host client2-eth0 {
	hardware ethernet 22:33:44:55:66:77;
	fixed-address 192.168.1.17;
	option host-name "client2";
}
host client2-wlan0 {
	hardware ethernet 33:44:55:66:77:88;
	fixed-address 192.168.1.17;
	option host-name "client2";
}
…

Quand le client à problème essaye d’obtenir une adresse IP, j’ai le message suivant dans les journaux :

130046:Nov 24 06:49:43 serveur dhcpd[102383]: Dynamic and static leases present for 192.168.1.18.
130047:Nov 24 06:49:43 serveur dhcpd[102383]: Remove host declaration client3-wlan0 or remove 192.168.1.18
130048:Nov 24 06:49:43 serveur dhcpd[102383]: from the dynamic address pool for 192.168.1.0/24

J’ai essayé de commenter la directive « deny unknown-clients » ainsi que la section concernant l’attribution d’IP statique pour ce client, cependant, j’obtient alors le message suivant dans les journaux :

reuse_lease: lease age 2804 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.18

J’ai également essayé de couper le serveur DHCP, supprimer les fichiers de leases et de le relancer, même problème, idem en démarrant le client à problème via un live USB, au cas où le problème viendrait de son SE.

Si quelqu’un à une idée du souci, je suis preneur, la configuration n’a pas changé depuis un moment.

De même, comme vous l’avez remarqué, j’ai des clients avec des interfaces ethernet et wifi, si quelqu’un a une manière plus élégante que la mienne de leur donner la même IP statique, ça m’intéresse.

#2

L’ip est pas déjà présente dans les leases déjà attribué ? si oui de combien est le temps d’attente avant sa purge ? et si tu le retire manuellement ça marche ?

#3

D’après le fichiers de lease, qui contient bien les IP des interfaces ethernet et WiFi du client à problème le bail est de 12 heures :

$ cat /var/lib/dhcp/dhcpd.leases
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.4.1

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\001+\021\351\345\2524\305\241$\206";

lease 192.168.1.18 {
    starts 4 2022/11/24 08:38:01;
    ends 4 2022/11/24 20:38:01;
    cltt 4 2022/11/24 08:38:01;
    binding state active;
    next binding state free;
    rewind binding state free;
    hardware ethernet 44:55:66:77:88:99;
    uid "\001\010&\2568\0263";
    client-hostname "client3";
}
lease 192.168.1.18 {
    starts 4 2022/11/24 08:40:27;
    ends 4 2022/11/24 20:40:27;
    cltt 4 2022/11/24 08:40:27;
    binding state active;
    next binding state free;
    rewind binding state free;
    hardware ethernet 55:66:77:88:99:00;
    uid "\001\250\223J\234.M";
    client-hostname "client3";
}

J’ai déjà essayé de supprimer les fichiers de « leases » du client ET du serveur (arrêt de DHCPD pour le serveur et NetworkManager pour le client, suppression de leurs fichiers de « leases », relance de DHCPD/NetworkManager), mais ça n’a rien donné de mieux.

#4

Les réservations d’adresses fixes doivent être définies en dehors des plages dynamiques.
Or 192.168.1.16, 192.168.1.17 et 192.168.1.18 appartiennent à la plage 192.168.1.16-192.168.1.254.

#5

En faisant des recherches j’avais trouvé cette réponse, or, étant donné que je ne veux pas d’adresses dynamique il faudrait que je supprime la ligne suivante ?

range 192.168.1.16 192.168.1.254;

J’ai toujours pensé que « range » définissait les adresses que DHCPD pouvait attribuer, dynamiquement ou non, ceci dit, je traîne à peu de chose près le même fichier de configuration depuis… Debian 4 ? Ça a sans doute changé depuis.

J’ai tenté de commenter la directive « range », mais après relance de DHCPD, le client tourne en boucle à essayer d’obtenir une adresse :

709:Nov 24 13:47:39 serveur dhcpd[494491]: DHCPDISCOVER from 44:55:66:77:88:99 via br0
710:Nov 24 13:47:39 serveur dhcpd[494491]: DHCPOFFER on 192.168.1.18 to 44:55:66:77:88:99 via br0
711:Nov 24 13:47:39 serveur dhcpd[494491]: DHCPREQUEST for 192.168.1.18 (192.168.1.1) from 08:26:ae:38:16:33 via br0
712:Nov 24 13:47:39 serveur dhcpd[494491]: DHCPACK on 192.168.1.18 to 44:55:66:77:88:99 via br0
…

J’ai bien essayé de supprimer les fichiers « leases » du client et du serveur, mais rien de mieux.

#6

Ca signifie que l’IP 192.168.1.18 fait partie d’un pool dynamique (declaration pool { … }) mais aussi d’une déclaration statique (hpst hostname { … } )

#7

Essaie de définir une plage dynamique qui ne recouvre pas les adresses fixes.

1 J'aime
#8

Déjà fait, comme indiqué dans la réponse 5, mais cela n’a pas corrigé le problème, juste déplacé. :frowning:

#9

Sauf erreur de ma part, dans le message 5 il n’est question que de supprimer ou commenter la ligne « range », pas de la modifier avec une adresse de début située au-delà des adresses fixes.

1 J'aime
#10

Je ne veux que des IP statiques (attribuées par DHCPD), dont autant la supprimer.

#11

Déja là il y a un soucis, deux MAC pour la même IP.

ensuite sur la machine concernée par 192.168.1.18, tu fait un release de l’adresse. Supprimer les fichiers leases directement ce n’est pas propre.
C’est release d’abord et ensuite éventuellement tu effaces les fichiers leases, bien que normallement cela ne serve à rien.
si tu es en isc-dhcp-server, normalement il vaut mieux que les IP fixes ne soient pas dans les ranges dynamiques.
Par ailleurs dans la conf que tu indique cela s’arrête à client2, donc nous n’avons pas la vue sur ta configuration client3, c’est balot.
ensuite teste aussi sans l’options deny-duplicates;

#12

Comme indiqué dans mon message de base, j’ai indiqué que le fait d’avoir une même adresse IP pour deux adresse MAC est du au fait que je souhaites avoir la même adresse IP que je sois connecté en ethernet ou WiFi, j’utilise ce genre de configuration sans problème depuis 15 ans pour plusieurs hôtes.

Le problème étant que j’ai tenté de démarrer le client à problème via un live USB, histoire d’être sûr de ne pas avoir de « lease » qui traîne de son côté, rien de mieux.

Comme indiqué au dessus, j’ai commenté la ligne « range » car je ne souhaite avoir que des adresses fixes attribuées par DHCP, mais ça n’a rien donné de mieux.

#13

en fait la declaration range doit impérativement faire partie d’une déclaration pool { ... };. RTFM

Non ce n’est pas bon. Pour le serveur, voir même pour la norme DHCP, une IP ne peut etre décemment affectée qu’à une seule MAC. De toutes façon ça pose problème à cause des fichiers leases.
C’est une bad practice, presque un cas d’école. Car si pour une raison ou une autre, tes deux interfaces sont UP en même temps, il y aura conflit.

Avec ISC-DHCP ?

#14

Quel genre de conflit ? J’ai beau chercher, je ne vois pas.

#15

Deux interfaces avec la même adresse IP dans le même réseau. Si ça ce n’est pas un conflit je ne sais pas ce que c’est. dans le meilleurs des cas, le serveur DHCp ne fournira pas le deuxième; bien qu’après les leases ne permettront pas de passer d’une interfaces à l’autre avec la même adresse du fait des durées de bail et autres; et j’en passe.

et je ne parle pas bien sur de l’état de l’art.

#16

Deux interfaces de la même machine. Le détail est de taille. Linux applique par défaut le modèle d’hôte « faible » (weak host model) qui considère que n’importe quelle adresse d’une machine est utilisable sur n’importe laquelle de ses interfaces donc je ne vois pas en quoi il serait fonctionnellement différent qu’une même adresse soit simplement utilisée ou carrément configurée sur deux de ses interfaces connectées au même réseau.
As-tu un exemple concret de quelque chose qui ne marcherait pas dans cette situation ?

1 J'aime
#17

deux interfaces (quelles soit sur une même machines le reste du réseau s’en cogne au fait) avec la même adresse IP, oui ça va poser un problème à n’importe quel routeur, parefeu, voir meme des switchs.
en dehors des usines à gaz, personnes ne s’amuse à faire ça dans un réseau c’est contre productif.

ce que fait le linux de ton PC n’est pas ce que font les machines autours.

et en terme de savoir faire ça ne se fait pas.

#18

OK, j’ai trouvé.

J’avais sur mes PCs clients revu la configuration de portsentry à la hausse, celle-ci bloquait les ports 67 et 68 en UDP, ce qui empêchait l’un des client - UN SEUL - de recevoir son bail DHCP, et bien entendu, le problème ne s’est pas posé dès le redémarrage suivant du client.

Bref, problème corrigé.

#19

Concrètement, quel problème cela va-t-il poser ? J’ai demandé un exemple concret, j’attends toujours.

#20

Si en 2022 tu ne sais pas encore c’est triste.

Quand deux machines ont la même adresse sur un même réseau elle ne peuvent plus communiquer correctement, les paquets ne pouvant plus determiner à quel endroit exactement ils doivent aller car il y a conflit entre les deux machines;