Dans cet article, je vais vous expliquer comment obtenir (difficilement) une IPv4 full-stack + 1/4 d’IPv4 + IPv6 /60 chez Free en zone ZMD.
Les caractéristiques techniques de Free ne respectent pas la RFC7597 de Map-e… Ce qui fait que l’on doit faire un micro patchwork sauvage dans les librairies de Openwrt (qui n’est pas très souple non plus, faut le dire). J’ai mis à peu près 1 semaine à faire de la “rétro-ingénierie” (c'est un bien grand mot), pour trouver les caractéristiques des tunnels ipip6 de Free.
Explications et préambule :
Commençons par des explications : 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à : 
Et vous le brancher sur un convertisseur optique <-> RJ45, type TP-Link MC220L : 
C’est le truc de base pratiquement commun à tous les opérateurs : Trouver le moyen de convertir les signaux analogiques en numérique, c’est-à-dire un modem. Ici, on est en fibre optique, donc il s’agit de signaux optiques, mais pour l’ADSL ou la VDSL il s’agit de signaux électriques analogique.
Phase I :
Pour obtenir le /60 de l’IPv6, la manipulation est relativement simple et commune à tous les opérateurs français. Il faut juste faire une requête DHCPv6 sur un VLAN particulier (ici, le 836) et le spoofing de l’adresse MAC de la Freebox. Le serveur vous renvoie immédiatement et automatique la plage IPv6.
Vous pouvez faire toutes les manipulations de la phase I avec l’interface web, mais je préfère passer par les lignes de commandes pour modifier les fichiers.
Du coup, vous pouvez commencer par vous connecter en ssh au routeur :
ssh root@192.168.1.1
et modifier le fichier network avec la commande:
nano /etc/config/network
(oui je suis #TeamNano, si vous voulez l’installer c’est "opkg install nano")
Vous chercher dans le fichier la section switch_vlan (généralement à la fin) et vous rajouter
config switch_vlan
option device 'switch0'
option vlan '836'
option vid '836'
option ports '4t 6t'
Vous taguer avec le vlan 836 le CPU et le port WAN respectivement. Je sais pas comment connaître les numéros correspondant au port WAN et au CPU, je vous conseille de modifier graphiquement les attributions switch une fois que vous avez créé le vlan en ligne de commande.
Toujours dans le fichier /etc/config/network:
Vous modifier l'interface WAN6 déjà existant.
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.
Félicitation, vous avez mis un 1er pied sur l’internet de Free. Normalement vous avez un internet Full IPv6 Only.
Cette connexion ne permet pas d’accéder à la totalité du WEB, mais vous pouvez normalement aller sur google.com et openwrt.org pour vérifier que cela fonctionne bien.
Phase II :
C’est la phase à la fois la plus simple et la plus compliquée.
Il suffit simplement d’installer le protocole Map-E dans Openwrt: le paquet s’appelle map.
Cependant, pas tout le monde va pouvoir l’installer en raison des modules noyau qui ont été intégrés ou non dans Openwrt.
(Je ne sais pas s’ils y sont par défaut, car je travaille avec une version que j’ai recompilée moi-même).
Mais voici le retour de la commande opkg
map depends on:
libc
kmod-ip6-tunnel
libubox20191228
libubus20191227
iptables-mod-conntrack-extra
kmod-nat46
Si kmod-ip6-tunnel, n’est pas inclue par défaut dans votre version compilée, il vous reste plus que à la recompiler vous-même.
Je vous laisse le tuto, si vous en avez besoin : Openwrt - Guide rapide de compilation
Cependant si vous avez réussi à installer le paquet map (ou recompiler le firmware), bonne nouvelle : vous avez terminé la phase II !!!!
En effet, Free envoie automatiquement les informations d’une IP partagé au routeur, même si vous avez choisi une IP full-stack !!!
Par conséquent vous avez le droit à des ports automatiquement en IPv4 pour pouvoir simplement naviguer.
⚠DISCLAIMER⚠
Je ne vous conseille pas d’utiliser cette IP pour de l’hébergement (même personnelle) car cette IP n’est en AUCUN CAS garantie, ni l’IP elle-même, ni les ports qui vous sont attribué ! Ce n’est qu’une IP avec des ports éphémères pour de la navigation simple.
⚠DISCLAIMER⚠
Si rien n’apparaît dans les interfaces, que ce soit avec ip a ou avec l’interface graphique.
Je vous conseille de redémarrer l’interface WAN6, car les infos viennent parfois avec la requête DHCP si cela fait longtemps qu’elle est restée allumer.
Normalement voici ce qui va apparaître dans votre interface graphique :
Je vais vous expliquer tout ce que vous voyez, même si cela n’est pas nécessaire pour avoir internet.
Vous avez votre interface WAN6 normal, qui vient normalement avec IPv6-PD : qui correspond au préfixe qui vous est attribué. Ce préfixe est réutiliser pour créer un tunnel avec le serveur border de Free.
Le tunnel qui est créé est l’interface WAN6_4_, il se décompose d’abords du préfixe IPv6 qui vous est attribué, ensuite 0, ensuite l’adresse IPv4 convertit en hexadécimal (par exemple, 91.1.10.100 -> 5b01:0A64), ensuite le rang des ports qui vous sont attribué (pour moi c’est le 2ᵉ rang).
On vous attribue 16 383 ports, sachant que il y a 65 535 ports, il y a normalement 4 rangs.
Ce qui donne comme adresse du tunnel PREFIX:0:5b01:0A64:2, par exemple. De l'autre côté du tunnel, on communique avec le serveur à l’adresse 2a01:e00:29:200a::ffff.
Une fois que le tunnel entre les 2 points est créé, Openwrt créer une interface virtuelle temporaire. Avec l’adresse IPv4 (ici 91.1.10.100).
La route est automatiquement créée pour renvoyer le trafic IPv4 vers cette adresse, mais par défaut, l’interfaces ne rentre dans aucune zone de pare-feu et par conséquent, il devrait normalement bloquer tout le trafic par mesure de sécurité.
Comme se sont des interfaces virtuelles vous ne pouvez pas modifier graphiquement la zone de pare-feu de ces interfaces. MAIS, vous pouvez les “pre-shot”, et les assigner à une zone avant même qu’elle soit créée.
Dans le fichier /etc/config/firewall:
Cherche le bloc « zone » avec le nom « wan » et dans option network, rajouter le nom de l’interface qui va se créer automatiquement (ici, WAN6_4) Mettez bien le nom de l’interface IPv4 et pas le nom du tunnel.
Vous avez normalement accès à tout l’internet!!! IPv4 et IPv6. Si vous ne souhaiter pas faire de l’auto-hébergement, héberger de serveur Minecraft ou autre utilisation d’une IPv4 Full-stack, vous pouvez vous arrêter ici, vous en avez terminé avec ce tutoriel, sinon pour les autres…
Phase III:
Bon… félicitation à ceux qui sont restés avec moi… vous avez fait le plus simple… … …
C’est à partir de maintenant que l’on peut commencer à s’amuser !
Vous pouvez obtenir une IPv4 full-stack en plus de l’IPv4 éphémère, car elles sont absolument totalement indépendantes.
Cependant voici le détail de comment j'ai fait et de mon patchwork. Je tiens à préciser que le patch est totalement sauvage et immonde, et si vous changer d’opérateur, il faudra penser à l’enlever potentiellement pour éviter qu’il gêne.
(Pensez également à activer votre IPv4 Full-Stack dans votre espace client)
Voici les paquets que je capturais avec Wireshark:
- Vous avez en rouge l’IPv6 avec lequel le serveur veut communiquer pour le tunnel et l’IPv4 qu’il nous attribue.
- Vous avez en bleu l’adresse du serveur pour l’autre bout du tunnel IPv6.
- Et en vert il s’agit du protocole que l’on essaye d’avoir…
Mais il y a problème ! me direz-vous…
L’adresse du tunnel ne respecte pas du tout le format précédemment vu…
Hé bin oui… Par conséquent, quand on voit ça, on se dit juste :
Borf pas grave… je vais juste créer les tunnels manuellement et les générer avec un script au démarrage… genre avec ce genre de commande:
ip tun add tun6 mode ipip6 local 2a01:xxx:xxx:xxx:0:ffff:ffff:0 remote 2a01:e00:29:200a::fffd dev eth0.836
ip link set mtu 1500 dev tun6
ip link set tun6 up
ip a add dev tun6 82.xx.xx.xx/32
ip a add dev eth0.836 2a01:xxx:xxx:xxx:0:ffff:ffff:0
ping -I tun6 8.8.8.8
ip route del default
ip route add default dev map-WAN6_4
ro lala, comme vous êtes mignon, mes minions… (ouai non enfin bref…)
Non cela ne marche pas, car il utilise pas un simple tunnel ipip6, mais bien un tunnel Map-E modifier car quand on commence à envoyé des paquets dans ce tunnel, les paquets sont envoyés avec le next headers :Destinations options for Ipv6 et le serveur nous répond Parameter Problem (unrecognized Next Header type encountered)
Et vous savez pourquoi… parce qu’ils ont réimplémenté le protocole ipip6 dans iproute!!!!!!
cf. floss.free.fr | Le fichier qui nous intéresse
Super !!! Merci Free… hein !!!!! J’ai dit MERCI FREE !!! HEIN !!! bref passons…
J’avais plusieurs choix, soit prendre les modifications de iproute2 qu’ils ont fait, pour faire fonctionner mes tunnels manuellement, soit trouver le moyen d’adapter Map-e dans Openwrt pour qui intègre la bonne adresse dans le tunnel.
J’ai choisi le 2ᵉ choix pour me simplifier la tâche, car on n'était pas sur la même version majeure iproute (version 5.0.0.2.1 dans openwrt et 4.2.0 dans la Freebox). J’ai même pas eu envie d’essayer de compiler avec une ancienne version iproute ou d’essayer d’adapter les patchs pour la nouvelle version iproute.
Du coup, je me suis attelé à modifier le fonctionnement de map dans Openwrt.
⚠Pour continuer la suite du tuto, il doit se faire TOTALEMENT en ligne de commande, car la version graphique (luci) de map est totalement non fonctionnel⚠
Pour commencer l’adaptation de map, il suffit d’aller regarder le package de map dans Openwrt.
On est rendu à 2 fichiers… ça va… l’analyse va pas être trop compliqué…
Nous avons un script shell et un fichier en C qui est compilé. J’aimerais éviter de devoir recompiler le programme si possible… Et comme j’ai de la chance, j’ai trouvé un moyen de modifier uniquement le script shell.
Pour simplifier le fonctionnement : Le script est appelé lors de l’appel de génération des interfaces (au démarrage). Le script avec des helper lit le fichier /etc/config/network, prends toutes ses options pour map et les écrit dans un fichier.
Le fichier est ensuite lu par le programme en C appelé mapcalc qui prend le fichier et qui lit tous les arguments pour calculer l’adresse la plage de port autorisé (quand c’est pas un full-stack ect.) et plein d’autre truc pour le tunnel.
Ensuite le script reprend la main pour envoyé les résultats du calcul à iproute… (enfin je pense, il y a tellement de helpers que j’ai arrêté de chercher où iproute était appelé)
Partant de ce principe-là j’ai décidé de changer l’adresse du tunnel juste après le passage de mapcalc.
Si vous voulez voir les fichiers dont je parle, ils se trouvent dans /tmp et commence par map.
Ils ne sont présents uniquement quand le tunnel est chargé, dès que le tunnel est déchargé, il est supprimé.
Pour appliquer le patch soit vous faites un nano et vous rajouter les 2 lignes à la main, pour vous télécharger le fichier sur votre ordinateur, car le logiciel patch n’est pas présent sur Openwrt.
Ce patch ci-joint
scp root@192.168.1.1:/lib/netifd/proto/map.sh ~/Bureau/map.sh
patch --verbose ~/Bureau/map.sh map.sh.patch
scp ~/Bureau/map.sh root@192.168.1.1:/lib/netifd/proto/map.sh
Une fois que vous avez appliqué le patch, il faut penser à modifier le fichier /etc/config/network, pour lui ajouter les paramètres du tunnel.
Personnellement j’ai remplacé l’interface WAN existant (et qui servira à rien)
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 à é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 '0' #pas 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'
#################################################
En vrai les options ealen, psidlen, offset, psid sont pas mis au hasard. Ils définissent par des calculs, le nombre de port qui vous sont attribué, le rang, le droit d’utiliser les 1000 premiers ports ect.
Malgré les calculs fournis par la RFC j’ai quand même joué à tatillons pour le full-stack… Je sais pas si c’est moi qui a mal compris la RFC ou si elle est mal implémentée dans Openwrt… mais avec ces options, on est sur du full-stack.
Phase IV :
Nous sommes ici sur la dernière phase, qui est vraiment totalement optionnel si vous ne faites pas l’auto-hébergement. Et même si vous faites de l’auto-hébergement vous n’êtes pas obligé d’utiliser les 2 IPs, mais quitte à en avoir 2, je vais faire du multiwan.
Pour cela il faut installer sur Openwrt mwan3 (et pour luci : luci-app-mwan3).
Mais malheureusement, il est possible que comme pour la phase II, vous soyez obligé de recompiler, pour que les modules noyau nécessaire soit présent.
Une fois le logiciel installé, vous devrez retourner dans /etc/config/network et rajouter dans le fichier l’interfaces WAN6_4, qui est obligatoire pour le fonctionnement de mwan3.
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.
À chaque fois que votre interface IPv6 redémarrera, il connectera automatiquement l’interface au tunnel map
Maintenant que les 2 interfaces sont dans /etc/config/network, vous pouvez modifier le fichier /etc/config/mwan3.
J’ai personnellement effacé toutes la configuration par défaut, car il correspondait pas à ce que je voulais faire.
Voici ma configuration avec les explications :
config globals 'globals'
option mmx_mask '0x3F00'
option rtmon_interval '5'
##############La déclaration des 2 interfaces#################
# Des options qui permet 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és 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ères 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'
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'
Phase V : (quelques jours après la publication de l’article)
Après quelques jours d’une connexion TOTALEMENT instable, j’ai dû me résoudre à remettre les mains dans le cambouis pour retrouver une connexion internet utilisable!
Je ne sais pas si c’est mon routeur qui n’est pas assez puissant pour gérer plusieurs WAN ou si c’est le changement incessant de table de routage par mwan3 qui fais tous foiré, mais nous avons mwan3 qui déconnecte systématiquement les 2 IPv4 l’une après l’autre et parfois les 2 en même temps toutes les 5 minutes, la connexion IPv6 redémarrer quant à elle, toutes les 3h.
Sachant que je souhaitais utiliser ma connexion internet pour faire de l’auto-hébergement et potentiellement un CHATONS pour plus tard. Il n’était pas acceptable que je reste dans ces conditions.
J’ai essayé de nombreuse configuration mwan3, mais aucune n’a permis d’avoir de connexion stable MÊME en n’utilisant qu’une seule IPv4 sur les 2.
J’ai également essayé d’utiliser les 2 IPv4 en même temps sans mwan3, mais impossible d’avoir le moindre résultat à cause de l’IP éphémère de Free. Openwrt est conçue de telle façon à ce que les règles Map-E passe toujours en priorité sur le pare-feu. Et donc systématiquement les règles custom que je créai pour répartir les charges selon leur source ne fonctionne pas non plus.
J’ai également essayé de router tout le trafic sur l’IP full-stack (et garder l’IP éphémère en fail-over). Cependant si les routes sont modifiées de façon manuelle (même avec les outils de Openwrt), l’IP éphémère est redémarré automatiquement pour écraser les routes custom.
Je n’avais donc aucun choix à part soit réécrire Openwrt, soit empêcher Openwrt de charger l’IP éphémère. J’ai donc re-modifier map.sh avec ces lignes-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"`
J’aurais pu terminer le script bien avant pour économiser des ressources, mais je préférais avoir toutes mes modifications au même endroit et donc utiliser quelque ressources à chaque fois que le tunnel essayerait de redémarrer.
(j’ai aussi modifié le patch de façon à ce qu’il soit compatible pour tout le monde)
J’ai malheureusement dû renoncer à l’IP éphémère, mais c’est un moindre mal par rapport à ce que j’ai découvert par la suite (dans un prochain article).
Phase VI: Toujours pas la fin... enfin si, c'est la dernière.
Terminer le script de manière aussi brutale ne plait pas à tous les routeurs. Mon exit 1 fonctionnait sans trop de difficulté et sans prendre trop de ressources sur mon Xiaomi Mi 4A (environ 1 à 2%), mais avec le Nano Pi R4S de nouknouk, il y a eu quelque problème: Post LaFibre.info
Du coup, j'ai cherché un moyen de rendre le truc plus soft et moins hard core. Je sais que Free envoie les données de la route 1/4 IPv4 en permanence et que si on empêche de créer cette interface, il réessaiera non stop tant qu'il n'aurat pas réussi.
J'aurais juste utilisé les routes mais malheureusement Openwrt les écrasent. Du coup, je suis parti du principe qu'il fallait empêcher openwrt de créer la route vers le 1/4 d'IPv4.
Je reste donc sûr la modification de map.sh qui gère presque tout pour nos tunnels.
[ -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
permet de changer l'adresse du tunnel d'entrer (local) s'il s'agit de l'addresse de tunnel de sortie dédié à l'IP full-stack, donc on la garde.
RULE_DATA=`cat "/tmp/map-$cfg.rules"`
permet de mettre à jour les données du script qui ont été modifiés avec la ligne précédemment citée.
[ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
est celle qui pose problème. Son principe était justement de sortir du script si l'adresse du tunnel de sortit était celle de l'ip 1/4. Du coup, on la jette, mais on garde son principe pour la route.
On accepte d'ajouter une route, si et uniquement si l'adresse du tunnel de sortie correspond à l'ip full-stack.
J'ai localisé la création de route à la ligne 134 (environ) avec proto_add_ipv4_route "0.0.0.0" 0
Donc j'ai remplacé cette ligne avec
[ ! -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0
qui permet de ne pas créer de route si l'addresse de sortie ne correspond à l'IP full-stack.
Je vous joins le diff du fichier /lib/netifd/proto/map.sh (testé uniquement sûr 21.02) que vous pouvez appliquer directement sans modification (j'ai utilisé des variables qui sont communes à tout le monde, normalement):
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"`
>
130c134
< proto_add_ipv4_route "0.0.0.0" 0
---
> [ ! -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0
Pour l'appliquer enregistrer le fichier dans tmp par exemple (/tmp/map.patch)
Et appliquez-le, sûr le serveur:
ssh root@192.168.1.1 'opkg update && opkg install patch'
ssh root@192.168.1.1 'patch --verbose /lib/netifd/proto/map.sh' < /tmp/map.patch
FINI :
ET VOILA !!! On a notre full-stack !! Pour trouver tous ça, j’ai mis moins de temps que je le pensais mais plus de temps que je l’espérais… Il m’a fallu 1 semaine avec une moyenne de 8 h par jour pour tout trouver (merci le chômage)
Je sais que normalement sur la VLAN 835 il y a le fonctionnement de la télé et du téléphone, mais j’ai pas réussi et j’ai pas cherché plus que ça, sachant que je ne l’utiliserai pas.
Autre point: j’utilise pas l’IPv4 full-stack comme route par défaut pour pouvoir l’utiliser pour de l’hébergement. (j’ai l’intention de devenir un CHATONS) Et j’ai envie d’avoir une IP dédiée à cela, quitte à en avoir la possibilité et j'ai également changé quelque truc sur mon réseau pour avoir 2 réseaux presque totalement séparer sur mes 2 IP, pour ne pas me faire attaquer de l’intérieur. Mais si vous souhaiter utiliser l’IPv4 full-stack comme route par défaut, à votre convenance, il suffit de supprimer la ligne defaultroute '0' et de supprimer mwan3
Maintenant que vous vous êtes débarrassé de la Freebox : ENJOY !!!
