Auteur Sujet: Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?  (Lu 13605 fois)

0 Membres et 1 Invité sur ce sujet

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Bonjour,

J'aimerais vos conseils sur une évolution de mon réseau domestique et les possibilités qui me seraient offertes.

ce que j'ai actuellement:

J'ai une petite installation réseau à la maison.
Le détail est dispo dans mon wiki (https://github.com/nouknouk/ma-domotique/wiki/armoire-r%C3%A9seau), ça se résume globalement à:

- une freebox revolution server, dans une zone fibrée par Orange, avec un ONT séparé.
- un switch 16 ports manageable, TP-Link TL-SG1016DE
- un serveur (celeron J4105) qui sert essentiellement de serveur 'nas/àtoutfaire' (debian, what else)
- un second serveur qui sert de box domotique home made (debian, forever)

Tout ça dans une armoire réseau avec onduleur, et différents équipements connectés dont certains alimentés en PoE passif (caméras, AP WiFi, ...)

+ un point d'accès WiFi (Xiaomi Mi router 3), déporté au milieu de la maison ; il expose actuellement deux réseaux WiFi: un pour la domotique (N), l'autre pour les utilisation domestiques (AC): smartphones, laptop, ...

+ différents équipements, connectés en filaire (desktops, tv android), et en WiFi (laptops, smartphones, 1 cam sur 5, des ESP32 utilisés pour de la domotique, ...)


Tout ce qui concerne l'accès WAN, le DHCP, le routing, etc... est actuellement géré par la freebox serveur.


ce que je voudrais:

Avant tout supprimer complètement la freebox révolution serveur (le player étant déjà retourné dans son carton).

et puis:

- rendre étanche les deux sous-réseaux: domotique (critique en cas de piratage) vs. domestique (smartphones, laptops, ...) à quelques exceptions près, bien scopées. VLANs ?

- exposer un troisième réseau Wifi, dédié à l'accès au net pour les enfants (avec protections parentales, ...)

- garder un accès VPN à mon/mes réseaux internes depuis l'extérieur (actuellement la fbx serveur s'en charge + openVPN)

- quelque chose de suffisamment puissant pour ne pas brider les debits (accès au WAN à 1Gb notamment)

- minimiser la conso électrique de l'ensemble (c'est une des raisons de l'envie de dégager la freebox serveur)


quelles options pour mon projet ?

Actuellement, je vois plusieurs solutions 'high level', à affiner par la suite:

1. réutiliser mon serveur 'nas/àtoutfaire' comme point central du réseau, pour gérer l'accès au WAN, VPN, firewall, routing, controle parental, ...
=> J'aime pas trop cette approche SPOF: si ce serveur tombe, tout tombe dans la maison.

2. un troisième mini-serveur dédié à ces tâches ?
=> quelle config nécessaire pour toutes ces fonctionnalités (dont VPN,firewall, routing, ...), le Gb du WAN
=> quelle consommation électrique ?
=> quels efforts de setup + maintenance ?

3. un routeur dédié ?
=> un truc avec une cage SFP intégrée pour dégager l'ONT au passage ?
=> j'ai lu des noms: Netgear MS510TX, Microtik RB4011iGS+RM, franchement, je suis paumé.
=> avec suffisamment de port il pourrait même venir en remplacement de mon switch actuel ?
=> quelle consommation électrique ?

4. remplacer mon AP WiFi par un vrai routeur Wifi, pour assurer à la fois le WiFi et tout le reste (firewall, routing, ...)
=> Cet équipement, critique, serait quand même déporté physiquement de mon armoire réseau :-\
=> Je veux de l'open et du bidouillable, openWrt ?
=> quelle conso ?
=> quels modèles ?

en bonus: remplacer ma fbx révo par une freebox pop server ?
=> je reste dépendant de Free
=> je m'asseois sur le routing avancé, firewall, etc...
=> mais facilité de setup/maintenance ++ ?
=> quelle conso elle fait, la pop server ?



Voilà, beaucoup plus de questions que de réponses à mon niveau ; si vous avez des conseils, je suis preneur  ;D


Merci d'avance.

« Modifié: 27 septembre 2020 à 12:21:42 par nouknouk »

Douks

  • Abonné Orange Fibre
  • *
  • Messages: 190
Citer
J'aime pas trop cette approche SPOF: si ce serveur tombe, tout tombe dans la maison.
D'un côté, si ta box tombe aujourd'hui, plus rien ne fonctionne non plus ?

J'aurais quelque chose de similaire à faire, je partirai sur l'option 2. Serveur que tu mets en DMZ et qui potentiellement sera le premier et seul à bouffer.

Tu as pas mal de posts au sujet du remplacement de l'ONT par un routeur avec le SFP à l'intérieur. Globalement, ça semble plus ou moins compliqué en fonction du type de fibre que tu as. Tu as déjà gratté la dessus ?

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
salut,

tout d'abord merci pour ta réponse.

D'un côté, si ta box tombe aujourd'hui, plus rien ne fonctionne non plus ?
L'accès WAN, le DHCP, oui.
Mais le réseau local + le WiFi continue de fonctionner à peu près normalement (je pense).

La solution finale sera sûrement un 'SPOF': je ne vais pas dédoubler pour un risque finalement très faible (combinaison de "le routeur tombe + je suis physiquement loin de mon domicile pour intervenir").

je partirai sur l'option 2. Serveur que tu mets en DMZ et qui potentiellement sera le premier et seul à bouffer.

Mais il faut que ça marche en permanence "hors panne matérielle" ; c'est pourquoi j'aime moins l'option 'vrai serveur'. Car un serveur c'est un truc qu'on installe, qu'on update, etc... bref qu'on maintient ; un truc qui -par expérience- a plus de downtime qu'une boite dédiée, style un switch, un routeur

Et c'est plus complexe, plus la 'surface d'attaque / de failure' est grande. Exemples:

- c'est la raison qui a fait que j'ai dédoublé mes deux serveurs (un mini pour la domotique, uptime max, un autre pour 'le reste', qui aurait pourtant pu assumer les deux d'un coup)

- pour l'asservissement de la sirène de mon alarme: un arduino plutôt qu'un relais branché sur mon serveur domotique: un serveur peut planter (et laisser la sirène allumée 24h/24 pendant une semaine ?  :'( ), un arduino, plus basique, beaucoup moins de chances.

Tu as pas mal de posts au sujet du remplacement de l'ONT par un routeur avec le SFP à l'intérieur. ça semble plus ou moins compliqué en fonction du type de fibre que tu as. Tu as déjà gratté la dessus ?

J'ai juste commencé à regarder ; j'y ai compris que ma situation (ZMD, fibrée par orange, ONT séparé) n'est pas forcément la même qu'une ligne FTTH fibrée par Free. (et que je suis même pas sûr que je pourrais facilement extraire le SFP de l'ONT fourni par Free pour le mettre dans un routeur perso).

Maintenant, j'ai une grosse somme de choses à apprendre ; je le ferai, mais c'est l'objet de ce thread: commencer par cibler la/les solutions potentielles pour éviter de me perdre d'emblée.

A ce propos, j'ai encore vu une solution supplémentaire, intermédiaire entre le serveur et le routeur 'acheté tout fait': le Banana PI R64, pour une solution 'home made' (sur openWrt ?)


nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Quelques mois plus tard,
- j'ai acheté un TPLink MC220L pour connecter l'ONT de mon abonnement free fibre (ZMD 10G EPON) en direct
- vers un futur routeur à base de NanoPi R4S + OpenWrt.

Ce que j'ai fait pour le moment:

1- j'ai compris que chez Free on est soit:
  * dans une situation Free fibre en ZMD (mon cas), on a une connectivité IPv6 de base + encapsulation des paquets IPv4 dans l'IPv6 = 4rd.
  * soit avec un setup 'inverse' en ZTD (pas mon cas): une connectivité IPv4 de base + encapsulation des paquets IPv6 dans l'IPv4 = 6rd (?)

2- j'ai découvert OpenWrt avec l'image FriendlyWrt proposée sur friendlyarm.com

3- j'ai lu avec attention le post ici-même de clecle26 (merci à lui) pour un setup openWrt sans freebox, avec une IP (full stack) + 0.25 IP
    * + l'article de son blog: https://liberty.noknow.ovh/article/NoBox-Free
    * perso, mon objectif n'est d'avoir que l'IP full-stack, ça me suffira

3b- même lecture attentive du tuto pour Ubuquity: Tuto: Remplacer sa freebox (non Delta) par un routeur Ubiquiti en ZMD (10G-EPON)

4- j'ai compris qu'il me faudrait comme infos:
    * mon IPv4 full stack (visible dans l'interface "mafreebox.freebox.fr > Etat de la box" et/ou dans mon compte abonné sur free.fr)
    * de mon adresse MAC ; pas trouvé d'étiquette sur ma freebox, la seule que je connaisse est celle visible dans l'interface "mafreebox.freebox.fr > Etat de la box" (F4:CA:XX:XX:XX:XX)
    * de mon prefixe IPv6 (2a01:xxxx:xx:xxxx::/64)
    * d'une IP locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0"
    * l'IPv6 du border router côté free ? il vaut apparemment toujours "2a01:e00:29:200a::fffd"

5- pour OpenWrt, j'ai compris qu'il me faudrait installer le package 'map' pour le 4rd (besoin only pour l'IPv4 ou pour l'IPv6 aussi ?)
    * or l'image FriendlyWrt fournie ne contient pas les dépendance nécessaires => besoin de compiler mon propre OpenWrt.
    * sur le forum OpenWrt le 'work in progress' pour le support du NanoPi R4S dans OpenWrt

7- j'ai buildé mon image openWrt pour le NanoPI R4S
    * le fork d'openWrt incluant le WiP pour le NanoPi R4S: https://github.com/1715173329/openwrt-official/tree/nanopi-r4s (en attente de PR)
    * j'ai donc compilé mon image et je l'ai installée sur mon nanoPi R4S, en incluant le  packet "Network ---> map"
    * (pas bloquant mais) il faudra que je "use r8168-8.048.03 realtek kernel module(much better than r8169)" + repo GitHub pour le module kernel openwrt-r8168,
      => je ne sais pas encore comment on intègre ça au moment du build (si quelqu'un a un tuto / l'explication, je prends).
    * j'ai fait un premier setup de base pour mon LAN (= remplacer le DHCPv4 fourni jusqu'ici par la freebox server par celui sur l'interface lan de mon openWrt)

8- j'ai fait une première tentative de setup du wan juste pour l'IPv6 déjà
    * j'ai compris que côté wan, il faudrait passer par le VLAN 836
    * il me faudrait donc définir une nouvelle interface eth0.836 et la mettre en 'client DHCPv6'
    * pour que la requête DHCP soit acceptée, besoin de MAC spoofing avec la MAC de la freebox ci-dessus

MAIS ma config ne marche pas en l'état :'( (EDIT: ça a changé, cf ci-après)
- je vois quelques paquets RX et TX dans LuCi, et un root@openwrt:~# ping6 google.com plante.
- le tuto de clecle26 parle de modifier dans /etc/config/network une "config switch_vlan" existante mais la section 'switch_vlan' n'existe pas du tout chez moi ; la page 'Switch' dans LuCi non plus

=> est-ce parce que je n'ai pas un "VLAN-enabled switch hardware" ?

=> si je définis simplement mon interface en "eth0.836", ça devrait passer crème ? Quelque chose dans ce style ?
config interface 'wan6'
option ifname 'eth0.836'
        option proto 'dhcpv6'
        option reqprefix 'auto'
        option reqaddress 'try'
        option macaddr 'F4:CA:XX:XX:XX:XX'
        option mtu '1700'
        list dns '2001:4860:4860::8888'
        option peerdns '0'
=> avec quoi en plus / en moins ?
=> on est d'accord qu'au stade 'stack IPv6 only', on n'a pas (encore) besoin de 'map', qui sert à l'encapsulation IPv4 dans IPv6 (4rd) ? EDIT: oui
=> suis-je censé renseigner où l'IPv6 du border router côté free ? où ça ? EDIT: non, pas besoin
=> suis-je censé renseigner quelque part mon IPv6 locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0" ? EDIT: non, pas besoin

Bref, beaucoup d'interrogations à ce stade, je suis un peu paumé, toute aide serait la bienvenue.
« Modifié: 21 février 2021 à 23:43:37 par nouknouk »

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Quelques compléments d'infos:

- les logs me ressortent ça lors d'un restart de wan6:
root@OpenWrt:~# logread

Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is now down
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is disabled
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.045174] rk_gmac-dwmac fe300000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.058499] rk_gmac-dwmac fe300000.ethernet eth0: No Safety Features support found
Sun Feb 21 18:28:57 2021 kern.warn kernel: [ 2489.059196] rk_gmac-dwmac fe300000.ethernet eth0: PTP not supported by HW
Sun Feb 21 18:28:57 2021 kern.info kernel: [ 2489.059810] rk_gmac-dwmac fe300000.ethernet eth0: configuring for phy/rgmii link mode
Sun Feb 21 18:28:57 2021 daemon.notice netifd: Interface 'wan6' is enabled
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.464898] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.465738] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Network device 'eth0' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: VLAN 'eth0.836' link is up
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' has link connectivity
Sun Feb 21 18:29:00 2021 daemon.notice netifd: Interface 'wan6' is setting up now
Sun Feb 21 18:29:00 2021 kern.info kernel: [ 2492.467137] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.836: link becomes ready
Sun Feb 21 18:29:00 2021 daemon.err odhcp6c[5786]: Failed to send RS (Address not available)
Sun Feb 21 18:29:00 2021 daemon.err odhcp6c[5786]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Feb 21 18:29:01 2021 daemon.debug dnsmasq[1819]: listening on eth0.836(#15): fe80::f6ca:e5ff:fexx:xxxx%eth0.836 port 53
Sun Feb 21 18:29:02 2021 daemon.debug dnsmasq[1819]: listening on eth0(#2): fe80::691:62ff:fexx:xxxx%eth0 port 53

Niveau interface, j'ai le mac spoofing qui semble ok pour eth0.836, et le link local créé:
root@OpenWrt:~# ip address show eth0.836
9: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether f4:ca:e5:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f6ca:e5ff:fexx:xxxx/64 scope link
       valid_lft forever preferred_lft forever

côté eth0 (sans vlan), je récupère la MAC d'origine de l'interface du R4S, ce qui me semble logique:
root@OpenWrt:~# ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 04:91:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::691:62ff:fexx:xxxx/64 scope link
       valid_lft forever preferred_lft forever

Après un restart, j'ai quelques paquets échangés dans les deux sens sur l'interface wan6:
- RX: 6 pkts
- TX: 22 pkts

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Bon ... ça marche maintenant ... mais je ne sais pas pourquoi  ;D

J'ai fini par recompiler une nouvelle image incluant tcpdump pour faire du wireshark en remote ssh (depuis mon desktop).
Je lance alors une session wireshark, et là surprise: je vois plein de traffic !

Un refresh de la page LuCi lus tard, et à ma grande surprise: wan6 a enfin attrappé une IPv6 et j'ai mes deux nouvelles interfaces de map:
- WAN6_4_ (eth0.836)
- WAN6_4 (map-wan6_4) qui a attrappé une IPv4 'shared' 91.161.x.y

Il semblerait que l'activation du mode promiscuous quand je lance la session wireshark soit à l'origine de la solution.
Quelques tests plus tard, et effectivement: il me suffit d'activer le promiscuous sur eth0 pour que tout démarre comme par magie:
root@OpenWrt:~# ifconfig eth0 promisc

J'ai trouvé sur le forum d'openWrt un post relatant le même problème, sans qu'aucune explication ni solution ne soit fournie: IPv6 works only with wan in promiscuous mode

Bref, j'ai une connectivité IPv6 + IPv4 (partagée) qui fonctionne, je ne sais pas vraiment ni pourquoi ni comment.
Le souci initial serait-il dû à un problème de driver (cf. le "use r8168-8.048.03 realtek kernel module(much better than r8169)" de mon post précédent) ?

Un premier bench avec ce NanoPI R4S + un iperf3 donne:
iperf3 -c ping6.online.net -p 5200 -i 0 -t 60
Connecting to host ping6.online.net, port 5200
[  5] local 2a01:e0a:69:xxxx:xxxx:xxxx:xxxx:xxxx port 48306 connected to 2001:bc8:1::40 port 5200
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-60.00  sec  2.90 GBytes   415 Mbits/sec  290    453 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  2.90 GBytes   415 Mbits/sec  290             sender
[  5]   0.00-60.00  sec  2.89 GBytes   414 Mbits/sec                  receiver

Sur les 6 cores du Rockchip 3399, les n°5 et 6 (les deux seuls à monter en charge) se stabilisaient aux alentours de 50% pour le premier, 55% pour le second.
« Modifié: 21 février 2021 à 23:32:57 par nouknouk »

clecle226

  • Abonné Free fibre
  • *
  • Messages: 36
  • Tours (37)
Salut,

J’arrive trop tard de toute évidence, mais pour le VLAN: je sais pas le pourquoi du comment exactement, mais le VLAN logiciel n’est pas toujours présent par défaut. Je sais pas si c’est un paquet ou une dépendance à installer, mais elle n’est pas sur toutes les configurations même les « stock » du site Openwrt. :'(
C’est d’ailleurs pour cela que je suis allé chercher une ROM modifiée de la Xiaomi Mi 4A, car par défaut il n’y avait pas de VLAN sur la ROM stock. :-\

Tu as finalement réussi à accrocher l’IP full-stack?

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
merci pour ton feedback.

J’arrive trop tard de toute évidence, mais pour le VLAN: je sais pas le pourquoi du comment exactement, mais le VLAN logiciel n’est pas toujours présent par défaut.

Ma compréhension de l'histoire du switch_vlan (en tant que noob) semble bien reliée aux capacités du hardware sous jacent: certains matériels intègrent du hardware capable de jouer le rôle de switch entre différents ports physiques ; cela sans doute pour décharger le CPU principal de cette charge de travail (et donc avoir un routeur avec un CPU minuscule capable pourtant de switcher du Gb/s).

J'imagine que ce genre de 'switch' hardware se trouve dans du matos 'spécialisé' pour gérer du trafic réseau (un routeur/AP WiFi, genre le Xiaomi).  (*)

Dans ce cas de 'switching géré en hardware', il faut bien informer le hard sous-jacent que tel ou tel port doit tagger/détagger tel ou tel VLAN, d'où, j'imagine, la config additionnelle que tu présentes dans ton billet. Dans mon cas, avec le nanoPI, on est plutôt sur du hardware type 'ordi à vocation généraliste', donc sans ce genre de switching hardwareintégré.

Et donc avec mon nanopi, je n'ai pas eu ce besoin de configurer un 'switch hardware' qui n'existe pas ; eth0.836 dans mon wan6 +  mon firmware compilé avec 'map' inclus ont suffit pour faire fonctionner l'IPv6 + l'IPv4 partagée (modulo mon souci de promiscuous mode à set manuellement).

Tu as finalement réussi à accrocher l’IP full-stack?
J'ai fait une première tentative avec le patch de map.sh que tu as partagé (seconde version, pour la full stack only = celle qui fait un 'exit 1' sur le cas "::ffff")

J'ai manifestement un souci avec cette config: le CPU est à 30% en IDLE (<1% normalement) et j'ai eu la vague impression en faisant un htop que le script map.sh était ré-exécuté sans cesse.

Un rapide bench m'a alors confirmé qu'il y avait un souci, avec un download intermittent, et <3Mb/s de débit (là où j'ai 500Mb/s avec l'IP partagée).

Il était tard hier, j'ai fini par capituler, mais ce n'est que partie remise.
Si tu as une piste à explorer, je suis preneur.



(*) EDIT: ceci corrobore mon assertion: "Many embedded devices with more than 1 port contain a VLAN-capable switch (all routers with a WAN port have a VLAN-capable switch for example). Single-port devices and devices where there is an ethernet controller for each port (like for example PCEngines boards or most PC hardware in general) will have VLAN managed by OS drivers."
« Modifié: 22 février 2021 à 17:03:33 par nouknouk »

clecle226

  • Abonné Free fibre
  • *
  • Messages: 36
  • Tours (37)
J’ai manifestement un souci avec cette config: le CPU est à 30% en IDLE (<1% normalement) et j’ai eu la vague impression en faisant un htop que le script map.sh était ré-exécuté sans cesse.

Un rapide bench m'a alors confirmé qu'il y avait un souci, avec un download intermittent, et <3Mb/s de débit (là où j'ai 500Mb/s avec l'IP partagée).

… AH (comme dirait Denis Brogniart) …
Alors c’est normal que le script soit ré-exécute sans cesse, car Free renvoie les informations du tunnel de manière régulière (toutes les secondes au tout début, lors de l’accrochage IPv6 puis toutes les 30 secondes au bout de 10min. environ)

Mais mon IDLE est passé de 1% à 2% … Ce qui m’a paru extrêmement négligeable comme différence de consommation CPU… c’est pour ça que j’ai laissé tel quel.

Dans cette situation tu as 2 choix:
– soit tu supprime la ligne
        [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1et tu essayes de trouver une solution en faisant du NAT ou mwan3 (ce que j’ai pas réussi à faire, du coup je suis preneur si tu trouves la solution)

– soit tu termine le script BIEN PLUS en amont, pour éviter qu’il fasse des calculs inutiles (avec mapcalc) avec genre ce code:
        [ -z "${peeraddr##*2a01:e00:29:200a::ffff*}" ] && exit 1à la ligne 35.

Normalement tu devrais presque plus avoir de problème CPU avec la 2ᵉ option (enfin je dis ça au doigt mouillé)

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Un début de réponse: logread me sort les 3 lignes suivantes en boucle 20x par seconde:
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is setting up now
Mon Feb 22 19:25:35 2021 daemon.notice netifd: wan6_4 (31467): Interface wan6_4_ not found
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is now down

avec:
1) l'ajout dans map.sh:
        [ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
        [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
        RULE_DATA=`cat "/tmp/map-$cfg.rules"`

2) mon /etc/config/network:
config interface 'lan'
        option type 'bridge'
        option ifname 'eth1'
        option proto 'static'
        option ip6assign '60'
        list dns '8.8.8.8'
        list dns '8.8.4.4'
        list dns '9.9.9.9'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'

config device 'lan_eth1_dev'
        option name 'eth1'
        option macaddr YY:YY:YY:YY:YY:YY'

config interface 'wan'
       option ifname 'eth0.836'                 # L'interface sur laquel le tunnel va communiquer
       option delegate '0'                      # On desactive l'integration de l'IPv6 automatique sur cette interface, car on est en IPv4
       option tunlink 'wan6'                    # On remet l'interface sur laquel il communique
       option proto 'map'                       # Le protocole
       option type 'map-e'                      # Le sous-protocole (map-e pour nous, pas lw6over4)
       option peeraddr '2a01:e00:29:200a::fffd' # L'adresse du tunnel cote serveur
       option ipaddr '82.xx.xx.xx'              # L'ip full stack qui vous a ete attribue et qui se trouve sur votre espace client
       option ip4prefixlen '32'                 # Le prefixe de l'IP
       option ip6prefix '2a01:xxxx:xxxx:xxxx::'    # la plage/prefix IPv6 fournie par Free
       option ip6prefixlen '60'                 # La longueur du prefix
       option mtu '1500'                        # 1500, pour etre en dessous de l'IPv6 a 1700
       option encaplimit 'ignore'               # pas d'encapsulation limit
       option defaultroute '1'                  # definir comme route par defaut
       # defini, le nombre de port attribues, rang, etc... ici pour du full-stack.
       option ealen '32'
       option psidlen '1'
       option offset '16'
       option psid '65535'

config interface 'wan6_4'
        option delegate '0'                     # Pas d'IPv6
        option defaultroute '0'                 # On ne definit pas comme route par defaut
        option proto 'static'                   # On lui dit que c'est une adresse static(le protocole map s'occupera de faire le lien)
        option force_link '0'                   # pas besoin de forcer le lien
        list ipaddr '91.yy.yy.yy/32'            # Votre adresse IP ephemere.


config interface 'wan6'
        option ifname 'eth0.836'                # Correspond au num..ro de l'interface dans le routeur g..n..ralement 0 pour le WAN, parfois 1 suivi du vlan de Free.
        option proto 'dhcpv6'                   # correspond au protocole. Ici, du dhcpv6 standard.
        option reqprefix 'auto'                 # On le laisse demander la plage IPv6 obtenu (normalement un /60)
        option reqaddress 'try'                 # On laisse en try pas besoin de forcer la requete
        option macaddr 'XX:XX:XX:XX:XX:XX'      # On change l...adresse MAC du routeur pour celui de la freebox
        option mtu '1700'                       # On augmente le mtu standard, pour avoir un tunnel plus grand en IPv4
        list dns '2001:4860:4860::8888'         # On attribue les dns IPv6 de google. (optionnel), c...est juste le temps d'avoir un internet fonctionnel le temps de hijacking le dns (si vous le souhaitez)
        option peerdns '0'                      # On refuse les dns proposer par Free (il pue un peu la m****e), mais vous pouvez toujours les autoriser si vous le souhaiter.

Les interfaces dans LuCi ressemblent au screenshot ci-après en configuration avec 'wan6' seulement, et pas de path de 'map' (donc avec l'ip shared only):


clecle226

  • Abonné Free fibre
  • *
  • Messages: 36
  • Tours (37)
Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?
« Réponse #10 le: 22 février 2021 à 21:38:05 »
Je suis relativement perplexe ???
On a exactement la même configuration et pourtant j’ai bien l’IPv4 full-stack

– est-ce que tu as un fichier qui apparait des fois, qui s’appelle /tmp/map-wan.rules ?
– est-ce que tu as plus d’info avec ip a? (l’interfaces graphique n’affiche pas toujours tout s’il y a des bugs)
Tu es bien avec la version 19.07 de openwrt ?

---------
Pour ce qui est des logs netifd, j’ai la même. Il me log ça aussi un nombre incalculable de fois, mais mon CPU reste bien à 2% (j’ai pas encore trouvé où taper pour lui faire fermer sa g****e  :-X)

nouknouk

  • Abonné Free fibre
  • *
  • Messages: 38
  • yutz 57
    • Wiki ma domotique
Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ?
« Réponse #11 le: 23 février 2021 à 02:31:11 »
Quelques tests faits ce soir:
- j'ai recompilé la version FriendlyWrt pour le nanopi 4s avec le support de map (et kernel 5.10)
- pas la moindre amélioration concernant mon interface WAN qui ne voit pas les paquets taggués VLAN 836 tant que je ne passe pas eth0 en mode 'promiscuous'

J'arrive à accrocher mon IP full stack, mais ça semble dans les mêmes conditions qu'avec openWrt:

 * toujours les même logs incessants de netifd, qui semble setup puis kill 'wan_6_4' en boucle, faute de trouver 'WAN6_4_'

 * une charge CPU élevée en idle, c'est bien netifd qui mange le temps CPU (cf screenshots d'un htop ci-dessous: en haut avec netifd ; en bas avec netifd killed).

 * j'atteins avec mon IPv4 Free full stack (82.x) les 600mb/s sans trop sourciller sur un iperf3 vers un de mes serveurs dédiés (51.x).
Accepted connection from 82.xx.xx.xx, port 54322
[  5] local 51.xx.xx.xx port 5201 connected to 82.xx.xx.xx port 54324
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  59.0 MBytes   495 Mbits/sec                 
[  5]   1.00-2.00   sec  69.8 MBytes   585 Mbits/sec                 
[  5]   2.00-3.00   sec  69.9 MBytes   586 Mbits/sec                 
[  5]   3.00-4.00   sec  70.1 MBytes   588 Mbits/sec                 

A noter que si je supprime le patch dans map.sh (je n'ai plus possibilité d'avoir ma full stack mais) je n'ai plus les logs incessants.
il y a peut-être quelque chose à améliorer de ce côté là ?
        [ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
        [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
        RULE_DATA=`cat "/tmp/map-$cfg.rules"`
- Le 'exit 1' du patch ne serait-il pas trop brutal pour netifd ?
- N'y aurait-il pas possibilité de le laisser aller jusqu'au bout du map pour l'IP shared, quitte à lui rajouter une option pour la forcer en down ?





« Modifié: 23 février 2021 à 02:56:22 par nouknouk »