Journal IPv6, Free & OpenWRT

Posté par (page perso) .
Tags : aucun
0
17
déc.
2007
Bonjour à tous,

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 (page perso) . Évalué à  1 .

    Et pour nos amis Geek qui n'ont pas le temps de s'installer une OpenWRT aux petit oignons mais quand même en profiter simplement avec DD-WRT !
    • [^] # Re: Oui mais... DD-Wrt !

      Posté par (page perso) . Évalué à  1 .

      Je me réponds a moi même, mais sans tester ! (Vive l'administration distante ;-) )

      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 (page perso) . Évalué à  1 .

        Finalement peut-être pas... Enfin si des connaisseurs connaissents, qu'ils donnent des infos plus pertinantes !
        • [^] # Re: Oui mais... DD-Wrt !

          Posté par (page perso) . Évalué à  1 .

          Dans DD-WRT, puisqu'un bridge regroupe toutes les prises eth et les vlan, ce ne serait pas mieux remplacer par :

          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 (page perso) . Évalué à  2 .

            > Qui accepterais sans condition touts les packets ipv6 venant de vlan1 dans le bridge ?

            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 (page perso) . Évalué à  1 .

        Sur mon DD-Wrt v23 SP2 std la commande ebtables ne marche pas :

        ~ # 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 !
  • # Marche pas sur les Linksys WRT54GS

    Posté par . Évalué à  1 .

    En effet, pour avoir le wifi, il faut utiliser OpenWRT kamikaze avec le noyau 2.4.
    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 . Évalué à  1 .

      Pour faire de l'ipv6 avec shorewall, il faut utiliser le fork qui s'appelle 6wall. Je sais pas si c'est encore maintenu, mais quand je l'utilisais, ça tournait plutôt impec.
      • [^] # Re: Marche pas sur les Linksys WRT54GS

        Posté par . Évalué à  1 .

        C'est pas vraiment maintenu, mais je l'utilise et ça marche à peu près bien pour une configuration simple.
        • [^] # Re: Marche pas sur les Linksys WRT54GS

          Posté par . Évalué à  1 .

          De toute façon rien ne vaut les règles ip{,6}tables à la main.

          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 (page perso) . Évalué à  2 .

      En effet, pour avoir le wifi, il faut utiliser OpenWRT kamikaze avec le noyau 2.4.
      Et là, pas de modules ebtables, notament le fameux ebtable_broute...


      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) ?

      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.


      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.

      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...


      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 . Évalué à  1 .

      Hello,

      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 . Évalué à  2 .

    C'est moi qui ai loupé quelque chose ou il existe bien plus simple ?
    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 . Évalué à  1 .

      L'interet ici est d'avoir le même réseau devant et derrière le routeur pour que l'autoconfiguration marche.
      • [^] # Re: Plus simple ?

        Posté par . Évalué à  2 .

        Merde, j'avais oublié ça. Merci. Faut tout réapprendre avec ipv6...
  • # tunnel 6to4rd avec routeur externe

    Posté par . Évalué à  1 .

    Hello à tous,

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.