La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Freebox par un routeur => Discussion démarrée par: clecle226 le 11 février 2021 à 09:01:44
-
Bonjour,
********************
Le tuto est valable jusqu’au 2 avril 2022. Ayant changé d’opérateur, je ne suis pas en mesure de maintenir le tuto. N’hésitez pas à demander aux autres personne si vous rencontrez des difficultés.
*********************
Je vais vous expliquer comment obtenir (difficilement) une IPv4 full-stack + 1/4 d’IPv4 + IPv6 /60 chez Free en zone ZMD
Le réseau de Free en ZMD est en 10G-EPON en infrastructures et du 4rd en guise de protocoles de communication IP, c’est-à-dire que le réseau est déjà en full IPv6, mais on peut tout de même récupérer une IPv4 à travers un tunnel point à point d’IPv6. Le serveur de réception IPv6 fait le travaille d’envoyé le paquet IPv4 encapsulé sur le réseau IPv4.
Pour pourvoir vous passez de la Freebox, vous devrez être sur un ancien modèle de Freebox (Révolution ou Mini 4k). Dans les anciennes versions, vous n’avez qu’un port SFP au cul des box et par conséquent, ils fournissent un ONU qui convertit le SFP+ en SFP.
Vous devez donc avoir ce module-là :
(http://IMG6.jpg)
Et vous le brancher sur un convertisseur optique <-> RJ45, type TP-Link MC220L :
(http://IMG7.jpg)
Je rentrerai pas dans les détails techniques sur le forum, si vous souhaiter avoir plus d’explication techniquement, je vous conseille mon article de blog qui explique les détails: https://liberty.noknow.ovh/article/NoBox-Free (https://liberty.noknow.ovh/article/NoBox-Free)
ssh root@192.168.1.1
opkg update
opkg install nano map
Vous modifier le fichier /lib/netifd/proto/map.sh:
Vous rajouter ces lignes entre les lignes 66 et 67 (après "echo $RULES_DATA" et avant "eval $RULE_DATA"):
[ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i 's/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=2a01:xxx:xxx:xxx:0:ffff:ffff:0/' /tmp/map-$cfg.rules
RULE_DATA=`cat "/tmp/map-$cfg.rules"`
--------------------------------------------------
Vous modifier le fichier /etc/config/network, pour rajouter un VLAN 836
Si il s'agit d'un VLAN logiciel, vous changer le bloc switch_vlan du WAN avec:
config switch_vlan
option device 'switch0'
option vlan '836'
option vid '836'
option ports '4t 6t'# Adapter avec votre config déjà existante
Si il s'agit d'un VLAN géré par le materiel:
config device
option type '8021q'
option ifname 'wan'
option vid '836'
option name 'vlanWAN'
option macaddr '70:FC:xx:xx:xx:xx' #MAC de votre Freebox
(dans ce cas-là, l'ifname sera vlanWAN)
---------------------------------------------
Vous remplacer les blocs WAN et WAN6 par cela:
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 '70:FC:8F: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.
config interface 'wan'
option ifname 'eth0.836' #L'interface sur laquel le tunnel va communiquer
option delegate '0' #On désactive l'intégration 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 (on a le choix entre map-e map-t et lw6over4, mais on est sur du map-e pour nous)
option peeraddr '2a01:e00:29:200a::fffd' # L'adresse du tunnel côté serveur
option ipaddr '82.xx.xx.xx' #L'ip full stack qui vous a été attribué et qui se trouve sur votre espace client
option ip4prefixlen '32' #Le préfixe de l'IP
option ip6prefix '2a01:xxx:xxx:xxx::' #Votre plage/préfix IPv6
option ip6prefixlen '60' #La longueur du préfix
option mtu '1500' # Le mtu que l'on met à 1500, c'est pour cela qu’on met celui de l'IPv6 à 1700
option encaplimit 'ignore' #pas d'encapsulation limit
option defaultroute '1' # définir comme route par défaut (à votre convenance)
################ plein d’option au hasard ########
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
#################################################
Vous rajouter un bloc dans ce fichier:
config interface 'wan6_4'
option delegate '0' #Pas d'IPv6
option defaultroute '0' #On ne définis pas comme route par défaut
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.xx.xx.xx/32'#Votre adresse IP éphémère.
Remplacer la totalité du fichier /etc/config/mwan3 par cela:
config globals 'globals'
option mmx_mask '0x3F00'
option rtmon_interval '5'
##############La déclaration des 2 interfaces#################
# Des options qui permettent de savoir s’il y en a une qui est HS
# Normalement dans notre cas, les 2 sont UP ou DOWN en même temps, mais dans le cas d’une connexion 3g de secours, cela peut être utile
config interface 'wan'
option enabled '1'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
list track_ip '208.67.222.222'
list track_ip '208.67.220.220'
option family 'ipv4'
option reliability '2'
option count '1'
option timeout '2'
option failure_latency '1000'
option recovery_latency '500'
option failure_loss '20'
option recovery_loss '5'
option interval '5'
option down '3'
option up '8'
config interface 'wan6_4'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
list track_ip '8.8.4.4'
list track_ip '8.8.8.8'
list track_ip '208.67.222.222'
list track_ip '208.67.220.220'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '2'
option interval '5'
option failure_interval '5'
option recovery_interval '5'
option down '3'
option up '3'
# On redéclare les interfaces en tant que membre avec un poids plus important pour l'IP éphémère pour que ce soit celle-ci qui soit utilisée en premier.
# On peut redéclarer plusieurs fois les interfaces avec des poids et des metrics différent pour pourvoir créer différentes règles.
config member 'wan_member'
option interface 'wan'
option weight '1'
option metric '2'
config member 'wan6_4_member'
option interface 'wan6_4'
option weight '2'
option metric '1'
# On créer des règles de fonctionnement
# La première c'est qu'on utilise l'interfaces IP éphémères en priorité absolue puis ip fixe en fail over. On utilise la table de routage par défaut si ça fonctionne pas.
# La deuxième consiste à dire qu'on utilise uniquement l'IP fixe (règles pour le serveur)
config policy 'then_half_full'
list use_member 'wan_member'
list use_member 'wan6_4_member'
option last_resort 'default'
config policy 'full_only'
list use_member 'wan_member'
option last_resort 'default'
# Ensuite on attribue les règles à des adresses IP source ou de destination
# ici, le serveur utilise la règle full_only, tandis que le reste de la maison utilise la règle then_half_full.
config rule 'Server'
option src_ip '192.168.XX.XX' #L'ip local de votre serveur
option proto 'all'
option sticky '0'
option use_policy 'full_only'
option dest_ip '0.0.0.0/0'
config rule 'All'
option proto 'all'
option sticky '0'
option use_policy 'then_half_full'
option dest_ip '0.0.0.0/0'
Et voilà vous avec 1,25 IPv4 et une plage /60 de l’IPv6
Si vous avez des questions, je vous conseille de lire d’abords l’article de blog qui est beaucoup plus détaillé, mais vous pouvez également poser la question sur le forum ^^
EDIT: mwan3 ne fonctionne pas. J'ai une solution pour faire fonctionner l'IPv4 FullStack.
Pour cela il faut modifier le fichier map.sh de cette façon:
vers la ligne 66, il faut rajouter 2 lignes:
echo "$RULE_DATA" >> /tmp/map-$cfg.rules
+
+ [ -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
+ RULE_DATA=`cat "/tmp/map-$cfg.rules"`
+
eval $RULE_DATA
Vers la ligne 135
Remplacer la ligne:
proto_add_ipv4_route "0.0.0.0" 0par:
[ ! -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0Cela permettra d’empêcher le routeur d’utiliser l’IPv4 partagé comme route par défaut... C’est le seul moyen que j’ai trouvé d’avoir une connexion stable.
-
Bonjour clecle226, je suis très interessé par ton article mais le lien semble ne pas être bon ?
Merci
Sylvain
-
Mais c'est parfait tout ça !
Moi qui voulait prendre le temps de le faire. Voilà un tuto (rapide certe) mais avec les paramètres.
A préciser:
- c'est sous openWRT et uniquement fibre
- à vérifier s'il existe une compatibilité avec l'adsl (c'était le cas pour le VDSL en 6rd)
- expliquer rapidement qu'il faut prendre un tcpdump -xx et quoi récupérer d'où.
Sinon j'ai toujours les même questions:
- est-il possible de faire fonctionner la mini4k sans son server ?
- est-ce qu'il existe des boitiers ONU 10G/1G compatible avec le réseau chez Free (et comment récupérer les SLID sur le boitier convertisseur SFP+/SFP ?) ?
-
@sylv1s Ha ba heu oui… effectivement… j’arrive pas à trouver la stabilité avec mwan3 pour l’instant (je redémarre la box tout les 2 jours). C’est pour ça que mon site était HS. Mais normalement, maintenant c’est bon.
@Fuli10
– Je viens de le préciser dans le titre pour openwrt, après c’est relativement explicite que c’est pour de la fibre (ZMD, ONU, SFP…)
– Normalement oui, c’est compatible ADSL/VDSL, sans certitude, mais l’infrastructure de Free semble être partout la même avec soit du 4rd, soit du 6rd. (D’après les messages que j’ai pût trouver ici et là sur ce forum)
Mon tuto ne marche que pour du 4rd, mais comme Free essaye que 100% de sa population ais une IPv6, il est fort probable que l’on soit sur une grande majorité de 4rd
– Ba perso, j’ai eu besoin de tcpdump (couplé à wireshark) pour trouver les infos, mais en soi. Je donne toutes les infos nécessaires, donc pas spécialement besoin que les autres fassent un tcpdump. Mais sinon pour les détails, j’ai tout répertorier mes péripéties sur mon blog.
Les personnes qui suivent le tuto ont uniquement besoin de récupérer l’adresse IPv4 full-stack renseigner sur leur espace client.
– Pour l’instant non, pas de box tv mini4k fonctionnel. Il faudrait que je place un mitm entre la Freebox server et le player, mais j’ai un peu la flemme, car il faudrait que je re-bouge les meubles et tous… mais je le ferai peut-être à l’occase.
– Je me pose la même question, je suis en train de voir pour essayer de récupérer le SLID, car en soi si je trouve un SFP compatible je pourrais me passer de leur big ONU. Mais c’est pas ma priorité dans mes projets. Pour l’instant j’essaye de stabiliser ma connexion au maximum et d’optimiser la communication entre le routeur et mon serveur.
-
Bonjour,
Après quelques jours de test, je me suis résigné à abandonner l’IPv4 1/4, car mon routeur n'arrêtais pas de se déconnecter de tous les réseaux (les 2 IPv4 et l'IPv6), littéralement, toutes les 5 minutes.
N’arrivant pas à trouver la moindre stabilité, avec ou sans mwan3 (voir blog) j’ai modifié le patch du script 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"`
Avec cette configuration, vous n’avez plus que l’IPv4 FullStack et la plage IPv6. Vous allégez votre système, car vous n’avez plus besoin mwan3.
Cordialement.
-
Salut,
merci infiniment pour ce tuto, ;D
ça fait justement quelques mois que je réfléchis à mettre tout ça en oeuvre (https://lafibre.info/materiel-informatique/degager-la-freebox-serveur-routeur-wifi-firewall-que-me-conseillez-vous/msg797957/#msg797957).
J'ai vu sur ton blog que tu t'amusais avec du Xiaomi et quelques autres petites cartes.
De mon côté, dans les cartons, j'ai:
- un Xiaomi Mi 4A Gigabit (juste passé sous openWrt) que je pensais n'utiliser que comme AP WiFi (avec pour objectif des SSIDs, multiples, VLAN séparés: SSID adultes, enfants, domotique, guest, ...)
- le fameux TP-Link MC220L
- un NanoPi R4S (https://www.friendlyarm.com/index.php?route=product/product&product_id=284) acheté en prévision pour remplacer ma freebox révo, à la fois pour le routage, mais également firewall + serveur VPN + DHCPd + DNS + le café + ...
J'avais déjà des doutes sur la capacité au R4S à tenir le Gb/s de la fibre (btw: un super billet ici (https://www.stupid-projects.com/benchmarking-the-nanopi-r4s/) sur le R4S), donc j'imagine mal le Xiaomi Mi 4A tenir un gros débit (surtout avec l'encapsulation 6rd).
Tu as un retour sur ce point ? (même à la grosse loulouche)
Sinon, ton avis global sur mon idée de base (Xiaomi 4AGb pour l'AP WiFi + R4S comme routeur + couteau suisse) ?
-
Salut,
Alors en vrai on atteint pas le gigabit avec la Xiaomi Mi A4, mais on atteint sans difficulté les 300 Mbit…
Le truc, c’est que je suis pas spécialement sûr que ce soit dû à la Xiaomi, plutôt que au réseau Free…
Avec la Freebox, j’avais pas spécialement une meilleure connexion… ce qui me met un doute sur la capacité du réseau. Et il y a également l’ONU qui ralentit encore plus le débit.
Je sais que ce que j’ai fait est pas bien, remplacer une box qui fait tout (Freebox), par une autre box qui fait tout (Xiaomi)… Mais le problème se situe autre part. Car la Xiaomi en as encore sous le pied en l’utilisant comme routeur, résolveur DNS (over https), VPN de réseau local et point d’accès Wifi… L’utilisation de la mémoire vise se situe autour de 60% et dans les environs de 2% du processeur. Donc pas trop trop de soucis avec les ressources.
Après tout dépend de l’utilisation prévue:
– Si tu penses uniquement à un réseau familial: avec 3/4 utilisateurs, je pense que la Xiaomi peu largement faire le taf seul.
– Si tu comptes faire de l’auto-hébergement et faire transiter de nombreuse donnée ENTRE les périphériques, il est possible qu’elle sature à elle toutes seul.
Pour les SSID, je sais pas comment il est possible techniquement : mais elle diffuse à la fois le réseau principal et le réseau « guest » sans aucune difficulté, donc pour 2 SSID, elle gère sans aucun problème.
Pour la nanoPi, j’ai pas d’avis dessus, mais je sais qu’elle m’avait fait de l’œil avant de choisir la Xiaomi, mais j’ai tendance à vouloir utiliser le moins de périphérique possible. Donc tant que la Xiaomi tiens le coup, je l’utiliserai toutes seul.
Pour ce qui est de la différence entre l’IPv6 et l’IPv4, il y en a pas:
root@Xiaomi:~# iperf3 -6 -c ping6.online.net -p 5209
Connecting to host ping6.online.net, port 5209
[ 5] local 2a01:xxx:xxx:xxx::1 port 44286 connected to 2001:bc8:1::40 port 5209
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 42.1 MBytes 352 Mbits/sec 24 280 KBytes
[ 5] 1.00-2.01 sec 44.6 MBytes 371 Mbits/sec 0 374 KBytes
[ 5] 2.01-3.01 sec 54.3 MBytes 459 Mbits/sec 5 347 KBytes
[ 5] 3.01-4.01 sec 40.3 MBytes 337 Mbits/sec 4 233 KBytes
[ 5] 4.01-5.00 sec 38.5 MBytes 324 Mbits/sec 10 241 KBytes
[ 5] 5.00-6.00 sec 42.5 MBytes 357 Mbits/sec 0 354 KBytes
[ 5] 6.00-7.01 sec 44.3 MBytes 370 Mbits/sec 1 328 KBytes
[ 5] 7.01-8.01 sec 49.4 MBytes 415 Mbits/sec 0 420 KBytes
[ 5] 8.01-9.01 sec 47.3 MBytes 396 Mbits/sec 1 393 KBytes
[ 5] 9.01-10.00 sec 44.9 MBytes 379 Mbits/sec 6 248 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 448 MBytes 376 Mbits/sec 51 sender
[ 5] 0.00-10.00 sec 448 MBytes 375 Mbits/sec receiver
iperf Done.
root@Xiaomi:~# iperf3 -4 -c ping.online.net -p 5207
Connecting to host ping.online.net, port 5207
[ 5] local 82.xx.xx.xx port 38924 connected to 62.210.18.40 port 5207
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.02 sec 21.8 MBytes 179 Mbits/sec 0 342 KBytes
[ 5] 1.02-2.02 sec 36.1 MBytes 302 Mbits/sec 2 462 KBytes
[ 5] 2.02-3.00 sec 38.8 MBytes 332 Mbits/sec 0 464 KBytes
[ 5] 3.00-4.02 sec 39.1 MBytes 323 Mbits/sec 0 465 KBytes
[ 5] 4.02-5.01 sec 38.8 MBytes 326 Mbits/sec 0 477 KBytes
[ 5] 5.01-6.00 sec 35.0 MBytes 296 Mbits/sec 0 483 KBytes
[ 5] 6.00-7.01 sec 38.8 MBytes 323 Mbits/sec 0 522 KBytes
[ 5] 7.01-8.00 sec 38.8 MBytes 328 Mbits/sec 0 566 KBytes
[ 5] 8.00-9.02 sec 37.5 MBytes 308 Mbits/sec 0 627 KBytes
[ 5] 9.02-10.00 sec 31.2 MBytes 268 Mbits/sec 0 627 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 356 MBytes 298 Mbits/sec 2 sender
[ 5] 0.00-10.00 sec 356 MBytes 298 Mbits/sec receiver
iperf Done.
Normalement, comme j’ai agrandi le mtu de l’IPv6, le mtu de IPv4 est standard (1500) donc pas trop de soucis de perf.
-
Merci pour ton retour d'xp.
Effectivement, depuis ma freebox Révo, quelques speedtests m'amènent aux alentours de 500Mb/s mais guère plus.
Et si je fais de l'iperf3 entre chez moi et mes serveurs dédiés (OVH, online, ...) on est encore en dessous de ça.
Bref, y'a de la marge.
Je vais garder l'idée d'avoir deux device séparés, par principe de séparation des responsabilités: un unique en entrée du WAN, et un "interne" pour le WiFi.
Mais effectivement la Xiaomi Mi A4 seule serait sans doute suffisante.
-
Je me suis lancé dans une première tentative ce weekend, avec mon nanoPi R4S + TPLink MC220L + ton tuto.
Ni la stack IPv6 (et encore moins l'IPv4) ne fonctionnent à ce stade, beaucoup de choses sont encore floues pour moi. EDIT: ça avance
J'ai compilé le détail dans mon thread (https://lafibre.info/materiel-informatique/degager-la-freebox-serveur-routeur-wifi-firewall-que-me-conseillez-vous/msg842768/#msg842768) pour éviter de polluer ici ; toute aide serait vivement appréciée ;)
-
Hello.
Je me suis lancé dans un test rapide du 4rd avec un openwrt 21.02 (en rc).
Ca marche direct, et tout est configurable par l'interface web (sauf mwan que ne j'ai pas installé pour l'instant, je ne cherche pas à faire fonctionner le 1/4 de ports).
J'ai aussi bien IPv6 que l'IPv4 de fonctionnel.
Pour tester, je récupère bien une IP privée 10./8 en DHCPv4 sur le VLAN 835.
Je teste sur un archer C5 rebadgé en C7, pas de tout première jeunesse, et les débits sont capés à 400Mbps (limites du CPU - 100Mbps en IPv4). Soit. C'est juste pour tester.
Le problème c'est que je n'arrive toujours pas à allumer la boxTV (mini4K), qui reste bloquée sur l'étape d'association avec la box server. J'aimerai savoir ce qui est nécessaire pour remplacer totalement la box server (options DHCP, route à définir pour le flux TV, tunnels ou autre). Je suppose qu'il doit y avoir une relation avec le VLAN 835 (à moins que cela ne soit réservé que pour le téléphone). Je suppose qu'il y aura aussi besoin d'une config d'igmproxy (avec le VLAN 836 ou 835 ?) etc.
Bref, je cherche vraiment un moyen de supprimer les 25W de la box tout en gardant la TV (même si à terme cela pourra etre via oqee sur android TV).
-
Je vais peut être dire une connerie mais j’ai lu une fois qu’il y aurait un tunnel (style ipsec) entre la freebox player et la freebox server ce qui rendrait ultra difficile le fonctionnement du player sans le serveur
-
Justement j'ai lu qu'il y avait de l'IPSEC, mais au niveau du réseau (après le server). Je suppose que c'est directement entre le réseau Free et la box. Du coup la box server ne ferais que du routage = quelques services. C'est ça qui me chiffone.
-
Justement j'ai lu qu'il y avait de l'IPSEC, mais au niveau du réseau (après le server). Je suppose que c'est directement entre le réseau Free et la box. Du coup la box server ne ferais que du routage = quelques services. C'est ça qui me chiffone.
Au risque de doucher tes espoirs, et pour avoir été amené à faire du dev sur la Freebox Player de la révolution, j'ai la quasi certitude que la Freebox serveur lui est totalement indispensable pour fonctionner.
La server n'est pas juste un "passe plat" pour le Player, elles fonctionnent vraiment toutes les deux de concert pour offrir le service TV/media player.
Donc pas de fbx Server, pas de fbx Player (pour la Freebox révolution en tout cas, concernant les déclinaisons Android, je n'en ai aucune idée).
-
Bonsoir J'ai actuellement un boitier Freebox Mini 4k en FTTH en ZMD (avec le boitier noir ONT/ONU),
Reçu vendredi dernier (Auparant sur Orange, SOSH, et dernièrement sur BT en must).
Mes mesures sur BT étaient 940/400, Ping de 3 avec Ubiquiti Edge Router lite sans la BBox. Apres branchement du technicien free, sur le même réseau LAN : 866/350 en free, Ping de 17 ! avec la Freebox. _(ツ)_/
Sur les FAIs précédents, j'étais également sur le même type d'infrastructure FTTH. Je suppose que la perte de download est due au boitier noir (SFP+--SFP), voire à la freebox mini 4k?
@clecle226 :
J'ai dans l'idée :
1-soit de la remplacer par un Raspberry PI4 sous openWRT
comme deja fait sous orange : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/264/
2-soit de remettre mon ERLITE3 comme déja fait précédemment avec Bouygues : https://lafibre.info/remplacer-livebox/tuto-er-6p-v2-0-6-cisco-sg350-28p-nettv-sans-livebox/60/ (j'avais mis un petit cisco pour marquer le cos) et crée un VLAN pour la boxTV
Avec Free :
si je comprends bien, je suis en ZMD, opérateur/cableur historique Orange.
en ZMD : PTO -- ONT/ONU -- freebox à remplacer par :
(PTO) -- SFP+ free(boitier noir ONT/ONU)stp free(M220CL)rj45 -- rj45(Edge lite (ubiquiti) ou (openWRT sur pi4) -- LAN
Finalement le montage est ok ou pas ? cf. https://lafibre.info/remplacer-freebox/quel-module-sfp-choisir/
et si oui je peux me lancer dans le remplacement de la freebox ? (je n'ai pas besoin du player TV, ni tel, etc ..)
Cordialement
-
Un Ping en hausse certes, mais un Ping vers quoi ? Parce qu’un simple nombre sans connaître la destination ça ne veut rien dire.
De plus, ne pas oublier que chez Free en IPv4 tout le traffic sort à Paris même si vous habitez à Menton puisqu’IPv4 est encapsulé dans un tunnel IPv6 et que l’équipement qui termine le tunnel est à Paris….
Pour terminer, attention, pas d’accélération matérielle des tunnels IPv6 pour transporter IPv4 sur la gamme EdgeRouter. Dans ces conditions je doute qu’un ERL dépasse 200 Mbps en IPv4….
-
@clecle226 :
J'ai dans l'idée :
1-soit de la remplacer par un Raspberry PI4 sous openWRT
comme deja fait sous orange : https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/264/
2-soit de remettre mon ERLITE3 comme déja fait précédemment avec Bouygues : https://lafibre.info/remplacer-livebox/tuto-er-6p-v2-0-6-cisco-sg350-28p-nettv-sans-livebox/60/ (j'avais mis un petit cisco pour marquer le cos) et crée un VLAN pour la boxTV
Avec Free :
si je comprends bien, je suis en ZMD, opérateur/cableur historique Orange.
en ZMD : PTO -- ONT/ONU -- freebox à remplacer par :
(PTO) -- SFP+ free(boitier noir ONT/ONU)stp free(M220CL)rj45 -- rj45(Edge lite (ubiquiti) ou (openWRT sur pi4) -- LAN
Le montage est ok pour de la zmd free.
Pour le choix du routeur, vu que tu semble très pointilleux sur les perfs visées, je te conseille de faire extrêmement attention à deux points en particulier:
- que l'interface réseau qui assure le côté wan supporte effectivement le tagging vlan & en hard (chez moi, j'ai du passer l'interface en mode promiscuous car le hard est mal supporté sous linux)
- que l'interface réseau (toujours côté wan) supporte un changement de valeur de mtu, et ce pour une valeur supérieure à la normale (1420 -> 1500 de mémoire), le tout également en hardware pour les perfs. Ton traffic ipv4 (paquets de 1420) a en effet besoin d'être encapsulé dans des paquets IPv6 un poil plus gros pour y placer le header
Perso, j'ai un nanopi r4s et ces deux points ne sont pas gérés ; comme je ne suis pas les yeux rivés sur les perfs, je m'en fiche, mais ça ne semble pas être ton cas.
-
merci pour vos réponses à tous les 2.
ok MTU à 1700 ( je crois avoir lu dans les posts).
@zoc
Un ping vers LaFibre.info ;D (Lyon) à 172 kms de chez moi.
Oui, j'avais remarqué avec mes "speedtest" que tout passe par Free SAS via Paris... :o
J'essaierais peut être bien le FriendlyELEC NanoPi R4S dans ces conditions.
Cordialement
-
Le lien vers mon thread (https://lafibre.info/materiel-informatique/degager-la-freebox-serveur-routeur-wifi-firewall-que-me-conseillez-vous/msg842768/#msg842768) pour openwrt + le r4s.
Si c'était à refaire, et quitte à choisir, pour le coup, j'opterais pour un autre hard si tu veux un support 'aux petits oignons' d'openwrt et de tes interfaces réseau.
-
Super merci à toi et merci pour le tuto que je ne manquerai pas de tester :) :D (j'étais en train de galérer pour tenter d'installer un linux sur un vieux MK808 Dual Core RK3066 Cortex-A9, de chez Rockchip justement...) je viens de regarder les caractéristiques du NanoPi R4S, c'est dingue ces petites choses 66 mm X 66 mm. Je pourrais faire une "freebox" avec un des mes PI4 (j'ai un adaptateur USB3-RG45) mais je vais bientôt le reconvertir pour remplacer les BoxTVs android. (passage en libreElec+ télécommande Apple Remote(flic) et kodi). Je verrai bien si c'est aussi bien.
Si je comprends bien il faudra peut être tagger les paquets en amont avec mon Cisco SG250. Je vais regarder cela tranquillement. Après le passage du technicien free, je me suis amusé à rebrancher le PTO avec le câble fibre SC/APC-SC/APC de Orange-BT sur le boitier ONT/ONU (avant de le remplacer par un câble free de 15m) et à ma grande surprise ça a fonctionné - avec un débit de 30 mo... mais j'avais bien la freebox branchée sur le WAN :o. J'avais commencé à brancher au PTO un câble LC/APC-SC/APC avec le TP-Link TL-SM321B sur le boitier ONT/ONU est là pas d'internet.
Mes premières impressions sur les Freebox : Ma Freebox consomme environ 18w si je me rappelle bien (j'ai désactivé le wifi - ou peut être que la carte femToCell a finie par être désactivée finalement?) et je regrette un peu les 6-7W du edge routeur erlite3, mais sinon ça marche bien. J’ai remis mes règles NAT en 10mm et demandée une full stack IP que j'ai obtenue en 30mm... Je vais enlever les plugsCPL sous peu aussi pour faire propre sur mon réseau électrique et soulager niveau câbles.
On dirait que le Bluetooth est activé sur les BOXs free sans que je puisse y faire grand chose et le replay d'un film en début de diffusion n'est pas possible me semble t-il (alors que BT le fait). Enfin j'ai constaté de très très léger lags quand je regarde une chaine + enregistrement en même temps avec la freebox server+freebox player branchées directement ensemble en RJ45 en 100bits - en comparaison sur le même lan, mêmes câbles une bboxTv+EDGEROUTER LITE 3 sur un vlan dédié que j'avais créé diffusé parfaitement.
Cordialement
-
Salut,
De rien pour le tuto, c’est cool de voir plein de personnes se rendre indépendant des box de FAI !!! ça m’insupporte que l’on m’oblige à utiliser une box opérateur dont on a aucun contrôle dessus.
Si je comprends bien il faudra peut-être tagger les paquets en amont avec mon Cisco SG250. Je vais regarder cela tranquillement.
Oui, c’est principalement du tag et de la configuration de tunnel pour IPv4.
Après le passage du technicien free, je me suis amusé à rebrancher le PTO avec le câble fibre SC/APC-SC/APC de Orange-BT sur le boitier ONT/ONU (avant de le remplacer par un câble free de 15m) et à ma grande surprise ça a fonctionné - avec un débit de 30 mo... mais j'avais bien la freebox branchée sur le WAN :o.
Attends, tu parles du boitier ONT/ONU de Free ou de Orange/BT ? Si c’est l’ONU de Free, c’est normal. SC et LC sont juste des connecteurs. Si tu avais du 30 Mo, c’est fort possible que le connecteur SC n'était pas tout à fait en face de la fiche LC… mais en soit, on pourrait juste acheter des adaptateurs de ce style-là: https://www.amazon.fr/Adaptateur-fibre-multimode-male-femelle/dp/B01D9XLAYO mais autant racheter un câble, ça ne coût relativement pas trop cher (pour l’instant).
Si tu parles de l’ONU d’Orange ou BT, c’est très intéressant comme expérience, cela montre qu’il y a possibilité d’avoir un faible débit, si l’ONU n’est pas authentifiée de la bonne façon… (mais ça parait bizarre, qu’il y a aucun filtre, et dangereux en plus de cela :s )
J'avais commencé à brancher au PTO un câble LC/APC-SC/APC avec le TP-Link TL-SM321B sur le boitier ONT/ONU est là pas d'internet.
Normal, justement (cf. phrase précédente) ONU de Free est authentifié sur leur infrastructure. Si tu veux pourvoir te connecter à leur infrastructure il faut probablement spoofer le SLID de l’ONU, mais de ce que je sais, personne n’a réussi à le faire encore (sur ce forum). mais avec leur nouvelle ONU (qu’il vienne de sortir) cela sert presque à rien d’essayer de remplacer leur ONU.
-
Salut
@clecle226 :
c’est cool de voir plein de personnes se rendre indépendant des box de FAI !!! ça m’insupporte que l’on m’oblige à utiliser une box opérateur dont on a aucun contrôle dessus.
Faire confiance à l'intégrité de ses données par le FAI et consorts aujourd'hui, ça relève aujourd'hui de l'utopie. ... big brother is watching you !
Merci pour tes tutos et pour ta réponse avec les explications à mes tests "empiriques" qui étaient en fait :
- 30 Mo sur la freebox en branchant le câble fibre SC/APC-SC/APC de orange/BT à la place du cable SC-APC à SC-UPC de free (du PTO au boitier ONT/ONU de free). Ca m'avait étonné sur le coup.
- rien du tout avec un câble LC/APC-SC/APC du PTO vers l'entrée de boitier ONU/ONU de free avec un module SFP : TL-SM321B. là no signal ...
Je regarde ce que je peux faire avec openwrt ou mon edgeOS. Quand je fais le tour des articles concernant la freebox en ZMD, je crois comprendre qu'il n'y a pas bcp de monde qui a résolu le pb du remplacement de la freebox avec les mêmes perf. ? voire encore moins du duo freebox-freeboxTV ? Ce n'est pas mon but, mais Il semblerait que bcp finissent par passer le routeur free en bridge.. (je suis tombé également sur cet article : https://www.g-rom.fr/2011/10/cohabitation-freebox-v6-server-en-mode-bridge-avec-freebox-player/ , qui traitait du sujet).
j'ai lu également ce tuto https://lafibre.info/remplacer-freebox/tuto-remplacer-sa-freebox-par-un-routeur-ubuiquity-en-zmd-10g-epon/ (mais avec une perte de l'offload et un débit dégradé pour le 4rd de free).
Cordialement
-
Hello,
Pour information, j'ai testé avec un openwrt 21 directement sur l'ONU.
J'ai découvert qu'une fois le package map installé, il suffit de configurer le WAN en DHCPv6 sur le VLAN836 et le tunnel map-e se monte tout seul directement avec 1/4 de ports.
Après il reste les règles IPv6 et IPv4 à mettre en place mais j'ai arrêté là.
Dans les faits je n'arrive pas à monter le tunnel IPv4 in IPv6 car j'ai aussi une IP avec l'ensemble des ports, et apparemment l'IPv6 de l'interface qu'il utilise ne peut pas exister dans la rfc7597 (https://datatracker.ietf.org/doc/html/rfc7597) car d'après le chapitre 6 cela reviendrait à avoir une IPv4 égale à 255.255.255.255 (bof). Du coup je cherche comment créer un simple tunnel IPv4 dans IPv6 avec openwrt et apparemment c'est pas possible (ou alors il faut bien chercher).
-
Bon, une configuration hyper simplifiée qui fonctionne avec openwrt 21.02:
config interface 'wan6'
option proto 'dhcpv6'
option mtu '1660'
option device 'eth7.836'
option reqaddress 'try'
option reqprefix 'auto'
option zone_map 'wan'
option encaplimit 'none'
option metric '20'
Avec ça j'ai l'IPv6 et l'IPv4 qui fonctionnent directes mais seulement le 1/4 d'IP.
Premier soucis, je n'arrive pas à forcer la mtu de l'IPv4 à 1500. Le réglage par défaut se met à 1280.
Second soucis: je n'arrive vraiment pas à récupérer l'IPv4 avec tout ses ports. Et ça ça m'énerve. La galère d'utiliser autre chose que map-e ou lw4o6 car c'est un tunnel ipip6 mais ça n'existe pas dans les configurations. J'ai modifié lw4o6 pour forcer l'IPv6 du tunnel mais ça ne fonctionne pas: je vois bien les paquets partir sur eth7 avec le bon VLAN, les bonnes MAC, les bons IPv6 avec proto=4, et les bonnes IPv4. Mais apparemment je n'ai aucun retour, le ping 8.8.8.8 part bien mais aucun retour. Par contre les scanner du net je vois bien les paquets arriver vers mon IPv4.
Bref tant que je n'arrive pas à récupérer mon IPv4 je dois supporter les 18W de la freebox...
-
Bonjour,
et en forçant le mode promiscuous sur l'interface réseau ?
cf https://forum.openwrt.org/t/ipv6-works-only-with-wan-in-promiscuous-mode/490/15
L'erreur suivante apparaît:
ip6_tunnel: map-wan6_4 xmit: Local address not yet configured!
-
Oui c'est vrai, j'avais oublié une règle firewall pour autoriser le tunnel IPIP6 a recevoir les paquets:
config rule
option name 'Accept IP4oIP6'
list proto 'ipencap'
option src 'wan6'
option target 'ACCEPT'
Et important de préciser que l'interface map-e qui va se créer utilise les règles firewall d'une interface IPv4 et pas hériter du firewall IPv6 wan6 (option zone_map 'wan').
Mais je ne sais toujours pas comment forcer l'interface à avoir une MTU de 1500.
-
J'ai quitté temporairement ByTel pour de basses raisons financières et je note:
- sans la patch du taulier sur map.sh, effectivement cela ne fonctionne pas
- il faut passer l'interface physique en mode promiscuous sur x86
- de mon côté, c'est soit l'IP partagée soit l'IP dédiée
- même problème de MTU bloqué à 1280 sur l'IP partagée
- au boot, l'IP partagée est préférée
- impossible de faire du NAT sur l'IP partagée (testé avec l'interface ou en modifiant le fichier de configuration) dès que l'IP full stack est activée avec la patch.
-
EDIT: mon patch-o-matic de fortune ne s'est pas passé comme prévu sur OpenWRT 21.02.2.
Désolé du dérangement.
-
Bonjour,
Personne n'a essayé de remplacer entièrement la box/l'ont pas un ONT générique 10g-epon ? :D
-
Plusieurs ont semble-t-il essayé, sans le moindre succès.
Le boîtier ont 'made in Free' reste indispensable pour les accès fibre en ZMD.
-
Bonjour,
J'ai réussi à suivre la méthode sous OpenWrt 21, avec FIBRE -> ONU/ONT (Free) -> MC220L -> OpenWrt.
Par contre, je n'arrive pas à mettre l'IPv4 full-stack en route par défaut.
Le routeur utilise toujours l'IPv4 partagée.
Si quelqu'un à une piste pour m'aider, je suis preneur.
Prochaine étape : mettre en place Wireguard :-)
-
Bonjour,
n'essayez pas de faire une mise à jour vers la version 22.03 pour le moment, il est impossible (à configuration fw identique) d'avoir une IPv6. Je n'ai pas le temps de tester avec un système vierge de toute modification.
Je précise bien évidemment que l'interface associée au VLAN 836 a bien une adresse LL.
L'erreur d'odhcp6c est la suivante:
odhcp6c[4986]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)
EDIT: en désactivant fw4, ça fonctionne, et même en faisant en sorte qu'il n'y a aucune erreur dans la console, ça merde alors que les règles ICMP pour ipv6 sont les mêmes que le fw par défaut.
https://github.com/openwrt/openwrt/blob/master/package/network/config/firewall/files/firewall.config
-
n'essayez pas de faire une mise à jour vers la version 22.03 pour le moment, il est impossible (à configuration fw identique) d'avoir une IPv6
Salut,
ça fonctionne chez moi (TM)
- sur un nanoPI r4s
- à l'époque (openwrt 21.x) grâce au blog et conseils avisés de clecle226 ; cf. ce thread (https://lafibre.info/materiel-informatique/degager-la-freebox-serveur-routeur-wifi-firewall-que-me-conseillez-vous/msg842768/#msg842768)
- entre temps j'ai upgrade vers openwrt 22.03 (il date un peu, cf. screenshot avec le build#, mais un 22.03 quand même) ; je me rappelle qu'effectivement il y avait des changements à faire dans mon /etc/config/network
- j'utilise le plugin 'map' customisé (https://github.com/nouknouk/ma-domotique/wiki/remplacer-la-freebox-par-nanopi-r4s#4rd-traffic-mapping) pour le tunnel ipv4 dans ipv6
- pas d'ipv4 1/4, uniquement la full.
- (+ une problématique propre au nanopi r4s) le WAN du r4s gère mal les VLAN ; plutôt que forcer un mode promiscuous, j'ai inversé les ports WAN et LAN car le chip du LAN fonctionne bien mieux, lui, pour les VLAN.
(https://i2.paste.pics/a1632bb38707d9194362afd074178032.png)
(https://i2.paste.pics/56fae313e389ef42acf9908913aa81b7.png)
==> toutes les notes que j'ai prises lors du build de l'image (https://github.com/nouknouk/ma-domotique/wiki/remplacer-la-freebox-par-nanopi-r4s#build-openwrt-from-git) depuis le repo git openwrt
ma config actualisée (celle qui est live en ce moment même, sans doute plus à jour que celle de mes notes)
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd02:8f90:d6f9::/48'
config device
option name 'eth0'
option macaddr '0x:yz:tx:yz:tx:yz'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config device
option name 'eth1'
option macaddr '0x:yz:tx:yz:tx:yz'
option mtu '1700'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ip6assign '60'
list ipaddr '192.168.0.254/24'
config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
list dns '2001:4860:4860::8888'
option peerdns '0'
option device 'eth1.836'
config interface 'wan'
option tunlink 'wan6'
option device 'eth1.836'
option proto 'map'
option type 'map-e'
option delegate '0'
option peeraddr '2a01:xyzt:xyzt:200a::fffd'
option ipaddr 'xy.xyz.xyz.xyz'
option ip4prefixlen '32'
option ip6prefix '2a01:xyzt:xyzt:xyzt::'
option ip6prefixlen '60'
option encaplimit 'ignore'
option defaultroute '1'
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option mtu '1500'
-
Prochaine étape : mettre en place Wireguard :-)
Ma config wireguard dans /etc/config/network, avec 4 clients:
mon network lan est en 192.168.0.0/24
le network wg est en 192.168.10.0/24
# le routeur
config interface 'wg0'
option proto 'wireguard'
option private_key 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa='
option listen_port '51280'
option mtu '1200'
list addresses '192.168.10.1/24'
# device client 1
config wireguard_wg0
option description 'laptop'
option public_key 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb='
list allowed_ips '192.168.10.2/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
# device client 2
config wireguard_wg0
option description 'tel_android'
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '192.168.10.3/32'
option public_key 'cccccccccccccccccccccccccccccccccccc='
# device client 3
config wireguard_wg0
option description 'nouksurface'
option public_key 'ddddddddddddddddddddddddddddddddddddddddddddddddd='
list allowed_ips '192.168.10.4/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
# device client 4
config wireguard_wg0
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '192.168.10.5/32'
option description 'surface_pro'
option public_key 'eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee='
config device
option name 'wg0'
option acceptlocal '1'
et sur mon laptop par exemple: /etc/wireguard/wg0.conf
[Interface]
Address = 192.168.10.2/24
MTU = 1200
# allow VPN traffic to be routed to interface wlp2s0 (= the wifi card of my laptop)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlp2s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlp2s0 -j MASQUERADE
PrivateKey = yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=
########################## this client's peer (=server to connect to)
[Peer]
# the public key of the server this client will connect to (=router)
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
# the IP of the server
Endpoint = my-little-dns.net:51280
# the IP range that will be routed through the VPN connexion
AllowedIPs = 192.168.0.0/16
PersistentKeepalive = 25
-
Merci nouknouk pour l'exemple de configuration Wireguard.
Depuis mon post où j'ai réussi à obtenir une connexion IPv4 + 1/4 IPv4 + IPv6, j'ai rencontré quelques problèmes que j'ai réussi à pallier.
Je n'arrivais pas à utiliser l'IPv4 fullstack comme route par défaut (je ne suis pas expert, j'avais donc manuellement ajouté la route par défaut, que je devais remettre à chaque redémarrage).
Depuis, j'ai ajouté dans le script de démarrage (onglet local startup ou ficher /etc/rc.local)
sleep 10
ifup wan
exit 0Cela permet d'allumer l'interface après l'obtention du 1/4 IPv4, et donc la route par défaut sera correcte.
Je ne pense pas que cette solution soit optimale, mais elle fonctionne chez moi :).
Ensuite j'ai eu comme toi des soucis de MTU (symptômes : obliger de réactualiser les pages web lors des premières visites, comme tu l'as bien décris dans un post du forum).
Après plusieurs essais, j'ai conclu que mon routeur ne pouvait pas prendre une MTU supérieur à 1504.
J'arrivais à forcer les MTU du wan à 1700 et du map-wan à 1500, mais j'avais toujours les mêmes symtômes.
Voici donc les MTU qui fonctionnent bien chez moi, sur un routeur Xiaomi Redmi AC2100
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc fq_codel state UP qlen 1000
3: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
4: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
5: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
6: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
7: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1000
10: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
11: wan.836@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
13: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
14: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
15: map-wan6_4@wan.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN qlen 1000
16: map-wan@wan.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN qlen 1000
Et voici ma configuration finale sous OpenWrt 21, sachant que j'ai appliqué le fameux patch du map-e.
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.1.254'
list dns '1.1.1.1'
list dns '1.1.0.0'
config device
option type '8021q'
option ifname 'wan'
option vid '836'
option name 'wan.836'
option macaddr 'HIDDEN'
config interface 'wan6'
option proto 'dhcpv6'
option device 'wan.836'
option reqaddress 'try'
option reqprefix 'auto'
config interface 'wan'
option proto 'map'
option maptype 'map-e'
option peeraddr '2a01:e00:29:200a::fffd'
option ipaddr 'HIDDEN'
option ip4prefixlen '32'
option ip6prefix 'HIDDEN'
option ip6prefixlen '60'
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option tunlink 'wan6'
option mtu '1280'
option delegate '0'
option encaplimit 'ignore'
option auto '0'
Si jamais vous voyez une aberration dans ma configuration, n'hésitez pas à me le dire ;)
-
Bonjour,
Petit message pour dire un grand merci à clecle226 et nouknouk pour leur tutos.
J'ai réussi à remplacer ma freebox mini 4K par un mikrotik hEX s sous openwrt.
je n’ai pas eu besoin de recompiler quoique ce soit, le firmware en 22.03 fonctionne niquel + installer map et un éditeur de texte (team vim).
Ci dessous ma config à toute fin utile :
/etc/config/network
config device
option device name 'wan'
option macaddr '70:FC:xx:xx:xx:xx'
config interface 'wan6'
option device 'wan.836' # Correspond au numéro de l'interface internet 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
list dns '2001:4860:4860::8888' #(optionnel), c’est juste le temps d'avoir un internet fonctionnel le temps de hijacking le dns
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.
config interface 'wan4'
option delegate '0' #On désactive l'intégration 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 (on a le choix entre map-e map-t et lw6over4, mais on est sur du map-e pour nous)
option peeraddr '2a01:e00:29:200a::fffd' # L'adresse du tunnel côté serveur (le border router)
option ipaddr 'ipv4 full-stack' #L'ip full stack qui vous a été attribué et qui se trouve sur votre espace client
option ip4prefixlen '32' #Le préfixe de l'IP
option ip6prefix '2a01:xxx:xxx:xxx::' #Votre plage/préfix IPv6
option ip6prefixlen '60' #La longueur du préfix
option mtu '1500' # Le mtu que l'on met à 1500, openwrt adaptera celle de wan6
option encaplimit 'ignore' #pas d'encapsulation limit
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option maptype 'map-e'
config route
option interface 'wan4'
option target '0.0.0.0/0'
/lib/netifd/proto/map.sh
-> ligne 66
echo "$RULE_DATA" >> /tmp/map-$cfg.rules
+ [ -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
+ RULE_DATA=`cat "/tmp/map-$cfg.rules"`
eval $RULE_DATA
-> ligne 130
- proto_add_ipv4_route "0.0.0.0" 0
+ [ ! -z "${RULE_DATA##*2a01:xxxx:xxxx:xxxx::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0
Ensuite il y a juste a s'assurer que wan4 soit bien dans la zone wan du pare-feu avec wan6 et c'est bon.
OpenWrt fait par défaut serveur DHCPv4 et v6 dont les paramètres sont modifiable dans /etc/config/dhcp (pas comme RouterOS qui ne maitrise pas l'art du DHCPv6 ???).
Je n'ai même pas eu à paramétrer de NAT.
Bref que du bon chez OpenWrt, j’appliquerai la même manip à mon hAP ax2 lorsqu'il sera dispo dessus :)
-
Salut les gars, j'ai essayé d’installer wireguard mais au moment de redémarrer le pare feu, j’ai eu une erreur et rien ne fonctionne.
-
salut,
chez moi la config ressemble à ça dans /etc/config/network
#1 definition du réseau wireguard
config device
option name 'wg0'
option acceptlocal '1'
#2 configuration du réseau:
# on définit une IP pour le routeur lui-même dans ce réseau wireguard,
# et aussi un range d'IPs pour le réseau wg0
config interface 'wg0'
option proto 'wireguard'
option private_key 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
option listen_port '51280'
option mtu '1200'
list addresses '192.168.10.1/24'
#3 configuration de chaque client qui veut accéder au réseau wireguard
# chaque client doit avoir sa propre ip unique (exprimée en /32) qui fait partie du range d'IP définie dans la config #2
config wireguard_wg0
option description 'device_client_1'
option public_key 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
list allowed_ips '192.168.10.2/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
config wireguard_wg0
option description 'device_client_2'
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '192.168.10.3/32'
option public_key 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
-
slt, j'ai essayé ta config, mais ça ne fonctionne toujours pas pour moi. T'a mis quelle règle pour ton pare-feu?
-
Salut,
Je pense qu'il faut que la zone 'vpn' puisse communiquer avec la zone 'lan'.
Deux paramètres sur lesquels jouer amha:
- l'accept sur le forward entre chaque zone
- le cas échéant, le masquerading
Niveau port forward, il faut accepter le trafic wireguard venant du wan pour qu'il atteigne le serveur wireguard qui tourne sur ton routeur openwrt:
- Incoming IPv4,
- protocol UDP
- From wan
- To this device, port 51280
- Forward to lan IP 192.168.0.254 port 51280
192.168.0.254 étant l'IP propre de mon routeur sur le LAN.
-
voici ma config
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'wg0'
config redirect
option dest 'lan'
option target 'DNAT'
list proto 'udp'
option src 'wan'
option dest_ip '192.168.1.1'
option src_dport '51820'
option dest_port '51820'
option name 'WireGuard'
config device
option name 'wg0'
option acceptlocal '1'
config interface 'wg0'
option proto 'wireguard'
option private_key 'aaaaa'
list addresses '192.168.9.1/24'
option mtu '1200'
option listen_port '51820'
config wireguard_wg0 'wgclient'
option public_key 'aaaaa'
option preshared_key 'aaaaa'
list allowed_ips '192.168.9.2/32'
option route_allowed_ips '1'
option persistent_keepalive '25'
-
Hello.
Quelques updates par rapport à ma connection récente chez Free.
Je test avec openwrt 22.03.
Apparemment il faut toujours modifier le fichier /lib/netifd/proto/map.sh comme au premier post. Je n'ai pas encore cherché s'il y a un moyen plus propre pour le faire.
Ensuite, apparemment sur openWRT la modification du map.sh pour interdire la route par défaut pour l'IPv4 partagée ne semble plus fonctionner. En tout cas si on défini l'IPv6 en DHCPv6, la route par défaut vers le 1/4 d'IPv4 se remet tout le temps et régulièrement. Du coup on finit par avoir tout son traffic par ce quart d'IP au lieu de l'avoir par l'IPv4 complète.
Pas top.
Quand j'aurai du temps je vais regarder ça plus en détail. Pour le moment j'ai désactivé cela en définissant l'IPv6 en statique. Mais j'aimerai bien garder mon quart d'IPv4 pour le fun (genre dédié uniquement à certains protocoles comme pour le gaming).
Ensuite, pour la récupération de l'adresse MAC de la Freebox (qui je le rappelle n'est visible nulle part sur la box), Free a modifié légèrement son infrastructure par rapport à avant. Maintenant il n'est plus possible de récupérer la MAC juste en branchant l'ONU et en dumpant ce qui arrive dessus. A chaque fois que l'ONU est débranché, il ne laisse passer plus rien du net sur son SFP tant que la box n'ai pas au moins envoyé un paquet avec la bonne address MAC.
Du coup, le seul moyen de récupérer la MAC de la box, c'est de brancher d'abord la BOX directement avec un DAC vers le routeur, puis de dumper les requêtes DHCP venant de la box. Et LA seulement on dispose de l'adresse MAC à utiliser.
-
salut,
je suis désormais également en 22.03 ; sans changement notable concernant les modifs précédemment citées.
Ça se passe (très) bien, à une exception près (mais qui - je crois - arrivait déjà sur ma config openwrt 21.02): il arrive que tout à coup (parfois au bout d'une semaine, parfois un mois), plus rien ne soit accessible de l'extérieur (tandis que sortir depuis le LAN ne continue de poser aucun souci) ; et c'est difficilement prévisible.
Dans ce cas un restart des interfaces suffit à tout faire rentrer dans l'ordre.
Mais c'est pas top, car si je décide de partir deux semaines en vacances et que ça flanche 'day 1', j'ai plus d'accès à ma maison du tout (domotique, caméras de surveillance, que madame puisse voir si le chat rentre bien, etc...)
si on défini l'IPv6 en DHCPv6, la route par défaut vers le 1/4 d'IPv4 se remet tout le temps et régulièrement. Du coup on finit par avoir tout son traffic par ce quart d'IP au lieu de l'avoir par l'IPv4 complète.
Au vu de ce que tu dis, dois-je comprendre que désactiver le DHCPv6 sur l'interface WAN6 résoudrait mon souci ?
Ma config actuelle:
config device
option name 'map-wan6_4'
option mtu '1500'
config interface 'wan'
option delegate '0'
option tunlink 'wan6'
option proto 'map'
option type 'map-e'
option peeraddr '2a01:xxxx:xxxx:xxxx::fffd'
option ipaddr '82.64.27.189'
option ip4prefixlen '32'
option ip6prefix '2a01:xxxx:xxxx:xxxx::'
option ip6prefixlen '60'
option encaplimit 'ignore'
option defaultroute '1'
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option device 'eth1.836'
option mtu '1500'
config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option macaddr 'XX:XX:XX:XX:XX:XX'
list dns '2001:4860:4860::8888'
option peerdns '0'
option device 'eth1.836'
option mtu '1700'
Je devrais donc passer en ?
config interface 'wan6'
option proto 'static'
-
Pour ceux avec un routeur type MT7621, est ce que l'offload hardware fonctionne avec cette méthode d'encapsulation ?
Les 1G sont atteints sans problème avec charge CPU modeste ?
DSlite a l'air supporté par le driver pour l'offload, ensuite MAP-E s'appuie sur la même encapsulation non ?
https://elixir.bootlin.com/linux/v5.15.85/source/drivers/net/ethernet/mediatek
Voir sources de mtk-ppe et ppe-offload
-
Petit retour d'expérience depuis 1 an, tout fonctionne sans soucis.
Pour la TV, j'ai découvert récemment que j'avais OQEE dans mon abonnement, donc parfait pour Chromecast, Android TV, etc.
Par contre il m'arrive d'avoir des bridages en soirée sur l'IPv4, souvent à partir de 21h.
Sur les sites de test de débit, on ne voit rien.
Par contre sur le téléchargement de fichier réel, hébergé sur un serveur IPv4, je ne dépasse pas les 200 ko/s !
Sur un autre serveur IPv4 situé à Lille, j'ai bien les 10 mo/s habituel.
Sur un serveur IPv6 (localisation aléatoire), pas de bridage.
Est-ce un problème de configuration de l'IPv4 ?
Existe-t'il une solution de contournement ?
Peut-être forcer le passage d'IPv4 en soirée dans un VPN IPv6 puis accès à l'Internet IPv4 de l'autre côté ?
-
bonjour a tous
Je réside dans une zone ZTD et j'utilise une Freebox Révolution. J'ai suivi ce tutoriel pour essayer de me passer de la Freebox, mais je rencontre un problème : je n'ai pas de connectivité IPv4, seule l'IPv6 fonctionne.
Ma connexion fibre est de type PON.
J'ai l'ONU de free connecté a MC220L puis a mon routeur openwrt (archer c7 v2)
OpenWrt 23.05.0 r23497-6637af95aa / LuCI openwrt-23.05 branch git-23.236.53405-fc638c8
TP-Link Archer C7 v2
J'ai installé le package map avec ses les dépendances. Serait-il un problème de firewall ? Comment je pourrais identifier cela ?
Ci-dessous, vous trouverez mes configurations. Si quelqu'un peut identifier un éventuel problème ou une erreur dans ces réglages
merci d'avance je reste a dispo pour toute info complémentaire
network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd72:xxxx:xxxx::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1.1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
list dns '8.8.8.8'
config interface 'wan'
option delegate '0'
option tunlink 'wan6'
option proto 'map'
option type 'map-e'
option peeraddr '2a01:xxx:xx:xxxx::xxxx'
option ipaddr '88.xxx.xx.xx'
option ip4prefixlen '32'
option ip6prefix '2a01:xxx:xxx:xxxx::'
option ip6prefixlen '60'
option mtu '1500'
option encaplimit 'ignore'
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option maptype 'map-e'
list dns '8.8.8.8'
config interface 'wan6'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option macaddr 'F4:xx:xx:xx:xx:xx'
option mtu '1700'
option device 'eth0.836'
option peerdns '0'
list dns '2001:4860:4860::8888'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 2 3 4 5'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6t'
option vid '2'
config switch_vlan
option device 'switch0'
option vlan '836'
option vid '836'
option ports '1t 6t'
screenshots:
https://imgur.com/WOeQ4F6
https://imgur.com/ERkRiXE
https://imgur.com/BjiteZ4
https://imgur.com/Lu8US0T
-
Salut,
De mon cote ça fonctionne toujours bien , ipv4 + IPv6.
J'avais eu besoin non seulement d'installer le package map, mais en plus de modifier un fichier une fois installé m.
Je t'invite à jeter un œil à mes notes perso: https://github.com/nouknouk/ma-domotique/wiki/remplacer-la-freebox-par-nanopi-r4s#4rd-traffic-mapping
-
Salut,
De mon cote ça fonctionne toujours bien , ipv4 + IPv6.
J'avais eu besoin non seulement d'installer le package map, mais en plus de modifier un fichier une fois installé m.
Je t'invite à jeter un œil à mes notes perso: https://github.com/nouknouk/ma-domotique/wiki/remplacer-la-freebox-par-nanopi-r4s#4rd-traffic-mapping
Bonjour,
Merci pour vos conseils notes. Malheureusement, je n'ai toujours pas réussi à établir une connexion IPv4. J'ai remarqué quelques différences entre vos notes et le tutoriel, notamment dans cette section :
echo "$RULE_DATA" >> /tmp/map-$cfg.rules
[ -z "${RULE_DATA##*2a01:xxxx:xxxx:xxxx::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
RULE_DATA=`cat "/tmp/map-$cfg.rules"`
eval $RULE_DATA
Dans vos notes, il est indiqué de remplacer xxxx:xxxx:xxxx:xxxx par ma propre adresse IPv6 ("replace xxxx:xxxx:xxxx by your own IPv6"), tandis que le tutoriel utilise *2a01:e00:29:200a::fffd*. Dois-je utiliser mon adresse IPv6 personnelle ou l'adresse peeraddr fournie par Free ?
Une autre question concerne les parties barrées dans le tutoriel. Sont-elles nécessaires ? En particulier, la section "Remplacer la totalité du fichier /etc/config/mwan3 par cela :"
Concernant l'interface 'wan6_4', le tutoriel mentionne qu'il faut indiquer #Votre adresse IP éphémère. Que signifie exactement une "adresse IP éphémère" ? Est-ce la même chose que #L'ip full stack qui vous a été attribué et qui se trouve sur votre espace client ?
Enfin, lors de mes tests, sur la console OpenWRT j'ai reçu le message d'erreur suivant : ip6_tunnel: map-wan6_4 xmig: Local address not yet configured!
Je vous remercie pour toute aide que vous pourriez m'apporter et m'excuse si mes questions semblent basiques, ma connaissance en réseau étant limitée.
-
Hello
Si ça peut aider quelqu'un, je vous copie le diff entre la version de map.sh que j'ai modifié et la version de base:
66a67,70
>
> [ -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
> RULE_DATA=`cat "/tmp/map-$cfg.rules"`
>
82c86,87
< json_add_int mtu "${mtu:-1280}"
---
> #json_add_int mtu "${mtu:-1280}"
> json_add_int mtu "${mtu:-1500}"
130c135,136
< proto_add_ipv4_route "0.0.0.0" 0
---
> # proto_add_ipv4_route "0.0.0.0" 0
> [ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && proto_add_ipv4_route "0.0.0.0" 0
En gros:
- je modifie l'IP source pour le tunnel ipip6 en ${ip6prefix%?}0:ffff:ffff:0
- je change la MTU du tunnel pour 1500 (par défaut 1280)
- je ne crée pas la route par défaut IPv4 via l'IP du tunnel[/ii]
Sinon, la définition de mon interface wan (IPv4 full stack) + wan6:
config interface 'wan6'
option device 'eth0.836'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option zone_map 'wan'
option peerdns '0'
config interface 'wan'
option delegate '0'
option tunlink 'wan6'
option proto 'map'
option type 'map-e'
option peeraddr '2a01:e00:29:200a::fffd'
option ipaddr '<monIPv4 full stack>'
option ip4prefixlen '32'
option ip6prefix '2a01:<prefix>0::'
option ip6prefixlen '60'
option mtu '1500'
option encaplimit 'ignore'
option ealen '32'
option psidlen '1'
option offset '16'
option psid '65535'
option maptype 'map-e'
option peerdns '0'
option zone 'wan'
De mémoire pas mal de trucs ne servent pas.
Et enfin et surtout parce que flemme, j'ai souvent des déconnexions dès que le wan6 déconne ou se reconnecte et le wan ne se monte plus. D’après les logs c'est un problème dans les scripts de démontage/remontage d'interface qui ne fonctionnent pas top (probablement un clean mal fait). Seul moyen d'être sûr qu'une modification d'interface est prise en compte est de redémarrer openWRT.
Hormis ces modifications du script map.sh et ma configuration, tout fonctionne avec l'IPv4 "full stack". J'ai également le 1/4 d'IPv4 qui se monte, mais malheureusement je ne sais pas pourquoi l'option zone_map ne semble pas fonctionner et l'interface se crée sans être mis dans la zone firewall du wan. J'ai aussi commenté la création de la route par défaut car si je laisse map.sh la créer, je n'arrive pas à créer une autre route de priorité supérieurs pour passer par défaut par une autre interface.
-
Voici une mise à jour rapide qui pourrait aider quelqu'un. J'ai finalement réussi à faire fonctionner ma connexion ipv4. Tout dans ma configuration openwrt était correct, la seule chose qui me manquait était de demander mon ipv4 full stack à Free. J'ai suivi la procédure décrite dans cette vidéo et maintenant ma connexion est bonne. Merci Fuli10 pour ton aide.
https://www.youtube.com/watch?v=7gwQYW7sdPU