Si vous n'êtes pas admin de la machine sur laquelle vous êtes (université ?), mais que vous voudriez partager votre connexion, par exemple pour une machine virtuelle ou pour des amis qui voudraient emprunter votre IP ... Il vous faut du NAT (a moins que vous vous contentiez d'un simple tunnel).

Problème : vous ne pouvez pas le mettre en place puisque vous n'êtes pas admin sur la machine qui partage la connexion.
Solution : slirp.

Hé oui c'est tout simple, slirp décapsule du PPP pour l'injecter dans de une socket normale et donc fait l'équivalent du NAT. Mais avec quelques limitations, on ne peut pas faire passer n'importe quel paquet (genre ping) depuis l'espace utilisateur, malgré tout c'est largement suffisant.

Le serveur de NAT (enfin le routeur quoi)

Bon c'est pas si simple mais presque.

Slirp est une commande qui utilise le l'entrée et sortie standard pour communiquer ce qui fait que si on veut l'utiliser à distance il faut le connecter à un "listener", ici nous allons utiliser socat, mais si vous voulez un tunnel chiffré, utilisez stunnel.

Donc vous avez besoin de socat et slirp sur la machine où vous êtes simple utilisateur. Si vous ne les avez pas recompilez les vous avez le droit. Si vous n'avez pas de compilateur copiez-lez depuis une autre machine, si cela ne fonctionne pas, recompilez les chez-vous en statique ... enfin vous êtes grands que diable, ne me posez pas cette question !

Il vous faut un fichier de configuration minimaliste pour slirp (à mettre dans ~/.sliprc) :

ppp
asyncmap 0

Puis lancez le service genre sur le port 2000 (fullbolt = pas de limitation de vitesse) :

$ socat -s tcp4-listen:2000,fork system:/usr/bin/slirp-fullbolt

Le client de NAT (enfin le terminux quoi)

Ici c'est légèrement plus compliqué. Tout d'abord il faut être root puisque nous allons faire un vpn, donc un réseau, donc une interface et du routage. Pour cela il nous faut l'autre bout du tunnel (toujours socat dans l'exemple, mais vous pouvez utiliser stunnel pour faire du ssl) et pppd qui est en quelque sorte le client naturel de slirp.

Petite configuration optimisée de pppd pour correspondre à celle de slirp (à mettre dans /etc/ppp/peers/slirp) :

notty 115200
noauth
lcp-echo-interval 0
asyncmap 0
nodefaultroute
nodetach

Et c'est parti on se connecte :

 
$ socat tcp-connect:host3.enstb.com:2000 system:"pppd call slirp"

Maintenant nous avons une connexion mais un peu spéciale car slirp a des exigences :

• IP : 10.0.2.15
• Réseau : 10.0.2.0/24 (ou autre, il s'en fout)
• Gateway(machine distante) : 10.0.2.2
• IP de commande de slirp : 10.0.2.0 (! une adresse en 0, beware of the netmask !)
• IP spéciale : 10.0.2.1
• + route directe vers l'ip du host

Et ppd configure le tout pas proprement donc il faut supprimer l'ip qu'il a ajouté. Malheureusement slirp non plus n'est pas très doué en configuration réseau et utilise l'adresse 10.0.2.0 ce qui fait que soit vous utilisez un /16 soit vous vous débrouillez pour que 10.0.2.0 soit correctement routée soit vous n'accédez jamais à l'interface de slirp à distance.

Choisissons le premier cas, donc pour activer le routage coté client configurez comme indiqué, en live cela donne :

$ ip addr del 10.0.2.15 dev ppp0
$ ip addr add 10.0.0.0/16 dev ppp0
$ ip route add default via 10.0.2.2 dev ppp0 # tout ce que vous voulez tout router par là

Et oualà !

Forwarding

Slirp est configurable dynamiquement, ce qui veut dire qu'un telnet 10.0.2.0 permet d'accéder à une interface d'admin de slirp.

Les commandes disponibles sont les mêmes que celle qu'on peut mettre dans le fichier de configuration. L'une de ces commandes est redir qui permet de faire des redirections qu'on appellerait port forwarding sur un routeur NAT.

redir [once|time] [udp|tcp] PORT [to] [ADDRESS:]LPORT

Exemple pour permettre l'accès au port ssh local depuis l'extérieur sur le port 2222 :

$ telnet 10.0.2.0
redir 2222 22
quit

Mais encore

Slirp a bien d'autres usages. Au départ slirp a été inventé pour faire du réseau sur un modem.

Mais il est aussi intégré à certains autre outils comme :

• uml : il est possible de définir une interface réseau uml comme étant une interface slirp ce qui vous permet d'avoir une machine virtuelle uml disponible directement sur le réseau local à travers un NAT
• vde : il est possible de définir un lien slirp pour vde ce qui permet tout comme pour uml de mettre en place une certaine forme de NAT derrière un switch virtuel (en général pour un ensemble de vm) sans avoir besoin d'être root
• colinux : colinux intègre aussi slirp pour la même raison

Si je me connecte au réseau local gigabit, que je fais un transfert de fichier ... je n'arrive pas à dépasser 200Mb/s ! Vous rendez-vous compte que c'est normal ?

Vous allez me dire que je ne suis pas doué, mais ce n'est pas moi, ce sont les lois de la physique.

Bon puisque nous somme dans un cas particulier je m'explique.

Temps de réponse

Le débit a beau toujours augmenter, il y a quelque chose qui s'améliore beaucoup moins vite : le temps de réponse. Pour une bonne raison, l'information a une vitesse limite, celle de la lumière. La limite est un peu inférieure sur une fibre optique et encore inférieure sur un câble cuivre.

De plus il faut une certaine électronique pour traiter tous ces paquets et ce débit. Du coup la traversée de switchs et de firewall en fout un coup à la latence. Et pourtant le débit ne change quasiment pas.

Tout ceci se voit avec la commande ping. Si vous lancez un ping sur la machine d'à coté, vous constatez un temps de réponse de l'ordre de la milliseconde.

Par exemple :

PING mamachine (10.0.0.0.1) 56(84) bytes of data.
64 bytes from mamachine (10.0.0.0.1): icmp_seq=1 ttl=61 time=1.16 ms

C'est le temps qu'il a fallu pour créer le paquet ping, l'envoyer à travers le switch, le réceptionner, répondre, repasser dans le switch, lire la réponse. Donc il faut la diviser par deux pour avoir un ordre de grandeur du temps de transfert du paquet.

Pour une machine sur un autre réseau c'est plus dans les 20ms voire 100ms.

Dans cette histoire les plus gros temps de latence dépendent de votre infrastructure, si vous êtes sur une fibre de 100km c'est elle qui contribuera à la latence, si vous êtes sur un réseau local c'est plus le temps de traitement par la carte réseau et le noyau, et s'il y a plusieurs switchs ou un routeurs c'est l'électronique des ces appareils.

Tout ça pour dire qu'il y a plusieurs limitations qui font que la latence ne s'améliore pas aussi vite que le débit.

TCP

Le TCP a été inventé à une époque où le débit d'une connexion était de l'ordre du Mb/s en local.

Une des limite du TCP est la taille des données pouvant être envoyés sans attendre de réponse (window size). Celle-ci est variable mais est limitée à 65535. Ce qui veut dire qu'une fois qu'on a envoyé 64ko de données il faut attendre une réponse, sinon on est coincé.

On voit donc bien une limite en débit apparaître à cause de la latence.

Cette limite est toute simple à calculer :
débit max = taille fenêtre / latence d'un paquet

Ce qui nous donne pour la connexion précédente :
débit max = 64ko*8 / 0.00116 = 450Mb/s

Dommage, je pensais avoir du gigabit !

Donc pensez-y la prochaine fois que vous faites un test de transfert réseau et que vous constatez que vous n'atteignez pas la limite théorique de votre réseau. Commencez par faire un ping et refaites le calcul ci dessus pour voir quelle était la limite.

PS : ce calcul n'est valable que pour une unique connexion. Si vous en avec 2 vous avez deux fois cette limite.

Erreurs

De plus, une chose qu'on ignore car elles sont devenues rares et corrigées, ce sont les erreurs.

Elles ont beau être rares lorsqu'on envoi des milliards d'octets par seconde il commence à y en avoir pas mal.

Chaque perte de paquet provoque un renvoi de touts les paquets non acquittés depuis, soit dans le pire des cas la taille de la fenêtre. La forte utilisation d'un réseau peut augmenter la perte de paquet et donc avoir un impact visible sur le débit total obtenu.

La formule est cette fois :
débit max = MSS / latence / sqrt(Proba perte de paquet)

Pour un réseau local, en général MSS=1460, prenons une perte de 0.1% on obtient :
débit max = 1460*8 / 0.00116 / sqrt(0.001) = 320Mb/s

Encore pire !

La suite

Mais non, TCP a beau être vieux, il a toujours des réserves. 2 évolutions ont donc été ajoutées à ce protocole il y a déjà un certain temps : window scaling et selective acknowledgement.

Window scaling est une extension TCP permettant d'augmenter la taille de la fenêtre jusqu'à 1Go, ça nous laisse un peu de marge.

Sous linux on vérifie l'utilisation de cette option et la taille de fenêtre associée avec :

$ cat /proc/sys/net/ipv4/tcp_window_scaling
$ cat /proc/sys/net/core/wmem_default
$ cat /proc/sys/net/core/wmem_max

Selective acknowledgement permet de demander la retransmission d'un seul paquet et non pas de toute la fenêtre. Cela permet de limiter l'impact des pertes de paquet sur les réseaux avec une forte latence.

Sous linux on vérifie l'utilisation de cette option avec :

$ cat /proc/sys/net/ipv4/tcp_sack

Ferm

Vous battez-vous toujours avec vos scripts shell pour configurer les firewall de vos serveurs ? Ne ramez plus, j'ai la solution : Ferm.

Pourquoi ferm ? Ben pourquoi pas ?

Je l'ai choisi car il ne fait qu'une chose (et le fait bien), il remplace vos scripts shell de lancement de firewall. Et c'est tout ! Pas d'interface graphique, pas d'assistance à création de règle, pas de gestion de votre serveur DHCP ...

Donc si votre machine de bureau sert de passerelle vers internet, ou si vous ne connaissez pas bien iptables, ce n'est probablement pas le meilleur outil. Par contre si vous avez l'habitude d'écrire des scripts shell pour gérer votre firewall, ferm est là pour vous simplifier la vie.

Configuration

Ferm génère des règles iptables à partir de son fichier de configuration. Il n'invente rien, il ne fait qu'écrire sous forme hiérarchique les règles iptables et vous permet d'utiliser des variable et des listes. Il faut donc les connaître un peu.

Petit exemple pour vous montrer comment gagner du temps (il se comprend tout seul) :

@def $SERVERS = (10.0.0.2 10.0.0.3);
table filter {
    chain FORWARD {
        policy DROP;
        proto tcp dport (80 443) daddr $SERVERS ACCEPT;
    }
}

On demande à ferm de générer les règles iptables mais sans les mettre dans le firewall (pas fou) :

$ ferm -n --lines firewall.conf

Et on obtient directement nos 4 règles auxquelles on s'attendait :

*filter
:FORWARD DROP [0:0]
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.3 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.3 --jump ACCEPT
COMMIT

On comprend bien qu'on va gagner du temps en scripting. Il faudra toujours écrire ses propres règles, mais elles seront "standardisées" et factorisées. Donc le transfert de compétence d'une personne à l'autre sera facilité. Le transfert de script aussi puisque ferm sait générer des scripts qui devront être poussés et lancés sur d'autres machines. Pratique pour ceux qui veulent une gestion centralisée des firewall de leurs serveurs/routeurs.

Mieux

Vous aurez remarqué que ferm génère des règles de type "sauvegarde iptables". Ce que je suis sur que vous ne faites pas dans vos script. Et pourtant c'est un gain de performance et de sécurité car l'ensemble des règles sera chargé en mémoire d'un coup.

De plus ferm gère lui-même le lancement du firewall au boot de la machine.

La cerise

Et si vous comptez passer à l'ipv6 ! Hé bien surtout ne faites rien ! Réutilisez le même firewall, entourez vos règles de

domain (ip ip6) {
 ....
}

Et voila votre firewall dualstack est prêt.

Maintenant qu'on connaît Internet, faisons le voyage du petit paquet.

Prélude

Un paquet n'apparait pas subitement du néant, il vient d'une information. Prenons par exemple un concert de Johnny transmis en streaming. L'information est le son, lui-même codé sous une certaine forme, nous avons par exemple le PCM, le MP3 etc. Pour ceux que ca intéresse, vous pouvez étudier les codecs ou déjà les transformées de Fourier. Jusque là ce que sont que des maths et de la physique.

Une fois ces données devenues des nombres, on les code comme des suites d'octets (8 bits, mais c'est historique, pourquoi pas 12 bits ou 18 bits ou même 7 ? mystère), on en fait des groupes de disons 1460 (totalement au hasard) qu'on met dans un paquet.

Ensuite le système ajoute des informations à ce paquet, par exemple un numéro d'ordre, la taille, l'adresse de l'émetteur, ou même des trucs qui ne servent à rien. L'information la plus importante est l'adresse de destination, en IPv4 elle est de la forme 1.2.3.4

Le premier problème est qu'il faut deviner cette adresse, le deuxième problème est que les barbus qui ont inventé ce protocole n'ont pas pensé qu'un jour les gens pourraient ne pas connaître l'adresse IP de la machine avec qui elles communiquent (qui ne connaît pas le numéro de téléphone des ses amis ?).

C'est pourquoi on a dû inventer un autre système qui permet d'obtenir cette information. Il tourne par dessus IP (ouf). Il s'agit du DNS, un annuaire qui permet non seulement de retrouver les adresses des machines depuis un nom lisible, mais aussi qui permet de déménager sans avoir à avertir tout son carnet d'adresse.

Il est bien dommage que ce système n'ait pas été intégré au protocole internet, ça nous aurait évité bien des soucis, mais bon il faut faire avec.

Ça y est, nous avons un paquet, il est rempli avec nos données et toutes les informations nécessaires, comme une enveloppe remplie et timbrée.

Première sortie

Et ensuite ? On dépose l'enveloppe à la poste la plus proche. La plupart des machines connaissent l'adresse de la poste la plus proche (euh non la passerelle) grâce à DHCP, un système mis en place pour diffuser cette information.

Votre machine connaît l'adresse IP de la passerelle, elle utilise alors la seule carte réseau dont elle dispose pour lui envoyer directement le paquet. Si vous êtes chez vous, la poste c'est probablement votre xxxBox. Si vous êtes dans une entreprise, il s'agit d'un routeur caché quelque part derrière un bureau.

Dans le cas d'une yyyBox, elle ne fait qu'une chose, elle envoie le paquet aussi sec vers le seul routeur qu'elle connait, à travers un DSLAM qui se trouve dans un local appartenant à France Telecom au bout de votre ligne téléphonique.

L'autoroute de l'information

Et c'est parti ! Chaque routeur est en fait un centre de tri, il dispose d'un table contenant toutes les adresses du monde (ou presque :-). En effet il est lui-même connecté à d'autres routeurs eux-même connectés à d'autres routeurs etc. Donc il prend l'enveloppe, lit d'adresse et va regarder dans sa table à quel routeur il doit envoyer le paquet. Et hop c'est reparti.

Ainsi mon paquet parti de chez messire Tartempion va passer entre les mains du routeur de son FAI, puis de celui d'un ami de son FAI, puis d'un transitaire qui fait payer cet ami, puis d'un autre routeur ami de mon FAI, puis d'un routeur de mon FAI avant d'arriver chez moi.

Comment ces routeurs peuvent-ils avoir toutes ces informations ? Tout simplement grâce à un protocole nommé BGP. Il permet aux routeurs de s'échanger des messages pour connaître la table de leurs voisins, et donc savoir à qui ils peuvent envoyer des paquets. Les routeurs appartenant souvent à des personnes différentes, le protocole BGP permet d'appliquer une stratégie de décision choisie par le propriétaire. Par exemple "X ne me paie pas bien, essaie d'abord de passer par Y à moins que ce ne soit impossible".

Les propriétaires de ces routeurs s'appellent des AS. Mais un propriétaire donné peut avoir plusieurs routeurs. Ces routeurs communiquent entre eux, mais cette fois sans arrière pensée politique et donc utilisent un protocole différent, comme par exemple OSPF.

L'arrivée

Et enfin le dernier routeur de la chaîne, le facteur va me délivrer le paquet.

Ma machine va ouvrir l'enveloppe et récupérer le contenu du paquet. Elle va aussi tenter de mémoriser quelques informations comme l'adresse de retour, pour au cas où ...

Si ma machine fait tourner un logiciel qui comprend les paquets envoyés par messire Tartempion, alors elle va pouvoir lire le paquet et récupérer les divers nombres qu'il contient, puis hop, mathématiques, physique, Fourier, codecs, on retrouve 1ms de Johnny.

Postlude

Voilà ce qu'on appelle l'autoroute de l'information. Plusieurs choses sont importantes sur cette autoroute.

Tout d'abord il y a généralement un péage qui permet de l'entretenir. C'est votre abonnement à internet. Mais ensuite personne ne vous demande ce que vous transportez, ça peut être du vin ou une lettre d'amour, l'important est uniquement d'arriver à bon port. C'est ce qu'on appelle la neutralité du net. Pas de filtrage, pas de discrimination, peut-être aura-t-on un jour une haute autorité de lute contre les discriminations sur internet !

Ensuite tout le monde doit parler le même format de paquet pour se comprendre. Et ce format n'appartient à personne. Si chacun parlait son propre format, ce ne serait pas internet.

Enfin internet est fait de toutes les machines connectées à internet. Si personne ne se connecte, si personne n'envoie de paquet, internet n'existe pas.

Et l'ipv6 dans tout ca !

Hé bien, c'est justement un autre format de paquet, avec des adresses différentes. C'est donc un autre réseau, on pourrait l'appeler internet 2 ou alternet si ce n'était pas déjà pris. Et c'est pour cette raison qu'IPv6 ne marche pas. Lorsqu'on parle de passer à IPv6, on ne parle pas de mettre à jour un logiciel, mais de se connecter à un nouveau réseau, un autre, différent. Ce sera donc très très long, comme de passer du français à l'espéranto. Comme de passer du téléphone à internet.

Qu'est-ce qu'Internet ? Cette question, dont la réponse parait évidente à beaucoup n'est pas facile à expliquer.

Internet expliqué à ma mère

Et plutôt que d'expliquer ce qu'est Internet, je vais plutôt expliquer comment marche Internet, car c'est son fonctionnement qui le définit.

Internet est un ensemble de réseaux (net) interconnectés (inter) grâce au protocole IP (internet protocol) aussi appelé IPv4. Ce protocole ne fait qu'une seule chose (et le fait bien :-), transférer des informations (mail, télévision ...) sous forme de petits paquet d'un appareil à un autre.

Internet est caractérisé par le fait que tout internet est accessible par tout internet. Si mon téléphone est connecté à internet alors internet est connecté à mon téléphone. S'il peut envoyer un paquet sur internet (par exemple 1s de musique), on peut aussi lui envoyer un paquet depuis internet.

Donc pour que mon appareil soit sur internet il lui faut seulement 2 choses :

• parler le protocole IP
• être connecté à internet

Internet ce n'est que ça. Mais il y a beaucoup d'autres choses à dire sur internet.

Internet expliqué à mon père

Sur internet on trouve énormément de choses. Malheureusement la plupart des gens n'en connaissent qu'une, le web, j'y reviendrai.

Sur internet il on trouve :

• les emails : un email est découpé en petits paquets qui sont envoyés par IP à une autre machine qui va les stocker dans un coin en attendant que l'utilisateur vienne les chercher
• le téléphone : les applications comme skype ou ekiga découpent votre voix en petits paquets et les envoient à un autre appareil sur internet
• le peer to peer : ce sont les applications qui profitent le plus du concept d'internet, tout ce qu'on y trouve y est découpé en petits paquets qui sont transférés à de multiples personnes, ces personnes peuvent alors enregistrer ces paquets et les retransmettre à d'autres personnes, le nombre de personnes connectées en permanence fait que la plupart de ces paquets sont toujours disponibles
• la messagerie instantanée : chaque message est mis dans un paquet et envoyé au destinataire

On y trouve aussi quelques autres service un peu moins visibles :

• les news : un système de diffusion de messages au monde entier
• irc : un système de communication instantané fonctionnant par groupes de discussion
• ssh : un système de prise de contrôle à distance d'appareils
• ... : il y en a des milliers, il m'est impossible de tous les citer ici

Internet expliqué à ma fille

Comme je le disais, sur internet on trouve le web, c'est l'univers le plus connu du grand public. Le web fonctionne grâce à des logiciels comme firefox ou chrome et des serveurs eux aussi connectés à internet. Ce logiciels font plusieurs choses (donc pas toujours forcément bien :-), ils prennent une adresse que vous leur indiquez et vont trouver le serveur correspondant et lui demandent la page web. Celle-ci est renvoyée par le serveur, découpée en petits paquets, comme d'habitude.

Une fois récupérée cette page est affichée par le navigateur. Elle peut contenir énormément de choses, ça peut être la page de google, ça peut être votre page facebook ... il y en a des milliards.

Et comme internet est internet, il suffit d'être connecté à internet pour voir ces pages. Sauf bien sûr s'il y a un système de protection mis en place spécialement pour n'autoriser que l'accès à certaines personnes, comme pour un compte twitter.

Internet expliqué à mon fils

Voila, c'est tout, Internet c'est comme un bar, on y trouve de tout, il y a un groupe qui chante sur scène et pendant ce temps un couple se forme à une table, d'un côté quelqu'un téléphone à sa femme pendant que de l'autre un groupe de discussion se forme.

Internet c'est un bar à l'échelle de la planète. Mais ce n'est qu'un bar. Il ne sert à rien de le fermer, on ne put empêcher aux gens de discuter, par contre il est possible d'écouter le voisin, d'intercepter ses conversations ...

La prochaine fois nous passerons à une version légèrement plus technique.

Niveau :
Résumé : proxy ndp

Aujourd'hui nous allons parler d'IPv6. Pas du troll sur son arrivée imminente (ou pas), mais de situations qui nécessitent l'utilisation d'une fonctionnalité du noyau linux appelée proxy NDP.

Rappels sur IPv6 et NDP (les habitués d'IPv6 peuvent passer)

En IPv4, on dispose du protocole ARP pour trouver, à partir de l'adresse IP, l'adresse MAC à laquelle envoyer le paquet Ethernet sur le même réseau. Si c'est sur un autre réseau, il suffit d'avoir une table de routage et de connaître le routeur (la passerelle) pour cette destination, à qui on envoie le paquet.

En IPv6, on fait fi d'ARP pour utiliser ICMPv6. Vous me direz, on ne fait que reporter le problème, on n'a toujours pas l'adresse MAC : c'est là qu'intervient la notion de lien local. En effet vous avez déjà du remarquer qu'à peine votre interface réseau montée, vous disposez d'une adresse de lien local (obtenue à partir de votre adresse MAC).

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:19:66:8c:b0:d9
          inet6 addr: fe80::219:66ff:fe8c:b0d9/64 Scope:Link
[...]

De la même manière, vos voisins sur le même lien Ethernet ont leur adresse de lien local, et c'est en utilisant celle-ci combinée au protocole ICMPv6 qu'on voit passer les requêtes NDP (Neighbor Discovery Protocol) de découverte de voisinage. On y retrouve exactement le principe de l'ARP d'IPv4 (who has/target is at), avec un nouveau vocabulaire (neighbor solicitation/neighbor advertisement).

# tcpdump -ni eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:06:29.756895 IP6 2a01:e35:3e93:68c0:4d0a:f82b:3678:aaac > ff02::1:ff8c:b0d9: ICMP6, neighbor solicitation, who has 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9, length 32

16:06:29.757294 IP6 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9 > 2a01:e35:3e93:68c0:4d0a:f82b:3678:aaac: ICMP6, neighbor advertisement, tgt is 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9, length 32

Problème

Ce petit rappel étant fait, voici le problème que l'on peut rencontrer en IPv6 : un fournisseur de connectivité IPv6 vous donne (annonce) depuis son routeur un /N sur lequel vous pouvez utiliser des adresses IPv6. Là où le bât blesse, c'est que son routeur désire voir à plat (sur le même lien local) toutes les IPv6. Impossible donc à première vue de placer votre routeur juste après celui du fournisseur et d'organiser les IPv6 en réseaux comme bon vous semble. A noter qu'on rencontre le même problème en IPv4 avec un fournisseur qui donne un /N et qui veut le voir à plat. Dans ce cas de figure, on peut utiliser le proxy ARP (dans le noyau). La méthode pour l'IPv6 présentée plus bas est ni plus moins son homologue en IPv6.

On rencontre cette situation par exemple chez Free, où la Freebox annonce un /64 (l'abonné dispose même d'un /60), ou encore chez OVH lorsque vous possédez un serveur dédié, où le routeur d'OVH vous annonce un /56 rien que pour vous (même si dans le manager c'est indiqué un /64, vous pouvez utiliser ce /56). Je présume que c'est le cas pour d'autres opérateurs, ou d'autres hébergeurs comme Dedibox.

Que l'on veuille organiser son réseau domestique avec son propre routeur IPv6 derrière sa freebox, ou que l'on veuille répartir en sous-réseaux le /56 de son serveur dédié dans des machines virtuelles ou des containers, le routeur veut voir le réseau à plat (sur le même lien) c'est ce qui pose problème. La solution évidente serait de pouvoir faire du routage : si on pouvait intervenir sur la table de routage de ce routeur (via le manager d'OVH, via la console de gestion de Free, ou via le protocole DHCPv6 s'il est implémenté me dit peck (NDM(note de moi): rechercher prefix delegation)), il suffirait de dire que pour joindre tel sous-réseau il faut contacter le routeur à l'adresse donnée. Malheureusement, on ne peut pas pour l'instant, il faut donc trouver autre chose.

La solution que je vais vous proposer et détailler est un proxy NDP : il s'agit de faire croire au routeur (la freebox ou le routeur OVH) qu'il voit votre réseau à plat (sur le même lien), en transférant les messages NDP d'un côté et de l'autre. Cette solution n'est pas nouvelle : Thierry Fournier propose depuis maintenant 1 an et demi un excellent tutorial rapportant son expérience avec l'IPv6 chez Free et comment il a organisé son réseau domestique. Le Wiki Gentoo dispose lui aussi d'un excellent article à ce sujet.

Une autre solution, plus ancienne, est d'utiliser le brouting ou switch filtrant (on route l'IPv4 et on laisse passer l'IPv6), mais je ne la détaillerai pas.

Solution à base de proxy NDP

Pour résumer, il va s'agir de :

• posséder un noyau linux supérieur à 2.6.19, à partir duquel le proxy NDP a été implémenté
• activer le routage IPv6 et le proxy NDP dans le noyau
• organiser son réseau (côté routeur) en sous-réseaux (côté LAN)
• router ces sous-réseaux du routeur vers les LANs
• configurer les hôtes
• configurer le proxy NDP côté LAN pour que les hôtes aient connaissance du routeur
• configurer le proxy NDP côté routeur pour que le routeur ait connaissance des hôtes

Pour la suite, comme les explications pour Free ont déjà été données sur Internet, je vous propose d'expliquer le proxy NDP dans le contexte d'un serveur dédié chez OVH avec des machines virtuelles (VM). Notez bien que c'est le même principe, juste le contexte de l'explication qui diffère.

Voyons comment ce réseau IPv6 s'organise :

.----------. 2001:2:3:4500::/56   .---------------.
| routeur  |______________________|    serveur    |
|   IPv6   |                  eth0|     dédié     |
*----------*                      *---------------*
                                veth1 |        | veth2
                                      |        |
                   2001:2:3:4501::/64 |        | 2001:2:3:4502::/64
                                      |        |
                                 eth0 |        | eth0
                                    [VM 1]   [VM 2]

Comme vous le voyez, le routeur fournit à ce serveur le préfixe 2001:2:3:4500::/56 :

2001:0002:0003:45 00::
\_______________/ \_..._/
 partie réseau     partie pour le serveur
    (56)            (72)

Que l'on va diviser en deux /64 pour chaque VM :

• 2001:2:3:4501::/64 pour la VM1
• 2001:2:3:4502::/64 pour la VM2

A noter que chez OVH, votre routeur est joignable sur le /56 suivi de 5*FF. Supposons alors que dans notre cas, le routeur soit à l'adresse 2001:2:3:45FF:FF:FF:FF:FF.

Sur le serveur, on route ces sous-réseaux vers les VM :

# ip route add 2001:2:3:4501::/64 dev veth1
# ip route add 2001:2:3:4502::/64 dev veth2
# ip -6 route list
2001:2:3:4501::/64 dev veth1  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:4502::/64 dev veth2  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:45FF:FF:FF:FF:FF dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:4500::/56 dev eth0  proto kernel  metric 256  expires 2427074sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev veth1  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev veth2  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295

Avant d'aller plus loin, n'oubliez pas d'activer le routage IPv6 ainsi que le proxy NDP. Par exemple avec les directives suivantes dans /etc/sysctl.conf suivi d'un sysctl -p pour appliquer :

net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1

Bien entendu, vous pouvez activer cela plus finement uniquement sur les interfaces concernées.

Pour la configuration des hôtes, il s'agit juste de leur indiquer qui est leur routeur, la route par défaut vers ce routeur, et enfin d'ajouter une ou plusieurs adresses dans le préfixe alloué. Par exemple, on configure la VM1 avec l'adresse 2001:2:3:4501::1/64 :

# ip route add 2001:2:3:45ff:ff:ff:ff:ff/128 dev eth0
# ip route add default via 2001:2:3:45ff:ff:ff:ff:ff
# ip address add 2001:2:3:4501::1/64 dev eth0
# ip -6 route list
2001:2:3:4501::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
# ip -6 address list
1: lo:  mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500
    inet6 2001:2:3:4501::/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::218:51ff:fede:aca9/64 scope link
       valid_lft forever preferred_lft forever

La même chose pour la VM2 avec l'adresse 2001:2:3:4502::1/64.

Il faut maintenant configurer le proxy NDP côté LAN pour que les hôtes (VM) aient connaissance du routeur. Sur le serveur et pour chaque interface où il faut faire apparaître le routeur avec le proxy NDP, procéder comme suit :

# ip neigh add proxy 2001:2:3:45ff:ff:ff:ff:ff dev veth1
# ip neigh add proxy 2001:2:3:45ff:ff:ff:ff:ff dev veth2

La même chose de l'autre côté pour que le routeur ait connaissance des VM. Pour chaque adresse IPv6 utilisée par les hôtes (VM), il faut explicitement la faire apparaître avec le proxy NDP. Par exemple pour les 2 VM où on a configuré l'adresse ::1 :

# ip neigh add proxy 2001:2:3:4501::1 dev eth0
# ip neigh add proxy 2001:2:3:4502::1 dev eth0

Enfin, il faut mettre l'interface côté routeur en mode promiscuous, afin de pouvoir prendre les paquets qui ne lui sont pas destinés mais destinés aux VM :

# ifconfig eth0 promisc

Les interfaces vers les VM n'en ont pas besoin car elles sont virtuelles. Dans le cas de Free avec des hôtes réels connectés à une interface réelle, il sera nécessaire de mettre l'interface côté hôtes en mode promiscuous aussi.

Maintenant, vous devriez avoir l'IPv6 disponible sur vos VM, et organisé comme il vous plaît. Si cela ne fonctionne pas, vous pouvez analyser le réseau en différents points (eth0, veth1, veth2, eth0 des VM) pour voir (ou ne pas voir justement) les paquets IPv6 qui passent :

tcpdump -ni <interface> ip6

Enfin, comme le fait remarquer l'article sur le wiki Gentoo, on peut procéder à la configuration automatique des VM en faisant tourner un démon radvd sur le serveur pour annoncer le préfixe utilisable ainsi que l'adresse du routeur. Cela ne vous affranchira cependant pas d'ajouter manuellement le proxy NDP pour chaque IPv6 utilisée, et c'est l'inconvénient majeur de cette technique. Mais après tout, dans le cas de serveurs les IPv6 utilisées sont choisies à l'avance, et pour les postes clients le plus souvent l'adresse IPv6 est obtenue à partir de l'adresse MAC, alors on s'en sort.

Si vous trouvez un moyen de voir les IPv6 utilisées dans les sous-réseaux et d'automatiquement ajouter le proxy NDP, faites-le savoir ! Ça doit être faisable à coup de tcpdump sur les neighbor solicitation, mais c'est moche...

J'espère avoir été clair et vous souhaite de bien vous amuser avec l'IPv6 ! Si vous avez des questions, n'hésitez pas.

NDM: il y a moyen de faire sans promisc et avec du proxy NDP d'un coté seulement, mais reste a retrouver les bonne conditions pour que ça marche.

L'interface de loopback se retrouve sur toutes les machines ou presque. pensez à l'activer si ce n'est pas fait par défaut car un certain nombre d'applications en dépendent et son absence peut parfois mener à des bugs inexplicables (à ce propos évitez de mettre un firewall bloquant 127.0.0.1 ...). Mais comment fonctionne-t-elle ?

Localhost

Tout d'abord l'adresse de loopback (127.0.0.1) permet par convention de contacter la machine locale sans passer par une interface qui serait accessible de l'extérieur. Cette fonctionnalité est en soit disponible sur n'importe quelle interface réseau. Il faut juste ajouter une entrée de firewall pour éviter l'accès depuis l'extérieur. Exemple pour prouver que c'est une ip comme une autre :

# on enlève le range d'ip de l'interface lo
$ ip addr del 127.0.0.1/8 dev lo
# on l'ajoute à une interface physique
$ ip addr add 127.0.0.1/8 dev eth0
# on teste
$ ping 127.0.0.1

En pratique, rien n'empêche cette ip d'être accessible publiquement si ce n'est que ce n'est pas recommandé et que linux ne répondra pas (je n'ai pas vraiment cherché à savoir pourquoi).

Device lo

Lo est l'interface de loopback. Celle sur laquelle on met habituellement l'adresse de localhost. Mais cela n'empêche de mettre d'autres ip sur cette interface. Dans un contexte de routeur c'est même très fréquent. Le routeur dispose d'un ip publique qui n'est sur aucune de ses interfaces.

Exemple :

$ ip addr add 172.16.20.1 dev lo
$ ping 172.16.20.1

Le but n'est pas de contacter localhost, mais de contacter le routeur depuis n'importe où, à travers n'importe quelle interface, cette ip est indépendante de l'état des différentes cartes réseaux.

Exemple dans lequel m1 serait un routeur ayant une interface 10.0.0.1 connectée à m2 directement sur le même réseau :

# Première machine
m1$ ip addr add 172.16.20.1 dev lo
m1$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Deuxième machine, on contacte le loopback de m1
m2$ ip route add 172.16.20.1 via 10.0.0.1
m2$ ping 172.16.20.1

L'interface de m1 agit comme un routeur pour son ip de loopback.

Un autre usage particulier de cette adresse est d'autoriser plusieurs machines à disposer de la même ip, sans les annoncer sur le réseau (puisqu'elles ne sont sur aucune interface publique). On peut ainsi éviter les conflits (arp ...). C'est par exemple la solution retenue pour faire de la répartition de charge avec keepalived entre plusieurs serveurs ayant la même ip publique.