Pourquoi une route d’hôte /32 garde l’extrémité du VPN joignable

Une route d’hôte choisit une adresse, pas un sous-réseau. Elle peut garder une extrémité de tunnel joignable ou épingler une ressource, mais elle devient obsolète quand les adresses changent.

Vous ouvrez la table de routage après la connexion et vous trouvez une seule adresse routée par le tunnel, tandis que le sous-réseau autour d’elle continue d’aller vers la passerelle locale. Cette entrée est une route d’hôte : une adresse, mise en correspondance par un préfixe de tous les uns. Elle compte parce que les décisions de routage utilisent le préfixe correspondant le plus long, si bien qu’un /32 peut supplanter un /24 ou une route par défaut sans modifier ni l’un ni l’autre. Qu’il s’agisse d’une exception soignée ou d’une panne future dépend de l’adresse qu’elle nomme et de qui la maintient.

Une adresse, une entrée dans la table

Une route d’hôte IPv4 porte un préfixe /32 et une route d’hôte IPv6 porte /128, ce qui signifie que l’entrée peut correspondre exactement à une adresse de destination. Rien d’autre dans la table ne bouge : le sous-réseau couvrant et la route par défaut restent où ils étaient. L’entrée étroite l’emporte pour cette adresse parce que son préfixe est plus long, non parce qu’elle a été ajoutée plus tard.

Cette propriété fait d’une route d’hôte une bonne exception et une mauvaise habitude. Deux entrées /32 qui nomment la porte d’entrée d’un service ne couvrent ni sa deuxième adresse, ni son adresse IPv6, ni l’adresse vers laquelle elle déménage le mois prochain. Une table pleine d’entrées à adresse unique inexpliquées signifie généralement que quelqu’un n’a cessé de rafistoler autour d’une décision de sous-réseau au lieu de la prendre. Lisez d’abord la longueur du préfixe, puis demandez ce que l’entrée est censée protéger.

Lire l’entrée depuis le client vers l’extérieur

Commencez par la machine qui a le problème, car la même adresse peut être routée différemment sur un portable et sur la passerelle devant lui. Demandez au noyau quel chemin il choisirait pour l’adresse exacte qu’utilise l’application, au lieu de lire la table depuis le haut. La réponse inclut l’interface et le saut suivant, qui ensemble constituent la décision.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Répétez la requête pour la famille d’adresses que l’application choisit réellement, car un client peut préférer IPv6 et contourner discrètement une exception IPv4. Comparez le résultat avant et après la montée du tunnel, et conservez les deux sorties. Cette comparaison montre si le client a ajouté l’entrée au moment de la connexion ou si elle était déjà là.

Une entrée persistante et une entrée d’exécution échouent différemment. Celle d’exécution disparaît avec la session, tandis que la persistante survit à un redémarrage et continue d’envoyer du trafic vers une passerelle qui n’existe plus.

L’exception d’extrémité et le piège de la récursion

Les clients VPN installent généralement une route d’hôte vers l’adresse extérieure du serveur via la passerelle d’origine avant de rediriger la route par défaut. Sans cette entrée, les paquets chiffrés seraient envoyés dans le tunnel qu’ils tentent de construire, et la connexion bouclerait jusqu’à expiration.

Le piège apparaît lorsque les sous-réseaux acceptés du tunnel incluent par hasard cette adresse d’extrémité, ou lorsqu’un second profil ajoute ensuite une route plus large. L’entrée d’extrémité perd alors face à un préfixe plus long et la session s’effondre dès qu’elle commence à faire passer du trafic. Écrire l’adresse d’extrémité à côté des sous-réseaux acceptés est le moyen le moins coûteux de remarquer la collision avant les utilisateurs. Cela explique aussi pourquoi le même profil fonctionne depuis un réseau et échoue depuis un autre.

Vérifier le chemin que l’application utilise réellement

Un ping réussi vers le nom d’hôte est une preuve faible lorsque l’application se connecte à une autre adresse ou à une autre famille. Vérifiez le tuple exact d’adresse, de famille, de port et d’interface, depuis la machine qui exécute le client.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Si le chemin est incorrect, décidez si le besoin est un réseau ou une adresse avant de modifier quoi que ce soit. Un besoin d’une seule adresse justifie une route d’hôte avec un commentaire et un responsable ; un service aux adresses changeantes a besoin d’un routage fondé sur le domaine ou d’une décision honnête de sous-réseau.

Supprimez les entrées qui ne correspondent plus à une destination réelle et notez celles que vous conservez. Un /32 inexpliqué est indistinguable d’un défaut trois mois plus tard, et la personne suivante le supprimera sans savoir ce qui en dépendait.

Articles similaires