OLSR, c'est bien. Ca permet de propager des tables de routage entre des clients qui ne se connaissent pas.
IPv4, c'est bien. Mais nous sommes actuellement en pleine phase de migration vers IPv6, pour augmenter le champ d'adressage, mais aussi pour tirer parti des protocoles d'autoconfiguration, et de découverte.
IPv6, c'est parfaitement adapté aux réseaux maillés, et aux hôtes hétérogènes.
Le hoquet, c'est que -- premier hic -- ce n'est pas reconnu par tout le monde, que c'est relativement pour les utilisateurs finaux que nous sommes,
c'est -- second hic -- un espace d'adressage totalement différent, et c'est -- troisième hic -- une pile de protocoles différents, de ce que l'on connaît actuellement.
Ce HOWTO traite d'IPv6, IPv4, d'OLSR, sous Linux.
1/ Monter un routeur IPv4Après avoir testé le firmware IPv6 de Earthlink, qui ne permet pas de faire du AdHoc, et le firmware Alchemy, qui ne permet pas de faire de l'IPv6, je me suis rabatu sur quelque chose de plus roots. Le FreiFunk Firmware allemand.
WRT54G et Freifunk. [[TODO: faire une page FreiFunk]]
J'utilise deux LANS, un sur le filaire, un sur le WIFI. J'ai donc deux adresses IP différentes sur le routeur Linksys.
Entre le filaire et le Wifi, il y a un routeur/firewall. Il dispose également d'une DMZ, et de tunnels vers d'autres lieux.
2/ Monter un routeur IPv6L'IPv6, quel que soit le firmware, n'est pas géré par l'interface WEB. Il va donc falloir écrire les fichiers de configuration en dur, deans le /etc
La première étape, c'est d'aller chercher le module IPv6 pour le noyau linux :
Mettre à jour la liste de paquets disponibles, pour la FreiFunk :
ipkg update
ipkg install kmod-ipv6 Puis de faire en sort qu'il soit aujouté au noyau à chaque démarrage, par la création d'un fichier /etc/init.d/S42ipv6 :
#!/bin/sh
insmod ipv6
ip -6 addr add 2001:aaaa:bbbb::2/64 3/ Paramétrer OLSR pour l'IPv4Pas de piège majeur, tout se fait par le biais de l'interface d'administration.
Quelques fichiers de la ROM à passer en mode "lecture écriture" :) on en aura besoin plus tard :
rm /etc/init.d/S53olsrd
cp /rom/etc/S53olsrd /etc/init.d/ rm /etc/local.olsrd
cp /rom/etc/local.olsrd
cp /rom/etc/local.olsrd.eth1
cp /rom/etc/local.olsrd.br0
Dans le configuration par le WEB, vous avez du voir un paramètre "HNA4". Laissez le vide, nous en reparlerons plus tard. 4/ Paramétrer OLSR pour l'IPv6
Ajouter les lignes "Ip6AddrType global" dans les deux fichiers local.olsrd.eth1 et br0
Cela permet à OLSRd de s'intéresser aux adresses IP routables sur internet que vous devaz normalement avoir sur vos boitiers.
Pour lancer olsrd manuellement, en ipv6, il faut taper :
# olsrd -ipv6 Facile.
Enfin... à condition d'avoir au minimum la version d'olsr 4.9, qui règle des soucis de "bind" UDP. Qui laisse des soucis d'interprétation de paquets, là, présentmenet, j'ai un peu de verbosité et de fausses routes ip4, mais globalement ça marche.
Sauf que.. sur mon routeur, ça marche bien. Sur mes WRT54G... il ne veut pas démarrer, au motif qu'un port, qu'il souhaite "binder", est utilisé.
En fait, il s'agit du port de managment, permettant en HTTP d'obtenir les valeurs actuelles de OLSR.
La bonne idée serait d'avoir deux fichier deux fichiers de configuration, un pour ipv4, qui binde le port 8080 du module HTTPInfo sur une IPv4, et un pour IPv6, qui fasse la même chose, mais sur une adresse IPv6.
Le souci de la FFF, c'est qu'elle recrée un fichier de configuration pour OLSRd de manière dynamique, à partir des valeurs stockées dans la NVRam, dans le fichier /var/etc/olsrd.conf
Deux solutions : soit éditer le /etc/init.d/S53olsrd pour qu'il utilise des fichiers statiques, dans /etc,
soit éditer le /etc/init.d/S53olsrd pour qu'il recrée de manière dynamique le /var/etc/olsrd.conf de manière différentielle, au lancement du démon en ipv4, et en ipv6.
A cette heure, je n'ai pas trouvé où se cachaient les adresses IPv6 dans la NVRam, je stocke donc tout à la main, et lorsque je lance un olsrd, par la méthode "classique", puis un "olsrd -f /etc/olsrd6.conf -ipv6", juste après, dans le /etc/init.d/S53olsrd.
Dans ce fichier olsrd6.conf, la section suivante a été supprimée :
LoadPlugin "olsrd_httpinfo.so.0.1"
{
PlParam "port" "8080"
PlParam "Host" "127.0.0.1"
PlParam "Net" "192.168.1.0 255.255.255.0"
} ainsi que
IpcConnect
{
MaxConnections 1
Host 127.0.0.1
Net 192.168.1.0 255.255.255.0
}
TODO: trouver une meilleure solution, et binder les ports 8080 sur les adresses IPv4 et IPv6 en fonction du démon. A tester.
Autre problème de l'olsrd en IPv6, le non fonctionnement du plugin dyn_gw. Il faut donc annoncer manuellement la route globale par défaut, ie. 2000::/3, sur l'équipement qui possède la connectivité internet -- le cas échant, bien sûr --.
Cela se faut, on le verra plus tard, dans la configuration du HNA6.
5/ poser un routeur externeDans ma configuration, je dispose d'une appliance qui me sert à tout. C'est mon serveur personnel à moi. 24x7, monitoring assuré par le relevé régulier de courrier.
Elle dispose de la connectivité ipv6, des services de messagerie et DNS, de l'accès ADSL, et de tout un tas de choses très pratiques.
Par contre, elle n'a pas de WiFi. J'y ai monté un démon olsrd, en utilisant le paquet debian "olsrd", que l'on trouve sur les sources debian suivantes (à ajouter dans le /etc/apt/sources.list) :
deb http://www.skyhub.de/debian/ unstable main
deb-src http://www.skyhub.de/debian/ unstable main
Le démon est paramétrer pour écouter sur les interfaces locales, et les différents tunnels.
Pareil, une instance en ipv4 est lancée, et une instance en ipv6 ("olsrd -ipv6") est démarrée.
Le module dyn-gw est chargé sur CET olsrd, et uniquement celui là, les routes se propagent à tous les noeuds avec ou sans fils, équipés d'un démon OLSR, et paramétrés tels qu'indiqués plus haut.
En outre, si les routeurs à base de WRT54G, de MA configuration,
sont des relais pour le réseau citoyen, je dispoe d'un routeur
statique, filaire, sous debian, qui m'assure la connectivité vers les
réseaux que je citais en préambule.
J'ajoute donc une section "HNa4", dans le fichier oslrd.conf, qui annonce à ses voisins (neighbors) qu'elle dispose de la connectivité vers ces réseaux :
Hna4
{
# DMZ
192.168.150.0 255.255.255.0
# LAN
192.168.1.0 255.355.355.0
# Autres réseaux citoyens :
10.0.0.0 255.0.0.0
}
# HNA IPv6 routes
# syntax: netaddr prefix
Hna6
{
# Mon préfixe, route par défaut
2001:686:abcd:: 64
# Le préfixe du voisin, par le biais d'un tunnel
2001:7a8:5c0:: 64
}
HNA4, doit vouloir dire "Host Network Access IPv4"
Pour l'anecdote, HNA4, en vocabulaire numérique médical, c'est un taux de mortalité.
HNA6, c'est la pression systolique sanguine.
C'est beau, et magique, de voir les p'tites tables de routage se propager :)
Nota: Routage par défauten IPv4, la connectivité "par défaut" se note, dans la section HNa4 "0.0.0.0 0.0.0.0".
En IPv6, elle se note, dans la section HNa6 : "2000:: 3"
Dans la documentation, il est noté ":: 0", ce qui correspond effectivement à tout l'espace d'adressage IPv6.
En l'occurence, ce qui nous intéresse, c'est uniquement l'espace d'adressage global qui nous intéresse, ie. 2000::/3 [[TODO: une explication plus approfondie des classes d'adsresses IPv6, notamment la différente entre local, link, et global]]
6/ Quelques commandes ipv6 pour Linux :en ipv4, les adresses s'écrivent 1.2.3.4
en ipv6, les adresses s'écrivent :
2001:2:3::4, ou
2001:aaaa:bbbb::1.2.3.4
ou 2.0.0.1.a.a.a.a.b.b.b.b.0.[...].1.2.3.4
et pour les manipuler :
ip -6 route get monhost:que:je:veux::trouver
ip -6 addr show
ip -6 addr add PREFX::HOST dev
ip -4 route help
ip -4 addr
7/ comment obtenir de l'accès IPv6 ?
-> freenode.net facile, rapide, mais basé aux états unis. 300ms de latence au ping entre les deux bouts du tunnel IPv6 "sur" IPv4 qui sert à relier leur réseau ipv6 et le client ipv6
-> sixxs.net rapide, efficace, performant, mais très regardant sur les qualités de l'administrateur du point. Un faut pas, et hop ! ejecté sans espoir de retour. A utiliser avec beeeeeaaaucoup de précautions (ils offrent un service de qualité, pour des non débutants)
-> nerim.net en propose de l'accès natif.
8/ Addendum
Deux ou trois trucs qui manquent et que je vais rajouter :
- la méthode est la même, quelle que soit la couche linux au dessous,
pour avoir le double olsrd v4/v6. Les paramètres du fichier de
configuration sont les mêmes.
- Le paquet debian olsrd est fourni avec un excellent fichier de
configuration, très pratique, pour comprendre rapidement à quoi
correspondent les options du olsrd.conf. Il suffit ensuite de poser les
paramètres ad hoc (nan, pas le mode wifi :) dans le /etc/local.olsrd* en
fonction du besoin
- comme olsrd tout seul, ne sait pas gérer deux piles, il faut deux
olsrd (pratique comme info). Il y a pourtant quelques pièges pour faire
tourner deux olsrd en simultané sur une même machine. D'où le howto.
- la méthode la plus pratique pour démarrer les deux olsrd, c'est
déditer le script de lancement. Pour la fff, c'est /etc/init.d/S53olsrd,
qui par défaut est un lien dans la "rom"... enfin... la partie de flash
ram en lecture seule :) .
- la méthode la plus pratique pour stopper olsrd, c'est killall olsrd.
C'est d'ailleurs la technique utilisée par les scripts fff (et debian,
puisqu'il n'y a pas de pidfile transmis à start-stop-daemon
- un démon olsrd, c'est en moyenne 3 process. Peut-être plus, peut-être
moins. Avec la double pile, cela fait donc 6 démons.
Par exemple, sur ma machine linux :
asr@greedo:~$ ps fax | grep olsr
25380 pts/4 S+ 0:00 | \_ olsrd -ipv6 -d 3
25381 pts/4 S+ 0:00 | \_ olsrd -ipv6 -d 3
25382 pts/4 S+ 0:00 | \_ olsrd -ipv6 -d 3
22760 pts/8 S+ 0:00 | \_ olsrd -d 3
22761 pts/8 S+ 0:00 | \_ olsrd -d 3
22762 pts/8 S+ 0:00 | \_ olsrd -d 3
Où l'on voit que deux process "père" olsrd tournent, ayant tous les
deux, un fils, et un petit-fils.
Là, ils sont en mode debug, pour voir ce qui s'y passe. Et il se passe
des choses anormales, sur le process gérant le v4, comme ça :
Alias list for 32.1.5.192: 32.1.5.192 - 0.0.1.52 - 0.0.0.0 - 5.192.0.0 -
32.1.7.168 - 255.0.93.204 - 0.0.0.1 - 0.0.0.0
Received MID from NON SYM neighbor 138.242.0.1
HYST[138.242.0.1] HELLO timeout 0.250
HYST[5.192.0.0] HELLO timeout 0.002
HYST[138.242.0.1] HELLO timeout 0.125
HYST[5.192.0.0] HELLO timeout 0.001
HYST[138.242.0.1] HELLO timeout 0.063
HYST[5.192.0.0] HELLO timeout 0.001
HYST[138.242.0.1] HELLO timeout 0.031
HYST[5.192.0.0] HELLO timeout 0.000
HYST[138.242.0.1] HELLO timeout 0.016
HYST[5.192.0.0] HELLO timeout 0.000
HYST[138.242.0.1] HELLO timeout 0.008
HYST[5.192.0.0] HELLO timeout 0.000
HYST[138.242.0.1] HELLO timeout 0.004
HYST[5.192.0.0] HELLO timeout 0.000
Got HELLO vtime: 6.000000 htime: 0.062500
HYST[5.192.0.0] HELLO timeout 0.000
HYST[138.242.0.1] HELLO timeout 0.251
Got HELLO vtime: 6.000000 htime: 0.062500
HYST[138.242.0.1] HELLO timeout 0.125
HYST[5.192.0.0] HELLO timeout 0.250
HYST[138.242.0.1] HELLO timeout 0.063
HYST[5.192.0.0] HELLO timeout 0.125
HYST[138.242.0.1] HELLO timeout 0.031
HYST[5.192.0.0] HELLO timeout 0.063
HYST[138.242.0.1] HELLO timeout 0.016
Je suppute une mécompréhension des paquets v6 par le démon v4.
Un bug olsrd, sans doute, et peut-être qu'il pourrait être résolu en
diminuant l'intervalle entre les HELLO.
|
|
|
|
|
