ipv6 imarchepô

Support Debian
#1

Bonjour,

J’utilise mon portable à la maison, en wifi, et au travail, en eth0. Des deux côtés je suis derrière une/des freebox.

À la maison, ça fonctionne au poil, un tour sur ce site me trouve bien connecté en ipv6.

Au boulot, je ne passe pas le test 2, la détection de l’adresse ipv6.

Pourtant j’en ai bien une, et même deux !

Oui, on a deux freebox sur notre réseau, toutes les deux fournissant une adresse ipv6, ce qui est je suppose la source de mon problème, mais je suis une quiche en réseau :mrgreen:

Voici quelques infos complémentaires :

$ ip -6 address show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2a01:xx:xx:xx:xx:xx:xx:xx/64 scope global dynamic valid_lft 86226sec preferred_lft 86226sec inet6 2a01:xx:xx:xx:xx:xx:xx:xx/64 scope global dynamic valid_lft 86226sec preferred_lft 86226sec inet6 fe80::xx:xx:xx:xx/64 scope link valid_lft forever preferred_lft forever

$ ip -6 route show default default via fe80::xx:xx:xx:xx dev eth0 proto ra metric 1024 expires 1607sec default via fe80::xx:xx:xx:xx dev eth0 proto ra metric 1024 expires 1607sec

J’ai déjà demandé à mon collègue informaticien de désactiver l’ipv6 d’une des freebox, mais ça ne semble pas envisageable.

Je navigue à vu en ipv4, mais en ipv6 c’est la brasse coulée :030

Est-ce qu’à priori mon problème vient de ces deux adresses et de ces deux routes ?

Si oui, est-il possible de configurer ma machine pour qu’elle ne demande qu’une seule ipv6, en blacklistant l’une des freebox ? Ou par un autre mécanisme ?

Je précise, à toutes fins utiles, que j’utilise wicd pour gérer mes connexions, et que j’exécute déjà un script post-connexion, je peux donc facilement y ajouter des commandes.

Usti

#2

C’est possible, si par exemple ta machine utilise le préfixe reçu d’une box mais la route par défaut reçue de l’autre. Tu peux le vérifier en supprimant une des paires adresse, route reçue d’un des routeurs. Informations que tu pourras déduire de la sortie de

ip -6 addr ls dev eth0 ip -6 route ls dev eth0 ip -6 route get 2000::
(Si tu veux les maquiller, stp fais en sorte qu’on puisse quand même distinguer les préfixes et les adresses)

#3

Pascal,

Voici les informations demandées :

$ ip -6 addr ls dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2a01:e35:2f51:xx:xx:xx:xx:xx/64 scope global dynamic valid_lft 86091sec preferred_lft 86091sec inet6 2a01:e35:3981:xx:xx:xx:xx:xx/64 scope global dynamic valid_lft 85881sec preferred_lft 85881sec inet6 fe80::222:64ff:fe53:dcaf/64 scope link valid_lft forever preferred_lft forever

$ ip -6 route ls dev eth0 2a01:e35:2f51:xx::/64 proto kernel metric 256 expires 86080sec 2a01:e35:3981:xx::/64 proto kernel metric 256 expires 86396sec fe80::/64 proto kernel metric 256 default via fe80::224:d4ff:fe57:3dfc proto ra metric 1024 expires 1786sec default via fe80::207:cbff:fe34:32c7 proto ra metric 1024 expires 1469sec

~$ ip -6 route get 2000:: 2000:: from :: via fe80::224:d4ff:fe57:3dfc dev eth0 src 2a01:e35:2f51:xx:xx:xx:xx:xx metric 0 cache

Usti

#4

Quelle buse, je pensais que les routes des préfixes indiqueraient l’adresse du routeur correspondant, mais bien sûr que non. Je pense qu’on peut quand même les relier en comparant les délais d’expiration des routes.
A priori 2a01:e35:2f51:xx::/64 est géré par fe80::207:cbff:fe34:32c7 et 2a01:e35:3981:xx::/64 est géré par fe80::224:d4ff:fe57:3dfc.
Or d’après la sortie d’ip route get, si je ne me suis pas trompé on peut voir que la décision de routage est “croisée” : l’adresse source par défaut appartient au préfixe d’une box alors que l’adresse de routeur par défaut est celle de l’autre box. Si chaque box filtre les adresses sources du trafic sortant pour ne laisser passer que le préfixe qu’elle gère, ce qui est probable, alors cela explique que cela ne fonctionne pas.
Tu peux le vérifier ponctuellement de deux façons :

  • en forçant l’adresse source 2a01:e35:3981:xx:xx:xx:xx:xx pour les commandes qui le permettent (ping6 par exemple, ou telnet (me souvient plus des options correspondantes, voir man)
  • en supprimant la route par défaut liée à fe80::224:d4ff:fe57:3dfc, ce qui forcera ta machine à utiliser l’autre, associé à l’adresse source par défaut (mais elle sera recréée à la prochaine annonce RA reçue qui peut arriver à n’importe quel moment, donc ne pas traîner.
#5

Bon, comme je ne suis pas doué, je n’ai pas trouvé l’option pour ping6 :116

Mais, en supprimant l’une des routes comme tu m’as indiqué, effectivement ça fonctionne nettement mieux, et test-ipv6.com/ me trouve bien connecté en ipv6 :041

Donc, la question qui reste, c’est est-il possible d’ignorer un routeur ipv6 ?

Sinon, je suppose qu’un script bash supprimant d’office l’une des routes fera aussi l’affaire.

Usti

#6

Le problème d’un script pour supprimer la route par défaut, c’est que les annonces de routeurs sont réémises périodiquement, ce qui a pour effet non seulement de recréer les routes supprimées mais aussi de modifier les délais d’expiration des routes et de durée de vie préférée des préfixes, ce qui peut inverser les préférences dans les choix de l’adresse source par défaut et du routeur par défaut.

Solution radicale : on devrait pouvoir filtrer ses annonces avec ip6tables.

J’ai regardé dans les paramètres IPv6 du noyau, je n’ai rien trouvé concernant une limitation du nombre de routeurs dont on accepte les annonces, ou une gestion des préférences. Seulement le nombre maximum d’adresses autoconfigurées, mais je ne suis pas sûr que ça suffise.

Il devrait néanmoins être possible avec du routage avancé de forcer le routeur par défaut en fonction de l’adresse source, mais je n’ai jamais essayé en IPv6. Quelque chose comme

ip -6 rule add from <prefixe1>/64 table 100 ip -6 route add <prefixe1>/64 dev eth0 table 100 ip -6 route add default via <routeur1> dev eth0 table 100
(répéter la même chose avec table 101, prefixe2 et routeur2)
Mais on s’éloigne de l’autoconfiguration…

#7

Bien vu, la route était effectivement revenue.

[quote=“PascalHambourg”]Solution radicale : on devrait pouvoir filtrer ses annonces avec ip6tables.

J’ai ajouté cette règle, et la route n’est pas revenue, cela me semble donc une bonne solution, du haut de ma totale inexpérience en réseaux :030

Je vais ajouter ça dans mon script post-connexion, et je teste en conditions réelles demain matin en embauchant.

Merci !

Je mettrais le sujet résolu demain matin si tout se passe bien.

Usti

#8

Le script post-connexion n’est pas forcément le meilleur endroit pour créer la règle.

  1. La règle ne doit être ajoutée qu’une seule fois après le démarrage, et pas à chaque fois que l’interface est activée.
  2. Idéalement la règle devrait être ajoutée avant que l’interface soit activée et non après, car une annonce RA indésirable pourrait être reçue entretemps puisque l’interface émet une sollicitation pour recevoir des RA lors de son activation.
#9

[quote=“PascalHambourg”]Le script post-connexion n’est pas forcément le meilleur endroit pour créer la règle.

  1. La règle ne doit être ajoutée qu’une seule fois après le démarrage, et pas à chaque fois que l’interface est activée.
  2. Idéalement la règle devrait être ajoutée avant que l’interface soit activée et non après, car une annonce RA indésirable pourrait être reçue entretemps puisque l’interface émet une sollicitation pour recevoir des RA lors de son activation.[/quote]
    Bon, je n’avais pas vu ça sous cet angle, mais effectivement ce n’est pas une bonne idée de mettre la règle dans un script post-connexion.

Je vais voir à remettre en route shorewall6, maintenant que j’arrive à utiliser le réseau au travail avec l’ipv6 d’activé :wink:

Je marque donc le problème comme résolu :smiley:, merci Pascal !

Usti