Serveur DNSMASQ DHCP, pas de bail donnée

Tags: #<Tag:0x00007f63f3ce16a8>

Bonjour

J’ai un serveur DEBIAN12 derriere une livebox.
J’utilise un DNS privé dans ce serveur, cela fonctionne tres bien.

La livebox a les serveur DNS non modificable.
J’ai donc creer un serveur DHCP dans ce serveur et bien sur desactiver celui de la livebox.

Ma config DNS et DHCP avec DNSMASQ qui fonctionne (car elle tourne sur un raspebrry en attendant et c’est fonctionnel)

#### DNS ####
#query-port=1000

port=53
user=dnsmasq
group=dnsmasq
local=/.lan/
bogus-priv
filterwin2k
localise-queries
strict-order
cache-size=1000
listen-address=192.168.100.240,127.0.0.1
no-negcache
resolv-file=/etc/dnsmasq.d/dnsmasq-dns.conf
no-hosts
addn-hosts=/etc/dnsmasq.d/dnsmasq-hosts.conf
expand-hosts
#log-facility=/var/log/dnsmasq_local.log
#log-queries

#### DHCP ####
#log-dhcp
dhcp-authoritative
dhcp-lease-max=10
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-range=192.168.100.50,192.168.100.100,24h
dhcp-option=1,255.255.255.0
dhcp-option=3,192.168.100.254
dhcp-option=6,192.168.100.240
dhcp-option=option:ntp-server,192.168.100.240

dhcp-host=3C:BD:D8:D9:03:1C,192.168.100.200
dhcp-host=5C:CF:7F:9F:B0:38,192.168.100.244
dhcp-host=B4:E6:2D:26:EB:36,192.168.100.245
dhcp-host=24:0A:C4:30:CB:10,192.168.100.246

Mon interface via IFCONFIG

    eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether a8:a1:59:db:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 10123234  bytes 8087801668 (7.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4996043  bytes 2291678490 (2.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.240  netmask 255.255.255.0  broadcast 192.168.100.255
        ether a8:a1:59:db:xx:xx  txqueuelen 1000  (Ethernet)

Mes regles IPTABLES (partiel), c’est pas propre mais ce n’est pas le soucis

# DHCP
iptables -A INPUT -p udp --dport 67 -j ACCEPT
iptables -A INPUT -p udp --dport 68 -j ACCEPT
# DNS
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT

Ma config sysctl.conf que je soupcone fortement

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
fs.inotify.max_user_watches = 10000000
fs.protected_fifos = 1
fs.protected_regular = 2
kernel.core_uses_pid = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
kernel.yama.ptrace_scope = 1
kernel.unprivileged_bpf_disabled = 1
kernel.panic=20

net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.log_martians = 1

net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.lo.autoconf = 0
net.core.bpf_jit_harden = 2
vm.overcommit_memory=1

Pour info, quand mon serveur est en adresse IP DHCP, il obtient bien l’adresse, mais en tant que serveur (avec une adresse statique defini), rien, pas de bail
Le fichier DNSMASQ est exactement le meme sur mon raspberry temporaire sans la partie DNS.

Si vous avez une piste, je suis preneur.
Merci d’avance

Ton serveur DHCP est obligatoirement en IP statique.
Il n’obtiendra jamais un IP de l’un de tes pools réseau.
C’est avec une autre machine qui doit demander une ip dhcp à ton serveur.
Et résumé:
livebox:

  • DHCP desactivé
  • Gère les DNS (ceci dit ils peuvent être modifiés manuellement, tout dépend de la version de la livebox)
    Raspberry:
    DHCP activé
    IP fixe dans le réseau 192.168.100.0/24 hors du range DHCP (c’est à dire host <50 ou host >100 exceptions 240 et 254

Autre machine:
config réseau en DHCP

En passant, pour mettre en place un serveur DHCP et un serveur DNS il n’y a absolument aucune raison d’aller trifouiller sysctl.

par exemple cette option à 1 est totalement inutile avec une seule interface. Elle a pour objectif de permettre de faire transiter des paquets d’une interface eth0 vers une interface eth1.
Tu n’es pas dans ce cas là. Remet les sysctl à leur valeur par défaut.

Stoppe iptables aussi pour voir si ta config marche. On ne teste pas trois choses en même temps mais une par une.

Merci de ma réponse rapide

Livebox version 5 avec DNS en dur, bien sur DHCP désactivé.

RASPBERRY avec déjà IP FIXE et config DNSMASQ, c’est déjà fonctionnel ! Mais ce n’est pas la config que je veux en définitif

Le serveur, actuellement en DHCP, mais l’essai a été fait avec une IP fixe, en l’occurrence 192.168.100.240

La config dans sysctl.conf est utilisé pour sécurisation, il y aussi un VPN WIREGUARD dedans, c’est pour cela que le forword a été activé

Le test a été également fait avec iptables totalement vide.

Le soucis devrait se situer soit dans sysctl.conf je présume ou une piste non explorer

test avec les éléments un par un.
Désactive ton vpn et le forward. Utilise un sysctl par défaut pour commencer.

Car si tu fait des tests avec tout d’un seul coup, tu ne sais plus lequel pose problème.
Si sans toute la machinerie VPN ça marche alors tu peux passer au VPN ensuite.

Personnellement je n’utilise pas dnsmasq, je lui préfère isc-dhcp-server qui est sur mon OPNsense (ils n’ont pas encore fait le passage à KEA).

Bonjour,

Je ne sais pas si ça a un rapport, mais j’avais déjà eu des soucis sur les sommes de contrôle des paquets UDP sur le protocole DHCP.
À tout hasard, essaie d’ajouter ces règles dans IPTABLES :

iptables -t mangle -A POSTROUTING -p udp --dport 68 -j CHECKSUM --checksum-fill

C’est un règle qui rempli correctement la somme de contrôle des paquets UDP.

Bonjour

J’avance petit à petit grace à Wireshark
donc IPTABLES fonctionne bien sur les regles, idem sysctl.conf

le soucis vient de mes interfaces, je viens de les activer dans DNSMASQ

interface=enp3s0
interface=eno1

Voici mes interfaces avec ifconfig

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether a8:a1:59:db:63:68  txqueuelen 1000  (Ethernet)
        RX packets 35110  bytes 31268866 (29.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27305  bytes 6019937 (5.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.240  netmask 255.255.255.0  broadcast 192.168.100.255
        ether a8:a1:59:db:63:68  txqueuelen 1000  (Ethernet)

Le log dans DNSMASQ

dnsmasq-dhcp[6389]: Paquet DHCP reçu sur eno1 qui n'a pas d'adresse

Je precise que je n’avais pas cette info.

Comment je sais quelle est l’interface reelle?
Je n’ai trouvé aucun bridge dans ma config et je n’ai qu’une seule interface reseau …

Comment ça? à quoi correspond ton interface eno1?
eno1 et enp3s0 sont en correspondance car elles ont la même adresse MAC :

a8:a1:59:db:63:68

enp3s0 est l’adresse physique. L’autre doit surement être en rapport avec ton VPN.

Comme je te disais, si tu veux déjà tester si ton DHCP fonctionne correctement, désactive ton VPN.
Sur un DHCP, une interface liée à la fourniture du service DHCP ne peut pas être en DHCP elle-même.

Trouvé

Merci Zargos mais le VPN n’a pas ce type de nom, il est wgXX pour wireguard Oxx pour openVPN ou ztxxxx pour zerotier, et surtout pour ce type d’adresse
Et l’explication du dhcp est dans mon premier post …

Voila la solution pour ceux qui cherche

Pour connaitre l’interface physique, il faut faire

ip addr show

ensuite connaitre son nom avec

 ifconfig -a

Trouve le nom alias ou altname, et le supprimer avec

ip link delete eno1 alias enp3s0

Et enfin avant de redemarrer, editer /etc/network/interface et de bien verifier l’existance de ces lignes

auto eno1
allow-hotplug eno1

Pour info, cette interface virtuelle s’est cree en faisant la mise à jour de debian

Sur quoi te bases-tu pour dire ça?

[www.itzgeek.com/amp/how-tos/linux/debian/change-default-network-name-ens33-to-old-eth0-on-debian-9.html](https://Debian eth to enp)

debian 9. C’est obsolète.
Et en prime eno n’a jamais été une interface standard.

Relis bien mon message de départ, je suis sous debian 12 …
Mais cette modification peut s’appliquer à tout moment, y compris changement matériel.
Et eno1, c’est bien standard, c’est le raccourci ethernet en remplacement de eth …

Voici le lien ci dessous, cadeau

et comment tu explique les deux? il y a forcement une manip manuelle quelq<ue part.

De toue façon, ca ne change rien au fait que pour DHCP les interfaces sur lesquelles il écoutent doivent obligatoirement avoir une IP fixe.

Oui durant une mise à jour de debian 9 à 10 il y avait parfois renommage des interface réseau sur des machines virtuelles ou physiques.

Non c’est totalement faux, tu peux être en dhcp et délivré un bail dhcp une fois que le serveur l’a obtenu.
Notamment avec un dhcp relay …
Il suffit juste d’avoir une adresse ip.

Rien à voir.
Un serveur DHCP écoute sur des interfaces (pas forcement toutes les interfaces).
Mais celles sur lesquelles il écoute doivent avoir une IP avant d’écouter. De fait elle est ton statique. Donc il ne peut pas se donner lui même une adresse via le protocole DHCP. Sauf que deux serveur DHCP sur le même segment vont interférer l’un avec l’autre.
Le DHCP relay n’a rien à voir. C’est pour permettre à un serveur DHCP de servir des réponses dans un sous-réseau dans lequel il n’a pas d’interface. Et c’est une fonction qu’on active uniquement sur les routeurs aujourd’hui (avant pas forcement car les routeurs n’avaient pas la fonction intégrée, donc il y a avait des machines qui servaient de relai DHCP, mais ce n’étaient pas des serveurs DHCP.
C’est pour ça qu’on ne met jamais deux serveurs DHCP qui servent le même pool (sauf failover mais c’est autre chose).