La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la box SFR par un routeur => Discussion démarrée par: quentind le 11 juin 2023 à 15:04:19
-
Salut à tous !
J'ai choisis la solution du double nat afin de connecter mon réseau à la RED SFR BOX 7.
J'ai donc la box reliée à un routeur OpenWrt, jusque là tout fonctionne bien, j'ai juste un peu lutté pour comprendre qu'il fallait ajouter une route ipv6 unicast vers ma box pour que les équipements en aval de mon OpenWrt puisse avoir ipv6 fonctionnel (sur le sous réseau ipv6 donné par la box).
J'ai décidé de m'équiper d'un Google Nest Wifi en mode bridge pour diffuser le réseau via WiFi. L'AP est configuré en mode bridge.
Tout fonctionne pour le mieux, à part un problème qui m'agace beaucoup, et je n'ai pas d'idée sur comment m'en débarrasser.
En effet, j'ai régulièrement des messages "ERR_NETWORK_CHANGED" sur mon navigateur, au cours de la navigation sur internet.
En regardant la conf réseau (je suis sur Ubuntu), je vois ceci en particulier :
inet6 fde7:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global deprecated dynamic mngtmpaddr noprefixroute
valid_lft 1610sec preferred_lft 0sec
J'ai également trouvé dans mon syslog de très nombreuses occurences de :
Jun 11 14:57:37 computer avahi-daemon[3439554]: Registering new address record for fde7:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx on enp0s25.*.
Jun 11 14:57:38 computer avahi-daemon[3439554]: Withdrawing address record for fde7:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx on enp0s25.
De ce que j'ai compris pour l'instant, c'est la google nest wifi qui envoie des paquets RA avec ces infos (alors même que la partie ipv6 est désactivée...).
Le problème c'est que le "preferred lifetime" est à 0sec, et donc elle est sans cesse entrain de se mettre à jour, entraînant une instabilité de la configuration réseau.
Est-ce que vous avez déjà rencontré ce phénomème ? Avez vous une idée qui me permette de régler ça ? Peut être en filtrant les paquets ICMPv6 ? Pour cela il faudrait que je crée un VLAN dédié au WiFI, ce que j'aimerais éviter...
Merci d'avance pour votre aide !
-
Salut,
Tu es sûr que c'est la nest qui envoie ça ? C'est pas l'openwrt plutôt ? Pour le lifetime, c'est très court et bizarre en effet... T'as fait une capture réseau pour voir ?
Si tu coupes l'ICMPv6, adieu l'ipv6 par contre, donc pas trop le choix.
Y'a des GUA sur les équipements en wifi au moins ? Car là tu nous montre une ULA qui est privée et non routable sur le net.
-
Salut à tous !
J'ai choisis la solution du double nat afin de connecter mon réseau à la RED SFR BOX 7.
tu as la box avec l'ONT intégré ?
-
Oui j'ai pas eu le choix, j'ai demandé au technicien si je pouvais avoir un ONT mais il m'a dit qu'il pouvait pas car tout était consigné et il était prévu que j'ai une box 7 avec ONT intégré dans son stock...
Et sinon oui je pense que c'est le Google Nest WiFi car j'ai essayé de la dégager temporairement du réseau (shut du port du switch sur lequel elle se trouve), et bim plus de problème ^^
Et plus d'adresse avec ce préfixe non plus !
J'ai vu que c'était une adresse locale, mais visiblement ça perturbe quand même le fonctionnement de l'ensemble du réseau. J'ai aussi eu le message "votre réseau est instable" lorsque j'utilise mon téléphone Android en WiFi.
Et oui le réseau IPV6 fonctionne bien, j'ai une IP globale, que j'utilise d'ailleurs sur un serveur ça fonctionne super bien...
-
je vais être un peu HS :
Si tu veux éviter le double NAT en dégageant la box SFR, tu peux trouver un ONT sur LBC, ex : https://www.leboncoin.fr/informatique/2347964409.htm
Tu te connectes en telnet dessus sur 192.168.4.254. et tu lui mets le mot de passe fibre qui doit etre indiqué dans l'interface du routeur SFR.
Tu pourras ainsi connecter l'ONT directement à ton routeur Openwrt. La box SFR te servira de routeur de secours.
J'ai acheté un ONT à 4€ la semaine dernière, au cas ou le mien lache, pour ne pas avoir à rester sans internet le temps d'en recevoir un nouveau. ;D
-
Ah ouai cool, merci pour le tuyau !
Je vais probablement regarder cette piste !
En attendant, concernant l'IPV6, j'ai mis une règle iptables en bloquant le traffic en provenance de la Google Wifi, et j'ai plus le problème. Mais bon ça règle le problème uniquement sur mon PC, et pas sur les autres équipements du réseau.
Je sens que je vais remplacer la Google Nest Wifi par une vraie borne wifi ^^
-
C'est normal , les appareils Nest de domotique utilisent une IPv6 ULA (privée) pour communiquer entre eux indépendamment de la configuration réseau existante.
Cela a été mentionné une fois ici et une explication plus complète se trouve la: https://forum.archive.openwrt.org/viewtopic.php?id=54161
Mais c'est curieux et pas trop normal que dans ton cas ton poste change de conf réseau.
-
C'est un peu bizarre parce que, qu'ils communiquent entre eux via IPV6, OK, mais ça continue à fonctionner sans le Google Wifi...
Et là ce qui pose problème c'est le Google Wifi qui se croit chez lui et se comporte comme un routeur alors même que je le configure en mode bridge ^^
-
De l'IOT qui envoie des RA et annonce des préfixes hors de controle de l'admin, tout seul comme ca ? Hmmm, nice! Ca vaut peut être le coup de les isoler sur leur propre VLAN.
-
Nan c'est le routeur de Google qui envoie les RA, mais bon il est configuré en bridge donc je suis moyen d'accord ^^
-
De l'IOT qui envoie des RA et annonce des préfixes hors de controle de l'admin, tout seul comme ca ? Hmmm, nice! Ca vaut peut être le coup de les isoler sur leur propre VLAN.
C'est visiblement de la merde en effet.
-
Perso je ne vois pas ou est le souci, ca permet un fonctionnement plug & play simple quelque soit la configuration réseau existante. C'est concu pour un usage grand public.
Y'a plein de Google Nest (Wifi, thermostats, etc) déployés dans le monde donc on peut supposer que cela ne pose pas de problème a la grande majorité sinon ils auraient changé ce comportement ?
y'a une norme (rfc 4862 , section 5.5.3) qui dit de "silently ignore the Prefix Information option" si les lifetime ne sont pas conformes a certaines valeurs.
Je dirais donc qu'a priori c'est plutot le poste Ubuntu de l'OP qui a un souci, il ne respecte pas cette norme s'il ignore pas ces annonces RA ?
T'as utilisé quel port du Nest pour le relier au LAN ?
-
Perso je ne vois pas ou est le souci, ca permet un fonctionnement plug & play simple quelque soit la configuration réseau existante. C'est concu pour un usage grand public.
Y'a plein de Google Nest (Wifi, thermostats, etc) déployés dans le monde donc on peut supposer que cela ne pose pas de problème a la grande majorité sinon ils auraient changé ce comportement ?
y'a une norme (rfc 4862 , section 5.5.3) qui dit de "silently ignore the Prefix Information option" si les lifetime ne sont pas conformes a certaines valeurs.
Je dirais donc qu'a priori c'est plutot le poste Ubuntu de l'OP qui a un souci, il ne respecte pas cette norme s'il ignore pas ces annonces RA ?
T'as utilisé quel port du Nest pour le relier au LAN ?
Je connaissais pas cette RFC, après ce qui m'embête c'est pas qu'ils utilisent l'IPV6 pour communiquer, juste qu'un bridge WiFi se comporte comme un routeur alors que je le configure pour ne pas faire ça. Je vois pas de raison pour qu'il se comporte ainsi. Comme je le disais, les éléments Google fonctionnent très bien en étant connecté à un routeur quelconque, pas nécessaire un Google Wifi.
Et ceci dit ça me surprendrait énormément que Ubuntu ne respecte pas une RFC officielle...
Et sinon j'utilise le port WAN pour me connecter à mon routeur. Effectivement je devrais peut être essayer le port LAN à la place ? Je me disais qu'en mode bridge il se comporterait de la même manière
-
On pourrait avoir une capture de ces RA ?
Pour ce qui est de la RFC 4862, il est dit que si preferred lifetime est plus grand que valid lifetime, il faut ignorer le préfixe. Hors ce n'est pas ce qui à l'air de se passer. Le pref est à 0 mais le valid est plus grand... donc tout le monde récupère quand même le préfixe. Ils auraient dû faire pref > valid ou jouer sur le flag A !
J’essaierais de faire une conf similaire avec radvd, voir si j'ai le même bug.
-
Pref = 0 et Valid > 0 : le prefixe est valide, doit être configuré sur les machines si on a bien le flag A, mais il est deprecated donc il faut éviter de l'utiliser pour des nouvelles connexions.
Ils émettent bien router lifetime = 0 ?
Miser sur le respect des gardes fous spécifiés dans une RFC me semble quand même très téméraire pour ne pas dire autre chose. Si on veut faire de la comm locale et automatique entre devices IoT, il y a plusieurs méthodes qui ont prouvé leur efficacité à grande échelle et moins intrusives que de mettre le bazar dans un réseau existant:
a) utiliser les adresses link-local, avec détection et potentiellement comm en multicast,
b) annoncer un préfixe ULA seulement si aucun autre préfixe n'est présent sur le réseau,
c) si on veut un réseau sur lequel on peut tout faire, créer un réseau mesh wifi dédié pour la comm IoT.
Il y a probablement d'autres facons de faire. Apple fait une combinaison de a) et b) pour AirPrint, AirPlay et autres (utilise un prefixe GUA/ULA si présent, sinon utilise les adresses link-local), mais n'annonce pas de préfixe de lui-même.
J'ai vu d'autres devices faire c) pour ne pas dépendre de la présence ou impacter un réseau existant.
-
Oui on peut discuter la pertinence de leur choix, j'imagine qu'ils ont du réfléchir longuement a la question.
Aussi ce qui est curieux c'est que cela perturbe Firefox sur Ubuntu. Je serais curieux de voir ce que cela donne sur d'autres OS/Navigateur.
Sinon contacter le support Nest pour voir si y'a un pas une manip cachée possible.
-
Oui on peut discuter la pertinence de leur choix, j'imagine qu'ils ont du réfléchir longuement a la question.
Oh, tu sais, dans l'embarqué/IoT, plus ca va plus on se demande... Et j'entends de moins en moins de bien de Nest depuis leur rachat par Google.
Un temps, j'ai failli bosser chez eux sur ces sujets là justement :)
Aussi ce qui est curieux c'est que cela perturbe Firefox sur Ubuntu. Je serais curieux de voir ce que cela donne sur d'autres OS/Navigateur.
En effet, Firefox devrait respecter le source address selection algorithm et utiliser le préfixe GUA en priorité. Peut-être une modif faite dans /etc/gai.conf ?
-
J'ai l'impression que comme la conf ipv6 change régulièrement avec ces RA en nombre, ça impacte la stabilité de la connexion. Même c'est de l'ordre de la micro-coupure, dès que la liste est complète il utilise toujours la GUA en priorité.
Je vous met ici un exemple des RA
J'ai déjà sollicité le support de Google, mais je m'attends pas à grand chose...c'est plutôt grand public ^^
-
WTF ?!
Tu as bien une seule nest ? Pourquoi diable y'a 2 link locales avec des lifetime différents qui annoncent la même route ?
Le premier c'est l'openwrt (b8c9) ? Mais dans ce cas il a pas l'air bien configuré (on devrait avoir la GUA aussi ou t'as un autre routeur pour les ULA ?)... Et on dirait que la nest (1230), copie la route et l'annonce à son tour, j'ai jamais vu ça.
Et après on s'étonne que ça déconne...
-
Alors en fait de ce que je vois les deux MAC 1230 et b8c9 sont originaires du Google Wifi. J'en ai qu'un seul oui...
Et oui j'ai deux préfixes qui sont diffusés par la Google Wifi, en ULA...
-
De mieux en mieux... C'est bien la peine de faire un préfixe spécial mais d'en diffuser un autre bien valide à côté depuis une autre link local ! ::)
Mais surtout que vient faire cette route au milieu qui ne correspond à rien du tout ?
Vraiment y'a rien qui va avec ce truc. Je ne comprend absolument pas ce qu'ils ont voulu faire avec une conf pareille :o
EDIT : J'ai testé de mon côté un préfixe avec preferred lifetime à 0 et je n'ai pas eu d'erreur sur Firefox. C'est toujours la même IP qui revient ? Dans ce cas, le fait de jouer sur les privacy extensions n'a pas d'effet on dirait.
Jun 13 17:52:53 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:52:54 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Jun 13 17:53:28 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:53:29 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Peux-tu vérifier que l'erreur se produit bien lorsque le timer de l'adresse se réinitialise ? avec un watch -n 1 ip a Par contre attention ça n'attend pas d'être à 0s y'a une marge.
-
étrange indeed ;)
y'a comme qui dirait un 3eme lan dont la route est annoncée par ce routeur wifi
y'a un RA prefix avec litefime a 0 donc celui la est a ignoré
l'autre par contre non...
Il est branché comment ton Google Wifi ? c'est un modele avec 2 ports Ethernet, un lan , un wan ? t'as bien mis le port lan vers ton routeur ?
t'as un wifi invité ? un meshing ?
-
Et si la route inconnue était le préfixe ULA de l'openWRT ? Donc ça veut dire que ça serait annoncé en triple ?! Vu que je suppose que l'OWRT envoie aussi ses RA avec GUA + ULA...
Si on résume on aurait donc un nest en "bridge" qui laisse passer le trafic mais récupère au passage les infos des RA qu'il voit passer, pour annoncer lui-même une route vers un préfixe ULA qui n'est pas censé gérer.
C'est seulement prévue dans une quelconque RFC ce genre de fonctionnement surréaliste ?
EDIT : @quentind : Tu reçois bien les RA de l'OWRT sur tes appareils en wifi au moins ?
-
De mieux en mieux... C'est bien la peine de faire un préfixe spécial mais d'en diffuser un autre bien valide à côté depuis une autre link local ! ::)
Mais surtout que vient faire cette route au milieu qui ne correspond à rien du tout ?
Vraiment y'a rien qui va avec ce truc. Je ne comprend absolument pas ce qu'ils ont voulu faire avec une conf pareille :o
EDIT : J'ai testé de mon côté un préfixe avec preferred lifetime à 0 et je n'ai pas eu d'erreur sur Firefox. C'est toujours la même IP qui revient ? Dans ce cas, le fait de jouer sur les privacy extensions n'a pas d'effet on dirait.
Jun 13 17:52:53 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:52:54 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Jun 13 17:53:28 renaud-VirtualBox avahi-daemon[608]: Registering new address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.*.
Jun 13 17:53:29 renaud-VirtualBox avahi-daemon[608]: Withdrawing address record for fdd1:a111:c111:0:e081:daed:ee0a:1a17 on enp0s3.
Peux-tu vérifier que l'erreur se produit bien lorsque le timer de l'adresse se réinitialise ? avec un watch -n 1 ip a Par contre attention ça n'attend pas d'être à 0s y'a une marge.
en fait c'est bizarre le timer est toujours à 0sec quand je fais un ip a...
L'erreur se produit de façon très très rare, c'est difficile à reproduire mais je suppose que c'est quand le chargement d'une page se produit pile au moment de la prise en compte d'une route ipv6 ?
-
étrange indeed ;)
y'a comme qui dirait un 3eme lan dont la route est annoncée par ce routeur wifi
y'a un RA prefix avec litefime a 0 donc celui la est a ignoré
l'autre par contre non...
Il est branché comment ton Google Wifi ? c'est un modele avec 2 ports Ethernet, un lan , un wan ? t'as bien mis le port lan vers ton routeur ?
t'as un wifi invité ? un meshing ?
j'ai juste configuré le wifi en mode bridge, disable ipv6. j'ai essayé avec le port LAN ou WAN, même combat ^^
pas de wifi invité ni de mesh
-
Et si la route inconnue était le préfixe ULA de l'openWRT ? Donc ça veut dire que ça serait annoncé en triple ?! Vu que je suppose que l'OWRT envoie aussi ses RA avec GUA + ULA...
Si on résume on aurait donc un nest en "bridge" qui laisse passer le trafic mais récupère au passage les infos des RA qu'il voit passer, pour annoncer lui-même une route vers un préfixe ULA qui n'est pas censé gérer.
C'est seulement prévue dans une quelconque RFC ce genre de fonctionnement surréaliste ?
EDIT : @quentind : Tu reçois bien les RA de l'OWRT sur tes appareils en wifi au moins ?
Non non mon OpenWRT n'annonce que le prefixe que j'ai configuré, c'est à dire un prefix public.
Je reçois bien les RA de OpenWRT sur mes appareils en wifi !
-
Salut à tous ! Petit UP sur ce sujet pour vous tenir au courant ! Le support Google a visiblement modifié quelque chose au fonctionnement du Google Wifi, ils ont également remplacé mon appareil. Et magic ! Je n'ai plus d'IPv6 distribués depuis le Google Wifi !
Affaire close donc !