<markdown>
Atelier Wifi n°1 : Pont bridgé et routage IPv6
*Voir aussi [l'atelier #2](https:////wiki.faimaison.net/doku.php?id=projets:wifi:ateliers:2_vlans_et_dhcpv6).*
# Idée générale
Un machine *« routeur faimaison »* (une VM) se voit attribuer un bloc d'une certaine taille (en IPv6 uniquement pour les tests), on le subdivise en réseaux plus petits, chacun de ces « petits » blocs étant attribué aux « abonnés » présents sur le réseau wifi.
Le traffic est acheminé entre l'« abonné » et le routeur sur un réseau wifi niveau 2 (L2), le routeur se charge du routage de chaque « petit » bloc entre le réseau wifi faimaison et internet.
Chaque « petit bloc » est sous la responsabilité d'un abonné, libre à lui de gérer son adressage comme il le souhaite en son sein.
Dans nos tests, le « petit bloc » est routé sur un ordinateur portable qui n'en utilise qu'une adresse ; dans la réalité, cela pourrait-être un petit routeur domestique qui dispatche les adresses au sein du foyer de l'adhérent.
# Tunnel IPv6
## Obtention du tunnel ipv6
Hurricane Electric (HE par la suite) a la bonne idée de proposer des tunnels ipv6 gratuits via ce [site - tunnel broker](https://www.tunnelbroker.net)
Cela nous permet de mettre en place facilement un tunnel ipv6 entre notre vm de routage et le point de sortie le plus proche, en l'occurence Paris (histoire de changer)
Une fois le compte activé, il faut bien penser à:
- Renseigner l'ip publique de notre passerelle
- Activer le bloc /48 fourni par HE
L'interface web de tunnel broker est relativement bien faite, notamment l'onglet configuration qui permet d'obtenir facilement la configuration nécessaire selon notre système d'exploitation, dans notre cas Debian GNU/Linux. On va donc modifier notre fichier /etc/network/interfaces afin de lui ajouter les paramètres de notre tout nouveau (tout beau) tunnel:
<pre>
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
# L'adresse v6 attribuée à notre machine, de notre côté du tunnel, donc (dans le /64 donné par HE)
address 2001:470:1f12:592::2
netmask 64
# Le endpoint IPv4 se trouve dans le panel d'administration du compte sur HE
endpoint ipv4_du_point_de_sortie
# IPv4 locale : peut être une RFC 1918 si on est sur un LAN derrière un NAT, ou bien une IP publique
local ip_v4_locale_de_notre_vm
ttl 255
# L'ipv6 de la passerelle chez HE
gateway 2001:470:1f12:592::1
</pre>
On sauvegarde et on relance notre service networking:
<pre>
service networking restart
</pre>
Notre tunnel est normalement déjà disponible, on peut en tester la fonctionnalité avec un simple:
<pre>
ping -6 ipv6_passerelle
</pre>
De plus, il ne faut pas oublier de modifier la route v6 par défaut (::/0) qui doit pointer vers la passerelle HE, sur notre périphérique virtuel représentant le tunnel, ici he-ipv6:
<pre>
ip -6 route add default via 2001:470:1f12:592::1 dev he-ipv6
</pre>
## Assignation des blocs du /48 fourni par HE ### Petit rappel: comment ça fonctionne?
Là où ipv4 utilise 32 bits répartis en 4 octets (pour la lisibilité), ipv6 utilise 128 bits répartis en *quads* de 16 bits, notés en hexadécimal par souci de lisibilité. Tout comme pour ipv4, la notation CIDR indique le nombre de bits qui seront réservés à notre sous-réseau, les bits restants étant réservés à nos hôtes et/ou à nos autres sous réseaux (c'est beau :])
Le bloc fourni par HE étant un /48, cela signifie que les 48 premiers bits (les 3 premiers quads) sont réservés (on ne peut pas faire mumuse avec, snif). Celà nous laisse quand même 80 bits pour définir nos sous réseaux et donner des adresses à nos « abonnés ».
Nous avons décidé d'utiliser des blocs en /56 que nous distribuerons à nos « abonnés », ce qui signifie que les 8 premiers bits du quatrième quad seront utilisés pour définir les adresses de ces sous-réseaux. 2^8=256, nous avons donc 256 sous-réseaux disponibles, et nos clients auront 2^72 adresses assignables possibles (qu'ils pourront bien entendu, de leur côté, rediviser en sous-réseaux, etc). On se rend compte au vu de ces chiffres de l'intérêt d'ipv6, surtout lorsqu'on est au courant de l'inéluctable pénurie d'adresses ipv4.
### Configuration de la VM de routage
Il faut renseigner le fait que l'interface (ici eth0) réseau de notre machine connaît le(s) sous-réseau(x) ipv6 défini(s). Par exemple pour 2001:470:c90b::/56 (premier bloc /56 disponible):
<pre>
ip -6 route add 2001:470:c90b::/56 dev eth0
</pre>
De même, il est important d'activer l'ipv6 forwarding dans le fichier /etc/sysctl.conf afin que nos clients puissent recevoir les réponses aux jolis paquets v6 qu'ils envoient vers l'extérieur.
La commande:
<pre>
sysctl -p
</pre>
permet de recharger la conf' du noyau directement, sans avoir à redémarrer (encore heureux)
### Notes
- il est important que toutes les antennes wifi soient configurées de la même
manière et utilisent [WDS](http://lists.tetaneutral.net/pipermail/technique/2012-April/000273.html)
- les clients doivent renseigner leur route par défaut via l'adresse ipv6 de lien local de l'interface eth0 de notre VM (fe80:…etc) qui sera donc leur passerelle.
# DHCPv6
## Configuration d'isc-dhcp server
Important : soit on lance le serveur dhcp “à la main” avec le paramètre -6, soit on copie et modifie le fichier /etc/init.d/isc-dhcp-server afin de rajouter ce paramètre et le fichier de configuration utilisé dans les fonctions status et start
Pour que notre serveur dhcp puisse assigner des adresses sur plusieurs vlans préalablement configurés (eth0.1, eth0.2… eth0.256) il est nécessaire de modifier le fichier /etc/default/isc-dhcp-server, afin qu'il puisse écouter sur toutes ces sous-interfaces logiques :
<pre>
INTERFACES="eth0.1, eth0.2, etc"
</pre>
Pour le moment, nous n'avons pas encore pu réellement tester la fonctionnalité. De même, assignerons nous la “zéroieme” (en fait la première) adresse de chaque bloc à la sous-interface logique correspondante ou pas (ça simplifierait la config. Alternativement, on peut aussi lancer un serveur dhcp par vlan)?
### fichier /etc/dhcp/dhcp6.conf
<pre>
default-lease-time 600;
max-lease-time 7200;
option dhcp6.name-servers ipv6_du_dns;
subnet6 2001:470:c90b::/56 {
range6 2001:470:c90b::1 2001:470:c90b::9; #un range de 9 hôtes, pour test
# notre but étant d'assigner des blocs /56, il faudra tester prefix6 start_subnet end_subnet /masque;
}
</pre>
Pour le moment, nous n'avons pas encore obtenu un setup fonctionnel, il est donc nécessaire de refaire un atelier rapidement afin de pouvoir régler les quelques problèmes auxquels nous avons été confrontés, notamment:
- vm bridgée, les vlans ne “passent” pas, apparemment: les requêtes dhcp arrivent sur eth0, pas sur eth0.2 dans le cas de notre test
- configuration exacte des nanostations
- N'y aurait-il pas une configuration/setup plus simple à mettre en œuvre?
TODO…
Plein de choses ;)
</markdown>