IP forward et routage IPv4 sous debian trixie?

Bonjour,

Y a-t-il eu des modifications du paramétrage de IP forward et du routage des paquets IPv4 sous debian trixie ?
En effet, une précédente installation sous debian bookworm fonctionnait très bien, mais après une réinstallation de mon routeur maison sous debian trixie, la communication IPv4 ne fonctionne plus.
Je précise également que l’IPv6 fonctionne parfaitement, donc je ne m’attarderais pas dessus

Voici ma configuration IPv4 sur mon routeur :

root@nanopi:~# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enP1p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.0.0.254/8 brd 10.255.255.255 scope global enP1p1s0
       valid_lft forever preferred_lft forever
3: enP2p1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.40/24 metric 10 brd 192.168.0.255 scope global dynamic enP2p1s0
       valid_lft 26060sec preferred_lft 26060sec

et le routage IPv4 :

root@nanopi:~# ip -4 r
default dev enP2p1s0 proto static scope link 
default via 192.168.0.254 dev enP2p1s0 proto dhcp src 192.168.0.40 metric 10 
10.0.0.0/8 dev enP1p1s0 proto kernel scope link src 10.0.0.254 
192.168.0.0/24 dev enP2p1s0 proto kernel scope link src 192.168.0.40 metric 10 
192.168.0.254 dev enP2p1s0 proto dhcp scope link src 192.168.0.40 metric 10

L’IP forward est bien activé :

root@nanopi:~# sysctl -a --pattern forward
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.enP1p1s0.bc_forwarding = 0
net.ipv4.conf.enP1p1s0.forwarding = 1
net.ipv4.conf.enP1p1s0.mc_forwarding = 0
net.ipv4.conf.enP2p1s0.bc_forwarding = 0
net.ipv4.conf.enP2p1s0.forwarding = 1
net.ipv4.conf.enP2p1s0.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

et la translation d’adresses (NAT) est gérée par netfilter :

root@nanopi:~# nft list ruleset
[...]
table ip Routeur_IPv4 {
        chain REDIRIGE_IPv4 {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "enP2p1s0" counter packets 885 bytes 60029 masquerade
        }
}

or sur un poste client côté LAN du routeur, les requêtes IPv4 n’aboutissent pas :

libresurf@slimbook:~$ wget -4 www.debian-fr.org
--2023-12-10 18:37:50--  http://www.debian-fr.org/
Résolution de www.debian-fr.org (www.debian-fr.org)… 148.251.85.151
Connexion à www.debian-fr.org (www.debian-fr.org)|148.251.85.151|:80… échec : Aucun chemin d'accès pour atteindre l'hôte cible.

Voici la configuration IPv4 du client sous debian 12 bookworm qui n’a pas changé :

libresurf@slimbook:~$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp2s0
    inet 10.0.0.14/8 brd 10.255.255.255 scope global dynamic noprefixroute eno1
       valid_lft 28584sec preferred_lft 28584sec

et ses règles de routage IPv4 :

libresurf@slimbook:~$ ip -4 r
default via 10.0.0.254 dev eno1 proto dhcp src 10.0.0.14 metric 100 
10.0.0.0/8 dev eno1 proto kernel scope link src 10.0.0.14 metric 100 
169.254.0.0/16 dev eno1 scope link metric 1000

Je ne comprends pas ce qui ne fonctionne pas et pourquoi je n’ai pas accès à www.debian-fr.org en IPv4 depuis le poste client.

Pouvez-vous m’aider ?

Le problème vient bien du routeur.

Voici une tentative de tracer la requête à www.debian-fr.org depuis le routeur :

root@nanopi:~# traceroute www.debian-fr.org
traceroute to www.debian-fr.org (148.251.85.151), 30 hops max, 60 byte packets
 1  192.168.0.40 (192.168.0.40)  3050.429 ms !H  3050.371 ms !H  3050.368 ms !H

Je me suis dit que ça vient de la box internet, mais je l’ai redémarrée et le problème persiste…

Bonjour,

Cette route me semble être de trop.
Est-ce que tu pourrais tenter de la retirer et voir si le routage marche mieux ?

sudo ip -4 route del default dev enP2p1s0

En effet, il y a 2 routes vers default.

  • L’une des routes vers default précise une « metric » à la valeur 10.
  • L’autre route vers default, qui ne semble pas être valide, ne précise pas de valeur « metric ». La valeur « metric » utilisée est donc 0.

Au cas où plusieurs routes sont présentes pour une même destination, c’est celle dont la « metric » est la plus petite qui est retenue.
Dans ce cas, la route vers default qui semble être incorrecte.


AnonymousCoward

Merci @AnonymousCoward !!! :smiley:
Tu as mis le doigt dessus ! C’est bien cette seconde route par défaut qui posait problème. :+1:

Mais pourquoi cette route s’est-elle créée ?

La route indique proto static , c’est une information déclarative sur ce qui a créé la route. C’est un signe que la route a été ajoutée par un programme gestionnaire de réseau.

Sur une distribution Linux, il y a (toujours ?) un service de gestion du réseau.

On peut citer :

  • ifupdown (gestionnaire par défaut de Debian)
  • NetworkManager, très répandu, remplace dhcpcd pour Raspberry Pi OS
  • dhcpcd
  • ifcfg / network-scripts. Désormais géré par NetworkManager
  • Systemd-Networkd
  • netifd pour OpenWRT
  • ifupdown-ng
  • ifupdown2, sponsorisé par Cumulus Networks et écrit en Python. Conseillé pour Proxmox VE
  • netifrc, le gestionnaire par défaut sur Gentoo
  • connman, sponsorisé par Intel

J’ignore quel est le logiciel installé par défaut sur la version de Debian proposée pour les nanopi mais c’est probablement de ce coté qu’il faut chercher.


AnonymousCoward

J’ai trouvé le fautif.
J’avais la directive DefaultRouteOnDevice=true dans mon /etc/systemd/network/10-ethernet-WAN.network :

[Match]
Name=enP2p1s0

[Network]
DHCP=yes
DefaultRouteOnDevice=true

[DHCP]
UseDomains=yes
RouteMetric=10

[DHCPv6]
PrefixDelegationHint=::/56

J’ai donc retiré cette directive et tout refonctionne correctement.
Elle devait être sans effet sous debian 12 bookworm, mais bloque l’accès réseau sous trixie.

Merci @AnonymousCoward, je marque le post comme résolu.

A moins que ce ne soit lié à une installation particulière, sous Bookworm je n’ai pas ce fichier.

Oui, c’est une installation manuelle à base de debootstrap.
J’avais indiqué cette option pensant qu’elle était pertinente et elle n’avait pas provoqué de blocage avec bookworm.

Je m’aperçois maintenant qu’elle n’est pas du tout adaptée à ma situation.

1 J'aime