Aujourd'hui on fait des nœuds.

Comme deux exemples valent mieux qu'un, je vous propose d'étudier 2 cas :

• la personne qui a 2 cartes réseau (wifi, pas wifi) pointant vers le même routeur
• la personne qui un routeur (genre pour une résidence) pointant vers plusieurs FAI

Comment faire pour répartir les connexions entre les différentes sorties proposées sans tout casser ?

iproute 2

Heureusement tout est dans le noyal ! La table de routage sait faire ce genre de chose.

Contrairement à ce qu'on pourrait croire mettre 2 routes par défaut ne marche pas. Le noyau n'en choisirait qu'une et la garderait jusqu'à ce que quelqu'un intervienne.

Il est par contre possible d'avoir une route vers une destination pointant vers plusieurs intermédiaires en même temps. C'est ce que fait l'option nexthop de la commande ip route.

Deux cartes réseau

Prenons le cas de la personne qui a 2 interfaces vers le même routeur :

$ ip route add default nexthop  via 10.0.0.1 dev eth0 weight 100 nexthop via 10.0.0.1 dev wlan0 weight 1

On choisit un poids de 100 pour faire en sorte d'utiliser presque toujours la première route plutôt que la deuxième. Bien sûr si une des routes est indisponibles, seul l'autre sera utilisée. Mais le système de routage ne le sait que grâce à l'interface elle même, il faut donc que l'interface supporte miimon pour détecter le débranchement d'un câble ou que vous la désactiviez à la main.

Ce genre de problème serait probablement mieux résolu avec un bridge ou du bonding, mais ce le sujet d'un prochain article.

Deux FAI

Plus difficile, prenons le cas de la personne qui a 2 FAI :

$ ip route add default nexthop  via 10.0.0.1 dev eth0 weight 1 nexthop via 192.168.0.1 dev eth1 weight 1

Et n'oubliez pas que pour que ca marche vraiment, il faudra que vous ayez du NAT quelque part (pour ipv6 on en reparle lorsque ça existe).

Il faut savoir que la table de routage dispose d'un cache. L'avantage est qu'il n'y a pas spécialement besoin de bidouiller avec le source routing pour que ça marche, ça fonctionne tel quel. L'inconvénient est qu'il n'y aura qu'une seule route par destination. Le partage de charge ne sera donc pas nécessairement équilibré puisque si tout le monde va sur youtube, un seul FAI sera utilisé.

Pour équilibrer le transfert de paquet il y a l'option equalize, mais elle nécessite d'une part un patch du noyau et d'autre part de passer un certain temps à faire sa configuration réseau car il faut maintenant router à la main les paquets d'une même connexion vers le même FAI (sinon le destinataire est perdu). C'est une solution plus compliquée mais qui peut être utile si vous n'avez que peu d'utilisateur ou de destinataires.

Enfin le failover ne se fait automatiquement que dans un cas, si le réseau est désactivé sur une carte (laquelle doit suporter mii-tools) . Sinon vous devez le faire manuellement :

$ ip link set dev eth0 down

Et si vous voulez le faire automatiquement lorsqu'un FAI ne répond plus, c'est à vous de mettre un script qui va vérifier la connectivité et faire des modifications si besoin.

Si vous avez aimé, il y a aussi :

1. Aggrégation de lien
2. Routage amélioré
3. Interface de loopback

Le routage IP est communément défini en fonction de la destination. Remarquez c'est logique. La fonction d'un routeur est de faire en sorte que les paquets arrivent à bon port (héhé), la route à prendre ne devrait dépendre que de cette destination.

Mais comme pour les GPS, il peut parfois y avoir quelques options à prendre en compte, êtes vous un camion (passage de tunnels) ou un piéton (passage d'escaliers) ? Pour toutes les options de routage qui ne dépendent pas uniquement de la destination, linux utilise ce qu'il appelle "policy based routing" qui est une option qui doit être activée dans le noyau (c'est le cas pour la plupart des distributions).

Le concept est simple. Vous écrivez des règles pour matcher les paquets, lesquelles vont décider de la table de routage à choisir. La table en question étant une table de routage tout ce qu'il y a de plus standard telle que vous connaissez sous linux.

Les tables

Les tables se créent et se gèrent avec ip route (comme d'hab). Exemple :

$ ip route add default via 10.0.0.1 table 1
$ ip route add default via 10.0.0.2 table 2

Vous avez 255 tables à votre disposition, j'espère que vous saurez en profiter.

Vous pouvez donner un nom plutôt qu'un numéro à votre table. C'est tout simple, il suffit d'éditer le fichier /etc/iproute2/rt_tables. Et voila :

$ ip route del default table matable

Remarquez que les fichiers permettent de nommer de nombreuses choses qui sont représentées par des numéros pour la commande ip.

Et pour le contenu des routes, c'est la commande show, par défaut c'est la table "main" qui est affichée avec la commande "ip route show". Pour en voir une autre :

# la table local ne doit pas être modifiée à la main, elle est gérée par le noyau
$ ip route show table local

Ça c'était la partie facile.

Les règles

Les règles se créent avec ip rules

Il est possible de créer des règles sur l'adresse source, l'interface réseau sur laquelle le paquet a été reçu, ou même sur une marque posée sur le paquet par netfilter (fwmark, ça permet de faire tout et n'importe quoi). Pour la liste complète, voyez le manuel.

$ ip rule add iif eth3 table matable

Par défaut 3 règles existent, la première force le passage par la table "local" pour les route gérées par le noyau. Les 2 dernières servent de défaut et pointent vers la table de routage habituelle : "main". On peut les voir avec :

$ ip rule show

Exemple

Supposons un monde composé d'un centre de production (avec des serveurs), d'un réseau avec des postes de travail et d'un accès au monde extérieur.

On va faire passer les postes de travail à travers un firewall pour sortir et pas les serveurs.

# TABLE SPÉCIFIQUE : routage spécifique pour les paquets en provenance du réseau user
$ ip rule add iff ethUser table 1
# pas de firewall pour accéder aux serveurs en interne
$ ip route add $SERVER_NETWORK dev ethServer table 1
# on les envoi vers le firewall par défaut
$ ip route add default via $FW_IP table 1

# TABLE PRINCIPALE : ne pas oublier de répéter les règles communes
$ ip route add $SERVER_NETWORK dev ethServer
# et une route de sortie aussi pour les non User
$ ip route add default via $3G_BOX

PS : pour ceux qui ne savent pas encore que je suis sur twitter, cette semaine c'est une série d'astuces réseau.

Si vous avez aimé, il y a aussi :

1. iproute2
2. Aggrégation de routes
3. Respections le protocole

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 vous avez aimé, il y a aussi :

1. Faire communiquer des socket avec socat
2. Des lutins dans votre noyau
3. Aggrégation de routes