Pourquoi la découverte de voisins IPv6 échoue à travers un VPN routé

La découverte de voisins IPv6 appartient à un lien, et un tunnel routé est une frontière entre deux liens. Cette seule phrase explique presque tous les rapports sur un hôte distant qui répond par son adresse et qu’aucun autre moyen ne retrouve. Vérifiez la portée de l’adresse que vous testez avant de vérifier le tunnel. Une adresse locale au lien n’a de sens que sur son propre lien, et un groupe multicast de nœud sollicité est délimité de la même manière. Ni l’une ni l’autre ne traverse un routeur, ce qui explique qu’un ping vers une adresse globale puisse réussir alors que la découverte pour le même hôte échoue.

La portée passe avant la configuration

La sollicitation et l’annonce de voisin portent une limite de sauts de 255 et ne sont pas transmises, par conception. Le routeur entre votre tunnel et le LAN distant transmet les paquets IPv6 et ne relaie pas les messages de voisins en son nom. La cache de voisins de l’interface du tunnel ne contient donc que le pair et peu d’autre chose, ce qui est un comportement correct et non un défaut à corriger.

Une adresse locale au lien, comme une entrée fe80::, est aussi limitée à une zone, et le même texte peut désigner un autre hôte sur un autre lien. En tester une depuis l’autre côté du tunnel ne prouve rien, sinon que l’adresse est ambiguë.

Le piège est la supposition que le préfixe est sur le lien

Un hôte qui croit qu’un préfixe est sur le lien envoie une sollicitation de voisin au lieu de remettre le paquet à son routeur, et cela vaut aussi pour un /64 routé vers un site distant. Quand un tel préfixe arrive comme étant sur le lien, l’hôte demande au lien local un hôte qui vit ailleurs, et rien ne répond. Routez quelque chose de plus petit vers l’hôte distant, ou terminez le préfixe sur le routeur qui répondra pour lui.

Un /128 pour un seul service est l’arrangement le moins surprenant, et il supprime complètement l’ambiguïté. La spécification de découverte de voisins décrit l’ensemble des messages et l’indicateur sur le lien qui tranche la question.

Le pontage change les règles exprès

Quand le tunnel transporte des trames Ethernet, les segments distant et local ne forment plus qu’un lien, le multicast atteint les deux côtés et la découverte de voisins se comporte comme sur un commutateur. Les conséquences arrivent avec : inondation de broadcast et de multicast, détection d’adresses dupliquées à travers le pont et annonces de routeur qui fuient dans un segment qui ne devrait pas les voir. Le domaine de panne couvre désormais aussi deux sites. Rien de cela ne plaide contre le pontage, et chaque point est une raison de pontérer délibérément plutôt que par accident.

Faire passer un profil de TUN à TAP pour faire apparaître la découverte est le mauvais ordre des opérations. Le serveur, le client et le plan d’adressage doivent s’accorder, et les clients mobiles n’offrent aucune interface TAP, si bien qu’une telle conception fonctionne sur un portable et échoue sur un téléphone. Les proxys et relais de voisins sont des mécanismes distincts avec leurs propres exigences, et ils relèvent de l’arrangement documenté de l’administrateur réseau et non des réglages d’une application.

Testez avec l’adresse que l’application utilise

Confirmez la route avec ip -6 route get, inspectez l’entrée de voisin avec ip -6 neigh, puis confirmez le service sur le chemin routé. Le DNS et le chemin de retour sont des vérifications distinctes, et une entrée de voisin saine ne prouve ni l’une ni l’autre.

Si l’application exige une destination locale au lien ou fondée sur la découverte, c’est une conversation de conception et non un exercice de réglage, car aucun paramètre client ne fait fonctionner un mécanisme limité au lien à travers un routeur.

Notez quelle conception vous avez

Consignez s’il s’agit de routé ou de ponté avant l’incident, car les deux déploiements répondent différemment à ces questions et un ingénieur d’astreinte ne devrait pas avoir à le déduire d’un profil.

Lire une fois l’ensemble des messages retire la tentation d’expliquer une propriété de portée de lien comme un défaut du VPN, qui est le diagnostic erroné le plus coûteux dans ce domaine.