Kea-dhcp4-server n'écoute pas sur le port 67 (bootps)

Tags: #<Tag:0x00007fc9f0a5e9e0>

Bonjour,

Sous Debian 12 bookworm, j’ai installé le paquet kea pour configurer un serveur DHCP.
Le paquet kea est un méta-paquet qui installe automatiquement kea-dhcp4-server et kea-dhcp6-server.

Voici ma configuration de /etc/kea/kea-dhcp4.conf :

{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [
              "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "192.0.2.252, 192.0.2.253"
        }
    ],
    "subnet4": [
        {
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.1 - 192.0.2.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "192.0.2.254"
                }
            ]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp4",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp4.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

et celle de /etc/kea/kea-dhcp6.conf :

{
"Dhcp6": {
    "interfaces-config": {
        "interfaces": [
                      "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea6-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases6.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "preferred-lifetime": 3000,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "dns-servers",
            "data": "2001:db8:192:0::252, 2001:db8:192:0::253"
        }
    ],
    "subnet6": [
        {
            "subnet": "2001:db8:192:0::/64",
            "pools": [ { "pool": "2001:db8:192:0::1 - 2001:db8:192:0::199" } ]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp6",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp6.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

J’utilise systemd pour gérer le lancement de kea-dhcp4-server et de kea-dhcp6-server :

# systemctl restart kea-dhcp4-server.service
# systemctl restart kea-dhcp6-server.service

Mon problème est que kea-dhcp4-server n’écoute pas sur le port 67 (bootps) les requêtes des futurs clients DHCP.
Alors que kea-dhcp6-server, lui écoute bien sur le port 547 (dhcp6-server) pour l’Ipv6 !

Voici la sortie de ss :

root@server:/etc/kea# ss -lup
State         Recv-Q        Send-Q                                      Local Address:Port                        Peer Address:Port       Process                                           
UNCONN        0             0                                   192.168.0.19%enP2p1s0:bootpc                           0.0.0.0:*           users:(("systemd-network",pid=289,fd=18))        
UNCONN        0             0                                               127.0.0.1:53001                            0.0.0.0:*           users:(("kea-dhcp-ddns",pid=1567,fd=13))         
UNCONN        0             0                    [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client                       [::]:*           users:(("systemd-network",pid=289,fd=21))        
UNCONN        0             0                    [fe80::1494:98ff:fea9:d341]%enP1p1s0:dhcpv6-server                       [::]:*           users:(("kea-dhcp6",pid=3431,fd=15))             
UNCONN        0             0                                    [ff02::1:2]%enP1p1s0:dhcpv6-server                       [::]:*           users:(("kea-dhcp6",pid=3431,fd=16))

Savez-vous quel est le problème ?
Merci à vous.

Ton serveur écoute sur le port 68 (bootpc)
Peut tu nous donner un ip a s’il te plait? si ton interface enp2P1s0 est en DHCP, c’est pour ça que ton serveur ne démarre pas. Car le client écoute sur le port 68.
Un serveur DHCP ne peut pas être définit sur une interface en DHCP.

Bonjour @Zargos,

Voici la sortie de la commande ip a :

root@server:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enP2p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 16:6c:df:b9:9d:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.19/24 metric 10 brd 192.168.0.255 scope global dynamic enP2p1s0
       valid_lft 26866sec preferred_lft 26866sec
    inet6 2a01:e0a:26:d3a0::46af:ab1/128 scope global dynamic noprefixroute 
       valid_lft 45185sec preferred_lft 45185sec
    inet6 fe80::146c:dfff:feb9:9df0/64 scope link 
       valid_lft forever preferred_lft forever
3: enP1p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 16:94:98:a9:d3:41 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.254/24 brd 192.168.2.255 scope global enP1p1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1494:98ff:fea9:d341/64 scope link 
       valid_lft forever preferred_lft forever

J’ai oublié de préciser, la machine est un NanoPi R5C avec deux cartes réseaux :

  • Port WAN sur interface enP2p1s0, qui est paramétrée pour obtenir son adresse IP par DHCP. Donc, c’est logique que cette interface écoute sur le port 68 (bootpc);
  • Port LAN sur interface enP1p1s0, dont l’adresse IPv4 est paramétrée en dur et qui sert de serveur DHCP pour le réseau qui lui sera connecté.

Les deux interfaces sont paramétrées par Systemd.

Voici le fichier de configuration du port WAN (/etc/systemd/network/10-ethernet-WAN.network):

[Match]
Name=enP2p1s0

[Network]
DHCP=yes

[DHCP]
UseDomains=yes
RouteMetric=10

Voici le fichier de configuration du port LAN (/etc/systemd/network/15-ethernet-LAN.network):

[Match]
Name=enP1p1s0

[Network]
Address=192.168.2.254/24

Cette configuration est volontairement très minimaliste pour être sur que Systemd n’interfère pas avec le serveur kea-dhcp.

Voici la sortie de networkctl list :

root@server:~# networkctl 
IDX LINK     TYPE     OPERATIONAL SETUP     
  1 lo       loopback carrier     unmanaged
  2 enP2p1s0 ether    routable    configured
  3 enP1p1s0 ether    routable    configured

3 links listed.

Si je modifie le fichier de configuration du port LAN ( /etc/systemd/network/15-ethernet-LAN.network ) en rajoutant une section DHCPServer :

[Match]
Name=enP1p1s0

[Network]
Address=192.168.2.254/24
DHCPServer=true

[DHCPServer]
ServerAddress=192.168.2.254/24

alors c’est le serveur DHCP de Systemd qui se lance, ce que je ne veux pas !

root@server:~# ss -lup
State  Recv-Q Send-Q                         Local Address:Port            Peer Address:Port Process                                                                                      
UNCONN 0      0                                  127.0.0.1:53001                0.0.0.0:*     users:(("kea-dhcp-ddns",pid=508,fd=13))                                                     
UNCONN 0      0                           0.0.0.0%enP1p1s0:bootps               0.0.0.0:*     users:(("systemd-network",pid=608,fd=25))                                                   
UNCONN 0      0                      192.168.0.19%enP2p1s0:bootpc               0.0.0.0:*     users:(("systemd-network",pid=608,fd=18))                                                   
UNCONN 0      0       [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client           [::]:*     users:(("systemd-network",pid=608,fd=21))                                                   

et je perds le kea-dhcp6 que j’avais auparavant !!!

En fait tu n’as pas compris.
Ton serveur DHCP fourni les adresse sur le réseau 192.168.0.0/24 sur l’interface WAN. L’interface correspondante doit être statique, elle ne peut pas être dynamique.
De plus, il faut que le routeur entre 192.168.0.0/24 et 192.0.2.0/24 dispose de la fonctionnalité de relay DHCP.
Par ailleurs, juste pour savoir, c’est une plateforme de tests? car 192.0.0.0 est un segment IP réservée par l’agence de gestion des adresses IP et non attribuée en tant qu’IP publique ou privée.

Bonjour @Zargos ,
Merci pour ton retour.

Je vais commencer par ça :

Oui, c’est une plateforme de test avec un réseau privé.

Ensuite :

J’ai mis du temps à comprendre ce que tu voulais dire… Je pense que j’ai compris.
La RFC 1918 définit le bloc d’adresses 192.168.0.0/16 (masque de sous réseau 192.168.255.255) qui englobe le sous-réseau que je voulais définir 192.168.2.0/24 (masque de sous réseau 192.168.2.255).
Du coup, si ma box internet fournit un serveur DHCP qui gère tout le réseau 192.168.0.0/16, je ne peux pas définir le sous-réseau 192.168.2.0/24 de manière autonome et c’est pour ça que le serveur kea-dhcp4-server ne se lance pas.

Malheureusement, je n’ai pas vraiment « complètement » la main sur le serveur DHCP de ma box internet, donc je ne sais pas quelle est l’étendue du réseau qu’elle prend en compte.
Du coup, j’ai changé mon fusil d’épaule et modifié l’adresse de réseau de mon interface LAN en 10.0.0.0/8.

Voici la nouvelle configuration de etc/systemd/network/15-ethernet-LAN.network :

[Match]
Name=enP1p1s0

[Network]
Address=10.0.0.254/8

et celle de /etc/kea/kea-dhcp4.conf :

{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [
              "enP1p1s0"
        ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600,
        "persist": true,
        "name": "/var/lib/kea/kea-leases4.csv"
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 28800,
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "10.0.0.252, 10.0.0.253"
        }
    ],
    "subnet4": [
        {
            "subnet": "10.0.0.0/8",
            "pools": [ { "pool": "10.0.0.1 - 10.0.0.199" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "10.0.0.254"
                }
            ]
        }
    ],
    "loggers": [
    {
        "name": "kea-dhcp4",
        "output_options": [
            {
                "output": "/var/log/kea/kea-dhcp4.log",
                "maxsize": 1048576,
                "maxver": 10
            }
        ],
        "severity": "INFO",
        "debuglevel": 0
    }
  ]
}
}

et ça marche ! :smiley: :+1:

Voici la sortie de la commande ss -lup :

root@server:~# ss -lup
State        Recv-Q        Send-Q                                      Local Address:Port                        Peer Address:Port       Process                                          
UNCONN       0             0                                               127.0.0.1:53001                            0.0.0.0:*           users:(("kea-dhcp-ddns",pid=505,fd=13))         
UNCONN       0             0                                              10.0.0.254:bootps                           0.0.0.0:*           users:(("kea-dhcp4",pid=506,fd=15))             
UNCONN       0             0                                   192.168.0.19%enP2p1s0:bootpc                           0.0.0.0:*           users:(("systemd-network",pid=289,fd=10))       
UNCONN       0             0                    [fe80::146c:dfff:feb9:9df0]%enP2p1s0:dhcpv6-client                       [::]:*           users:(("systemd-network",pid=289,fd=23))       

Le serveur kea-dhcp4-server est bien lancé ! et je confirme qu’il fonctionne car il attribue une adresse IP 10.0.0.1 au premier client qui se connecte.

Maintenant, le problème se pose pour kea-dhcp6-server qui n’est pas opérationnel.
Et là se pose certainement le problème du relais DHCP (mais en IPv6) dont tu parles.
Il faut que j’explore cette piste…