Problème avec serveur DHCP

Support Debian
#1

Bonjour, je travaille avec la plateforme Proxmox pour la virtualisation des serveurs de mes clients.
Pour les serveurs Linux, tout est automatique, mais pour les serveur Windows, un serveur DHCP est requis.

J’utilise donc isc-dhcp-server. Proxmox à créer une carte réseau nommé vmbr0 qui redirige vers eth0.
Tout les serveurs sont connecté sur vmbr0.

J’ai donc configuré le serveur DHCP en écoute sur vmbr0.

Voici mes fichiers de configuration:

  • /etc/default/isc-dhcp-server
# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts
 
#
# This is a POSIX shell fragment
#
 
# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPD_CONF=/etc/dhcp/dhcpd.conf
 
# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPD_PID=/var/run/dhcpd.pid
 
# Additional options to start dhcpd with.
#   Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
#OPTIONS=""
 
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#   Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="vmbr0"
  • /etc/dhcp/dhcpd.conf
#
# Sample configuration file for ISC dhcpd for Debian
#
#
 
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;
 
# option definitions common to all supported networks...
option domain-name "youheberg.fr";
option domain-name-servers 8.8.8.8, 8.8.4.4;
 
default-lease-time 600;
max-lease-time 7200;
 
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;
 
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
 
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
 
#subnet 10.152.187.0 netmask 255.255.255.0 {
#}
 
# This is a very basic subnet declaration.
 
#subnet 10.254.239.0 netmask 255.255.255.224 {
#  range 10.254.239.10 10.254.239.20;
#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}
 
# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.
 
#subnet 10.254.239.32 netmask 255.255.255.224 {
#  range dynamic-bootp 10.254.239.40 10.254.239.60;
#  option broadcast-address 10.254.239.31;
#  option routers rtr-239-32-1.example.org;
#}
 
# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
#  range 10.5.5.26 10.5.5.30;
#  option domain-name-servers ns1.internal.example.org;
#  option domain-name "internal.example.org";
#  option routers 10.5.5.1;
#  option broadcast-address 10.5.5.31;
#  default-lease-time 600;
#  max-lease-time 7200;
#}
 
# Hosts which require special configuration options can be listed in
# host statements.   If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.
 
#host passacaglia {
#  hardware ethernet 0:0:c0:5d:bd:95;
#  filename "vmunix.passacaglia";
#  server-name "toccata.fugue.com";
#}
 
# Fixed IP addresses can also be specified for hosts.   These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.   Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
#  hardware ethernet 08:00:07:26:c0:a5;
#  fixed-address fantasia.fugue.com;
#}
 
# You can declare a class of clients and then do address allocation
# based on that.   The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.
 
#class "foo" {
#  match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}
 
#shared-network 224-29 {
#  subnet 10.17.224.0 netmask 255.255.255.0 {
#    option routers rtr-224.example.org;
#  }
#  subnet 10.0.29.0 netmask 255.255.255.0 {
#    option routers rtr-29.example.org;
#  }
#  pool {
#    allow members of "foo";
#    range 10.17.224.10 10.17.224.250;
#  }
#  pool {
#    deny members of "foo";
#    range 10.0.29.10 10.0.29.230;
#  }
#}
 
subnet 137.74.157.0 netmask 255.255.255.0 {
    range 137.74.157.136 137.74.157.139;
    option subnet-mask 255.255.255.0;
    option routers 37.187.164.254;
}

Sauf que au lancement du serveur DHCP, voici ce que j’obtient:

  • journalctl -xn
nov. 16 15:22:19 ns3012890 dhcpd[21329]: bugs on either our web page at www.isc.org or in the README file
nov. 16 15:22:19 ns3012890 dhcpd[21329]: before submitting a bug.  These pages explain the proper
nov. 16 15:22:19 ns3012890 dhcpd[21329]: process and the information we find helpful for debugging..
nov. 16 15:22:19 ns3012890 dhcpd[21329]:
nov. 16 15:22:19 ns3012890 dhcpd[21329]: exiting.
nov. 16 15:22:21 ns3012890 isc-dhcp-server[21320]: Starting ISC DHCP server: dhcpdcheck syslog for diagnostics
nov. 16 15:22:21 ns3012890 isc-dhcp-server[21320]: failed!
nov. 16 15:22:21 ns3012890 systemd[1]: isc-dhcp-server.service: control process exited, code=exited status=1
nov. 16 15:22:21 ns3012890 systemd[1]: Failed to start LSB: DHCP server.
-- Subject: L'unité (unit) isc-dhcp-server.service a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- L'unité (unit) isc-dhcp-server.service a échoué, avec le résultat failed.
nov. 16 15:22:21 ns3012890 systemd[1]: Unit isc-dhcp-server.service entered failed state.
  • systemctl status isc-dhcp-server.service
   Loaded: loaded (/etc/init.d/isc-dhcp-server)
   Active: failed (Result: exit-code) since mer. 2016-11-16 15:23:14 CET; 9s ago
  Process: 21510 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
 
nov. 16 15:23:12 ns3012890 dhcpd[21519]:
nov. 16 15:23:12 ns3012890 dhcpd[21519]: No subnet declaration for vmbr0 (37.187.164.164).
nov. 16 15:23:12 ns3012890 dhcpd[21519]: ** Ignoring requests on vmbr0.  If this is not what
nov. 16 15:23:12 ns3012890 dhcpd[21519]: you want, please write a subnet declaration
nov. 16 15:23:12 ns3012890 dhcpd[21519]: in your dhcpd.conf file for the network segment
nov. 16 15:23:14 ns3012890 isc-dhcp-server[21510]: Starting ISC DHCP server: dhcpdcheck syslog for diagn...ed!
nov. 16 15:23:14 ns3012890 isc-dhcp-server[21510]: failed!
nov. 16 15:23:14 ns3012890 systemd[1]: isc-dhcp-server.service: control process exited, code=exited status=1
nov. 16 15:23:14 ns3012890 systemd[1]: Failed to start LSB: DHCP server.
nov. 16 15:23:14 ns3012890 systemd[1]: Unit isc-dhcp-server.service entered failed state.

Cordialement, Volting

#2

Peux-tu aussi mettre le contenu du fichier /etc/network/interfaces, s’il te plait ?

#3

Merci de la réponse, oui, aucun problème,

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# for Routing
auto vmbr1
iface vmbr1 inet manual
	post-up /etc/pve/kvm-networking.sh
	bridge_ports dummy0
	bridge_stp off
	bridge_fd 0


# vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.
auto vmbr0
iface vmbr0 inet static
	address 37.187.164.164
	netmask 255.255.255.0
	network 37.187.164.0
	broadcast 37.187.164.255
	gateway 37.187.164.254
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0

iface vmbr0 inet6 static
	address 2001:41d0:000d:0fa4::
	netmask 64
	post-up /sbin/ip -f inet6 route add 2001:41d0:000d:0fff:ff:ff:ff:ff dev vmbr0
	post-up /sbin/ip -f inet6 route add default via 2001:41d0:000d:0fff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del default via 2001:41d0:000d:0fff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del 2001:41d0:000d:0fff:ff:ff:ff:ff dev vmbr0
#4

Le range que tu mis dans ton fichier dhcpd.conf n’est pas bon alors. Tu as mis 137.74.157.0 alors que ça ne correspond pas à vmbr0.

#5

Du DHCP pour des serveurs ? On aura tout vu…

Et comme le serveur DHCP et les VM sont sur le pont vmbr0 qui englobe l’interface physique eth0, le trafic DHCP va baver à l’extérieur de la machine hôte à moins de mettre en place des règles de filtrage ebtables.

Quelle est la vraie plage d’adresses IP allouées par OVH aux VM (Linux inclus) ?

#6

Pour le serveur dédié Linux nous avons: 37.187.164.164
Pour les VM nous avons:
137.74.157.136 - 137.74.157.139

#7

C’est risqué d’avoir inclus toute la plage des VM, y compris les adresses des VM Linux, dans la plage DHCP si les VM Linux n’utilisent pas le DHCP. Normalement le serveur DHCP et/ou le client vérifie qu’une adresse ne répond pas avant de la proposer/accepter, mais il vaut mieux éviter.

Je n’ai jamais réussi à faire tourner ISC dhcpd sur une interface dont une adresse IP n’appartient pas au sous-réseau défini dans sa configuration. Par conséquent il faudrait attribuer une adresse de la plage des VM au pont vmbr0, ce qui n’en laisserait que trois disponible pour les VM. Encore un argument contre l’utilisation de DHCP.

PS : l’adresse IPv6 2001:41d0:000d:0fa4:: configurée sur vmbr0 est réservée comme adresse “anycast” des routeurs du réseau 2001:41d0:000d:0fa4::/64, elle ne devrait pas être attribuée à une interface.

#8

Ah bon ? Ça fait plusieurs années que j’utilise la première adresse IPv6 du réseau sans aucun soucis. C’est quoi exactement ?

#9

Tout routeur IPv6 directement connecté à un réseau est censé répondre à la première adresse du préfixe de ce réseau. Cette adresse est dite “anycast” car elle peut correspondre à n’importe quel (any) routeur du réseau. Par conséquent si cette adresse est configurée sur une autre machine que l’unique routeur directement connecté à ce réseau, les paquets qui lui sont destinés ne lui arriveront pas forcément car ils peuvent être interceptés par un routeur du réseau.

#10

Ah, donc, en fait, j’ai eu du bol, j’ai eu la présence d’esprit d’attribuer cette adresse au routeur à chaque fois, du coup, c’est pour ça que je n’ai jamais eu de problème.