Le ping vers votre pair de tunnel IPv6 échoue ? Vérifiez l’adresse ::

Une extrémité de votre tunnel IPv6 ping l’autre, et une seule direction répond jamais. L’interface est active, la route semble correcte, et rien dans le journal ne l’explique. L’adresse que vous avez attribuée est l’adresse anycast du routeur de sous-réseau, qui n’est pas du tout une adresse d’hôte, et sur une liaison à deux extrémités elle a exactement une cible de livraison : l’émetteur. Aucune valeur de délai ne répare cela, car l’adresse ne fait pas ce que vous croyez.

Le symptôme qui désigne l’adresse

Tous les hôtes de la liaison répondent sauf celui dont l’identifiant d’interface est tout à zéro. Un paquet adressé à cette forme est livré par définition à un routeur du sous-réseau, donc sur un tunnel point à point il revient à la machine qui l’a envoyé. De l’extrémité lointaine, cela se lit comme un pair injoignable ; de l’extrémité proche, comme un silence. Remplacez par un autre identifiant du même préfixe et le symptôme disparaît sans aucun autre changement, et c’est la confirmation à obtenir avant de toucher aux routes.

L’identifiant tout à zéro est réservé comme anycast

La RFC 4291 conserve l’identifiant d’interface tout à zéro comme adresse anycast du routeur de sous-réseau, donc un /64 comme 2001:db8:4a::/64 ne contient aucun hôte utilisable à 2001:db8:4a::. La réservation mérite sa place : les annonces de routeur et la découverte de voisins adressent cette forme, et un routeur répond pour le préfixe qu’il sert. Attribuer cette valeur à une extrémité de tunnel donne un rôle de routeur à une feuille, et c’est pourquoi rien ne revient. Tout autre identifiant du préfixe fonctionne comme hôte, donc la réparation est généralement un chiffre.

Traitez la réservation comme un rôle que vous n’avez pas le droit d’occuper depuis une extrémité de tunnel, plutôt que comme une bizarrerie à contourner par une route.

Attribuez des adresses d’hôte et routez le préfixe

Choisissez ::1 et ::2 pour les deux extrémités, ajoutez-en une avec ip -6 addr add 2001:db8:4a::2/64 dev tun0, puis routez le préfixe distant au lieu de tenter de l’adresser. Une route pour 2001:db8:4a::/64 par le tunnel rend le côté distant joignable ; l’adresse seule ne fait que configurer l’interface locale.

Pour un tunnel complet, il y a une troisième étape, une route par défaut pour l’unicast global via l’appareil, qui est l’équivalent IPv6 d’envoyer tout dans le tunnel. Omettez-la et IPv6 continue d’utiliser la liaison physique pendant qu’IPv4 voyage dans le tunnel, donc l’hôte fuit précisément le trafic que vous croyiez couvert. Confirmez avec ip -6 route get 2001:4860:4860::8888 et lisez quel appareil elle nomme au lieu de supposer la réponse.

Le multicast est refusé avant le routage

Android valide les adresses et les routes pour VpnService.Builder via LinkAddress, et ce constructeur refuse le multicast d’emblée. Donnez-lui un préfixe multicast comme route et le résultat est un échec de paramètres LinkAddress incorrects plutôt qu’une route, ce qui est une réponse de validation et non de réseau. Le refus correspond au medium : un périphérique tun point à point n’a pas de multicast de couche liaison, donc une route de groupe dessus n’a pas de modèle de livraison à installer. Les adresses de groupe sont créées et consommées par la pile elle-même plutôt que configurées à la main.

Les adresses IPv6 all-nodes et solicited-node relèvent de la même règle. L’interface les porte parce que la pile les y a mises, non parce qu’une politique les visait.

Ce qu’un tunnel peut porter à la place

Déplacer la découverte multicast à travers un tunnel exige une couche qui comprend l’appartenance aux groupes : un pont TAP présentant un segment Ethernet, un relais au niveau applicatif ou un protocole de routage auquel on dit explicitement vers quels pairs répliquer. Rien de cela n’existe dans le modèle VpnService, où l’application lit et écrit des paquets et n’a aucun appel qui rejoigne un groupe pour le tunnel. Soit vous ajoutez le composant qui comprend les groupes, soit vous retirez l’exigence de la conception.

L’unicast, en revanche, ne demande rien de plus que les adresses et routes ci-dessus, c’est pourquoi on attend généralement des tunnels qu’ils le portent, puis on les blâme quand un protocole de découverte échoue.

Trois vérifications avant d’attribuer quoi que ce soit

Confirmez que l’adresse n’est pas la forme anycast, confirmez qu’elle n’est pas multicast et confirmez que le préfixe est routé et non simplement attribué à l’appareil. Envoyez ensuite votre test vers une destination qui est un véritable hôte, car un ping visant l’adresse anycast mesure l’émetteur et ne dit rien du chemin. Conservez ces trois vérifications dans le journal des changements pour que le prochain déploiement ne les redécouvre pas.

Une route que la plateforme n’a jamais installée ne se débogue pas en attendant plus longtemps, et une adresse qui n’a jamais été un hôte ne se répare pas avec un meilleur ping.