Route rejetée à cause des bits d’hôte ? Retrouvez le préfixe voulu

Votre ligne de route revient rejetée, et le conseil que vous trouvez dit d’activer le transfert IP. Ces deux choses se situent à des étapes différentes du problème. Le transfert décide si un hôte peut déplacer des paquets entre interfaces ; il n’a pas d’avis sur le fait que la destination saisie soit un réseau valide. Corrigez d’abord le préfixe, car le transfert ne sauvera pas une adresse et un masque qui se contredisent.

De quoi l’analyseur se plaint réellement

Une destination écrite comme une adresse plus un masque doit décrire un réseau, et un réseau commence par des bits d’hôte à zéro. Quand l’adresse fournie porte encore une valeur dans la partie hôte, la paire est incohérente en interne : 172.20.130.0 semble propre parce qu’elle finit par zéro, mais le zéro du quatrième octet n’est pas la seule chose qui compte. Le troisième octet est celui qui contient ici des bits errants.

Les outils traitent cette incohérence différemment. Les analyseurs stricts refusent la ligne et nomment les bits d’hôte. Les analyseurs indulgents masquent l’adresse et installent quelque chose que vous n’avez pas demandé, ce qui est pire, car la configuration route désormais une plage que vous n’avez jamais voulue. Le module ipaddress de Python expose le choix directement : l’analyse stricte du réseau lève une erreur, et strict=False masque les bits d’hôte. Votre client peut être strict, indulgent ou incohérent selon les versions, alors lisez le message au lieu de faire confiance à une habitude.

Faites l’exemple à la main

Prenez un tunnel qui doit atteindre 172.20.130.0 avec un masque /20. Un /20 emprunte quatre bits au troisième octet, donc cet octet ne compte que par pas de 16 : 0, 16, 32 et ainsi de suite jusqu’à 240. La valeur 130 tombe entre 128 et 143, ce qui signifie que le réseau englobant commence à 172.20.128.0, et non à 172.20.130.0 avec le dernier octet remis à zéro.

Écrit, le bloc va de 172.20.128.0 à 172.20.143.255 et contient 4,096 adresses. Fournir les mêmes valeurs à un analyseur non strict montre la substitution qu’il aurait faite à votre place :

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Décidez quelle destination vous vouliez vraiment

La ligne rejetée cache souvent l’une de trois intentions, et vous seul pouvez choisir. Si le tunnel a besoin du bloc entier, écrivez 172.20.128.0/20, l’adresse réseau canonique. Si le tunnel n’a besoin que du segment 130, le masque était faux et 172.20.130.0/24 est la forme honnête. Si une seule machine est visée, une route d’hôte IPv4 est /32 et aucune arithmétique de masque n’entre en jeu.

Chacune autorise une quantité de trafic différente, et c’est la vraie raison de ne pas élargir le masque jusqu’à ce que la plainte cesse. Un /16 accepte la ligne presque partout et envoie le trafic vers des destinations que vous n’avez jamais voulu router par le tunnel. Écrivez le préfixe le plus étroit qui correspond à l’intention, puis confirmez-le par rapport au prochain saut attendu, et non par rapport au silence de l’analyseur.

Pourquoi le transfert n’a jamais été la solution

Une route rejetée n’atteint jamais le chemin de transfert, donc basculer net.ipv4.ip_forward ne peut pas changer le résultat. Ce réglage compte plus tard, quand l’hôte doit transmettre des paquets entre interfaces, et l’activer avant que la table soit correcte ne change que l’étape qui échouera ensuite.

Deux autres choses sont souvent mises en cause au même endroit. La route peut être acceptée et perdre malgré tout face à une route plus spécifique, et une règle de pare-feu peut abandonner du trafic après une recherche correcte. Gardez les étapes séparées : syntaxe, installation, sélection, filtrage. Travailler sur la mauvaise étape semble productif parce que chaque changement redémarre quelque chose.

Vérifiez la route installée et le chemin qu’elle gagne

Une fois la ligne acceptée par le client, regardez ce qu’il a installé et quelle route le noyau choisit pour une adresse représentative dans le bloc. Si le préfixe installé diffère de celui écrit, un normaliseur a agi à votre place.

Interrogez une adresse membre ainsi qu’une adresse hors du bloc, pour que la comparaison soit significative plutôt qu’une seule ligne rassurante :

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

La troisième requête doit tomber hors du tunnel si votre préfixe est correct, et quand ce n’est pas le cas, la route construite est plus large que vous ne le pensez. Notez ce que le préfixe était censé couvrir avant de toucher au réglage suivant, car une route qui s’analyse et un chemin qui fonctionne restent des observations distinctes.