Redirections ICMP face à vos routes VPN : ce qui change vraiment

Un flux qui devrait traverser le tunnel prend un autre prochain saut, et quelqu'un trouve une redirection ICMP dans une capture. C'est une hypothèse, pas un diagnostic. Une redirection est une suggestion du routeur concernant un meilleur prochain saut, et le fait que l'hôte agisse en conséquence dépend de réglages qui varient selon la plateforme, l'interface et la famille d'adresses.

Une redirection est une suggestion du routeur

Les redirections ICMP d'IPv4 ont leur propre type de message et un ensemble étroit de conditions : le routeur achemine un paquet par l'interface par laquelle il est arrivé, et il connaît un prochain saut sur ce même lien plus proche de la destination. Il indique ensuite à l'émetteur d'utiliser ce prochain saut directement. Le message nomme la nouvelle passerelle et inclut une partie du paquet d'origine pour que l'émetteur puisse l'associer à un flux. C'est un message de courtoisie sur la topologie locale, et il suppose que l'émetteur partage un lien avec la passerelle suggérée.

L'émetteur est libre de l'ignorer. Rien dans le protocole n'oblige un hôte à modifier sa table, et une redirection capturée prouve seulement qu'un routeur en a envoyé une.

C'est précisément dans cette distinction que la plupart des enquêtes sur les redirections se trompent.

IPv4 et IPv6 la livrent différemment

IPv6 dispose d'un mécanisme analogue à l'intérieur de la découverte de voisins plutôt que dans ICMPv4, avec des formats de message et des règles de validation différents. Les concepts se ressemblent, les paquets non. Un filtre de capture écrit pour ICMP type 5 ne montrera rien sur un réseau IPv6, ce qui est parfois lu comme la preuve qu'aucune redirection n'a eu lieu.

Les réglages de politique sont eux aussi distincts, si bien qu'un hôte peut accepter les redirections IPv4 et ignorer celles d'IPv6, ou l'inverse.

Vérifiez les deux familles si le flux en question pourrait utiliser l'une ou l'autre.

L'acceptation est une politique de l'hôte, pas un fait du réseau

Sous Linux, l'acceptation des redirections est contrôlée par interface et globalement, et les valeurs par défaut diffèrent entre les rôles d'hôte et de routeur. Une interface de tunnel qui accepte les redirections est une conception étrange, car dans un tunnel point à point il n'existe pas de prochain saut alternatif significatif sur le même lien. Cela rend le réglage digne d'être lu plutôt que supposé.

Les réglages de redirection sécurisée restreignent encore quelles passerelles peuvent être crues.

Si vous durcissez un hôte, ce sont les réglages à examiner, et c'est aussi pourquoi deux machines sur le même réseau peuvent se comporter différemment. Modifiez-les comme une politique, pas comme un raccourci de débogage.

Ce qu'une redirection ne peut pas expliquer

Les routes spécifiques, les règles de routage par politique et les interfaces locales expliquent la plupart des chemins inattendus sans aucune redirection. Un préfixe plus spécifique, une règle correspondant à l'adresse source, ou un second défaut dans une autre table chacune de ces entrées supplantera la route que vous attendiez. Vérifiez-les d'abord, car elles sont déterministes et visibles.

Les captures périmées sont l'autre piège, car un client qui a changé de réseau a une passerelle locale différente.

Une ancienne redirection du rattachement précédent n'explique rien du chemin actuel, alors notez quelle interface reçoit maintenant le trafic de contrôle.

Vérifiez la route avant d'accuser le tunnel

Demandez au noyau quelle route il utiliserait pour la destination, puis comparez cela à la table que vous visiez. Si la réponse correspond à la table, aucune redirection n'a rien changé et l'enquête appartient ailleurs. Si elle ne correspond pas, cherchez une redirection en cache, une règle de politique ou une seconde table avant de supposer que le tunnel est en cause. La consultation est la vérité de terrain, et tout le reste est une histoire sur la façon dont on en est arrivé là.

Une redirection ne devrait jamais être la raison pour laquelle un chemin protégé devient silencieusement non protégé, et c'est pourquoi la politique d'acceptation relève de la revue de conception. La définition du RFC 792 reste la référence de ce que le message IPv4 est autorisé à dire.

Écrivez la consultation de route et l'horodatage de la capture ensemble, et la personne suivante pourra reproduire votre conclusion.