L'info debug intéressante du soir : le strict RPF ne fonctionne pas avec des IPv4 locales au lien quand plusieurs interfaces ont ces mêmes IPs.
RPF = reverse path forwarding = anti-usurpation d'IP. Voir
http://www.bortzmeyer.org/3704.html
L'IETF a bien réservé des IPv4 locales au lien à l'IANA, voir
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml . Par contre, Linux ne les considère pas nativement comme telles donc il faut toujours préciser « scope link » quand on les ajoute à une interface même via /etc/network/interfaces.
Soit deux machines, reliées par un câble réseau direct. On assigne une IP link locale des deux côtés. ping -I eth0 169.254.42.2 passe très bien depuis 169.254.42.1. Même chose en IPv6 avec fe80::42:1 et 2 : ça fonctionne.
Des deux côté, ajoutons la règle RPF kiVaBien : ip(6)tables -t raw -A PREROUTING -i $IFACE -m rpfilter --invert -j DROP . Ping v4 et v6 fonctionnent encore.
Maintenant, si nous ajoutons un lien vers une autre machine ou que nous rajoutons un lien (VLAN ou dédié) entre ces machines, avec les mêmes IP et la même règle RPF, on remarquera que le premier lien ping encore en v4 et en v6... mais que le deuxième lien ping v6 alors que le ping v4 ne fonctionne plus...
On supprime la règle RPF sur le deuxième lien : ça fonctionne. On remet la règle RPF ? Ça ne fonctionne plus et on voit les compteurs de paquets bloqués augmenter...
Pourtant, si l'on regarde à coup de ip r s dev <interface> et ip r g <IP> dev <interface>, on voit que l'on a bien une route sur les deux interfaces... En toute logique, le ping entrant devrait être autorisé par le mécanisme RPF.
Même en utilisant l'ancienne fonctionnalité du noyau Linux, avant qu'elle soit déléguée à Netfilter, « echo 1 | sudo tee /proc/sys/net/ipv4/conf/<interface>/rp_filter », ça bloque les IPv4 locales au lien...