Free propose à présent l'IPv6, ça, tout le monde a compris. Et le geek moyen qui utilise un Linux mitonné aux petits oignons comme routeur, il utilise la technique de Sébastien Chaumontet [http://ip6.fr/free-broute/] pour en profiter.
Oui mais voilà, le geek particulier qui utilise des routeurs Linksys WRT54GL (au hasard) tournant sous OpenWRT WhiteRussian, il fait comment ? En deux temps, trois mouvements, en s'inspirant du tuto précédent :
* on installe ce qu'il faut : ipkg install ebtables (il faut aussi le paquet bridge mais normalement il est présent par défaut)
* on charge les modules nécessaires au démarrage :
root@OpenWrt:~# cat /etc/modules
ebtables
ebtable_broute
ebtable_nat
ebtable_filter
(les deux derniers sont inutiles ici mais bon...)
* enfin, on met les règles qui vont bien pour ajouter l'interface WAN (vlan1) au bridge local (br0) et pour ne laisser entrer sur le bridge depuis le WAN que les paquets IPv6. Concrètement, ça fait deux lignes en plus à la fin de S40network :
root@OpenWrt:~# cat /etc/init.d/S40network
#!/bin/sh
case "$1" in
start|restart)
# snip le blabla standard (...)
brctl addif br0 vlan1
ebtables -t broute -A BROUTING -i vlan1 -p ! ipv6 -j DROP
;;
esac
* enfin, on n'oublie pas de désactiver radvd et les éventuels tunnels sixxs ou autres qu'on aurait pu mettre en place par le passé, sinon ça fout la zone.
Avantage : ça marche bien, tout seul, tout de suite. Même avec le wds activé (c'est mon cas).
Inconvénient : je me demande si la config en question ne laisse par fuiter quelques paquets du réseau local vers Internet (du moins vers la Freebox, qui doit les filtrer j'imagine). J'ai essayé de trouver un filtrage plus strict pour les paquets sortants, mais sans succès - si un gourou d'ebtables passe dans le coin, qu'il n'hésite pas.
Danger : si vous oubliez le "-i vlan1" dans la commande ci-dessus, j'espère pour vous que vous connaissez l'adresse IPv6 de votre routeur, parce que vous venez de vous couper la patte ;-) (ouaip, on sent le vécu) Alors prudence dans les essais...
Voilà, ce texte est dans le domaine public, passez-le à vos amis, tout ça, en espérant que ça puisse aider certains.
# Oui mais... DD-Wrt !
Posté par superna (site web personnel) . Évalué à 1.
[^] # Re: Oui mais... DD-Wrt !
Posté par superna (site web personnel) . Évalué à 1.
Connectez vous à votre interface d'administration DD-WTR.
Dans Administration/Management :
Activez IPV6
(Désactivez Radvd si activé)
Sauvez la config.
Ouvrez Administration/Commands et entrez :
brctl addif br0 vlan1
ebtables -t broute -A BROUTING -i vlan1 -p ! ipv6 -j DROP
=> Remplacez vlan1 par ppp0 si vous êtes en PPPOE
Et cliquez sur Save Startup
Redémarrez le routeur en bas de Administration/Management.
Normalement ça devrait faire le même effet !
[^] # Re: Oui mais... DD-Wrt !
Posté par superna (site web personnel) . Évalué à 1.
[^] # Re: Oui mais... DD-Wrt !
Posté par superna (site web personnel) . Évalué à 1.
ebtables -t broute -A BROUTING -i vlan1 -p ipv6 -j ACCEPT
Qui accepterais sans condition touts les packets ipv6 venant de vlan1 dans le bridge ?
[^] # Re: Oui mais... DD-Wrt !
Posté par MrLapinot (site web personnel) . Évalué à 2.
Le problème, c'est que par défaut tous les paquets du bridges sont "acceptés" (comme si c'était le même réseau). Il faut donc, comme présenté dans l'article, une règle négative : on spécifie que c'est tout ce qui n'est pas de l'ipv6 qui doit être routé classiquement (donc exclu du bridge). Ceci vaut naturellement si la policy de BROUTING est ACCEPT ; si elle est mise à DROP (ce qui serait un peu bizarre, on perd l'intérêt d'un bridge, mais pourquoi pas), ta remarque devient pertinente - mais il faut alors ajouter d'autres règles ACCEPT selon ses besoins.
[^] # Re: Oui mais... DD-Wrt !
Posté par Aurélien Bompard (site web personnel) . Évalué à 1.
~ # ebtables -t broute -A BROUTING -p ! ipv6 -j DROP
The kernel doesn't support the ebtables 'broute' table.
Vous avez fait comment ?
C'est énervant j'arriveà pinguer l'extérieur en IPv6 mais aucun autre protocole ne passe...
Merci !
[^] # Re: Oui mais... DD-Wrt !
Posté par MrLapinot (site web personnel) . Évalué à 2.
# Marche pas sur les Linksys WRT54GS
Posté par Gilles Mocellin . Évalué à 1.
Et là, pas de modules ebtables, notament le fameux ebtable_broute...
A moins que quelqu'un connaisse un portage ?
D'autre part, il y a déjà un bridge, hors une interface ne peut pas faire partie de deux bridges. Est-il judicieux de mettre toutes les interfaces dans le bridge ?
Vous allez dire oui, car la règle ebtables n'autorise que l'IPV6 entre l'interface Internet et l'interface interne.
Question subsidiaire :
Shorewall ne permet pas d'établir des règles pour IPV6, comment on fait pour ne pas resté ouvert au grand Ternet (simplement) ?
Oui oui, on contribue à shorewall...
[^] # Re: Marche pas sur les Linksys WRT54GS
Posté par alexissoft . Évalué à 1.
[^] # Re: Marche pas sur les Linksys WRT54GS
Posté par Victor . Évalué à 1.
[^] # Re: Marche pas sur les Linksys WRT54GS
Posté par alexissoft . Évalué à 1.
En plus, le conntrack ipv6 a été ajouté relativement récemment (j'ai dit relativement) dans Linux 2.6, et faire un firewall sans, c'est un peu comme recopier l'intégrale de Kant avec un clavier de téléphone portable.
[^] # Re: Marche pas sur les Linksys WRT54GS
Posté par MrLapinot (site web personnel) . Évalué à 2.
Apparemment, il y a un problème de stabilité d'ebtables avec le noyau 2.4 : https://dev.openwrt.org/ticket/2482
Problème qui se pose peut-être aussi avec WhiteRussian ? En tout cas, chez moi ça a l'air de bien fonctionner. Cela dit, si tu t'en tiens à un noyau 2.4, pourquoi ne pas utiliser WhiteRussian (plus limitée, certes, mais déjà bien fournie) ?
Ouaip, c'est la question que je me suis posée. D'où mon inquiétude de laisser fuir certains paquets. Je n'ai pas vraiment de réponse ; c'est clair en tout cas que ça tient plus du hack dégueu que de la solution idéale.
On utilise ip6tables. Mais comme on veut le suivi de connexion, on a besoin d'un noyau 2.6.20 au minimum. Donc on utilise kamikaze. Ah oui, mais on n'a pas le driver binaire tout pourri pour faire fonctionner le wifi - et le driver libre pour 2.6 est instable. Monde proprio, monde de merde...
[^] # Re: Marche pas sur les Linksys WRT54GS
Posté par Thierry B . Évalué à 1.
Effectivement tjs pas de paquet kmod-ebtables, dans la dernière Kamikaze 7.09.
A croire qu'il vaut mieux rester sous WhiteRussian lol :-(
# Plus simple ?
Posté par benoar . Évalué à 2.
On peut simplement ne pas natter les paquets en ipv6. Genre dans la chaine FORWARD, on a une règle qui -j ACCEPT l'ipv6 et une autre qui -j MASQUERADE l'ipv4 ? Non ?
[^] # Re: Plus simple ?
Posté par Victor . Évalué à 1.
[^] # Re: Plus simple ?
Posté par benoar . Évalué à 2.
# tunnel 6to4rd avec routeur externe
Posté par Thierry B . Évalué à 1.
Voici une copie d'un post du fil de discussion proxad.free.services
Ca permet (je ne l'ai pas testé), de faire en sorte à ce que ca soit le routeur qui etablisse le tunnel 6to4rd, et apparemment, ca marche avec une vieille Freebox non degroupé.
Mais bien entendu, il faut désactiver le mode ipv6 de la console d'admin, pour que le routeur puisse lui mm etablir le tunnel.
Voila la copie du post.
++ :-)
-----------------------------------------------------------------------------------
Je ne sais pas si l'information est déjà passée (pas ici, en tout cas).
Je viens de chercher à faire marcher le nouveau service IPv6 en non-dégroupé
et avec une vielle freebox : apparemment, ça marche parfaitement.
Ça se fait de la même manière qu'un tunnel 6to4 classique, à ceci près que :
- Le préfixe à ajouter est 2a01:5d8::/32 au lieu de 2002::/16 (donc pour
l'adresse IPv4 x.y.z.t, ça donne 2a01:5d8:xy.zt::/64).
- L'extrémité du tunnel est ::192.88.99.100 (au lieu de ::192.88.99.1, mais
apparemment, ils en ont profité pour créer leur propre ::192.88.99.1).
Sur mon routeur (un WRT54G), j'ai configuré ça :
ip tunnel add tun6to4 mode sit remote any local x.y.z.t
ip link set tun6to4 up
ip -6 addr add 2a01:5d8:xy:zt::1/128 dev tun6to4
ip -6 addr add 2a01:5d8:xy:zt::1/64 dev br0
ip -6 route add 2000::/3 via ::192.88.99.100 dev tun6to4 metric 1
ip -6 route add 2a01:5d8:xy:zt::/64 dev br0
J'imagine que la même manoeuvre doit marcher en dégroupé si on n'active
_pas_ IPv6 dans l'interface d'administration. Ce qui permet d'avoir un vrai
routeur configurable pour gérer la connexion.
-------------------------------------------------------------------------------------
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.