Association Bordelaise des Utilisateurs de Logiciels libres

Faire causer entr’elles des machines virtuelles, c’est bien. Les relier
au réseau, c’est encore mieux.

Quoi, pourquoi, qui ?

On veut maintenant relier une machine virtuelle au réseau : on pourra
maintenant lui causer depuis une machine réelle, que ce soit la machine
machine hôte, ou toute autre machine.

Il y a plein d’applications intéressantes. Voir note de bas de page [1] si vous n’en êtes pas convaincus.

Reste à savoir qui : pour connecter votre machine virtuelle,
il vous faudra obligatoirement une intervention de l’administrateur root.
C’est assez logique : vous auriez besoin de ses services si vous vouliez
raccorder des machines à la sienne par une carte
réseau supplémentaire dans sa machine, et on
va voir que ce n’est pas très différent.

Vue d’ensemble

Dans l’article précédent, vous avez vu comment raccorder des machines
virtuelles sur un switch virtuel. Il ne reste plus qu’à relier ce switch
à notre machine hôte par une carte d’interface virtuelle, et à
assurer le routage pour que ça fonctionne.

Fixons un but :
– nous avons un réseau local avec les adresses
privées 172.16.*.* (netmask 255.255.0.0)
– la plage d’adresses 172.16.99.* (netmask 255.255.255.0) est
actuellement inoccupée. Nous allons la squatter pour notre sous-réseau
de machines virtuelles.
– sur une des machines de ce réseau, nous
voulons installer une machine virtuelle d’adresse 172.19.99.1, qui sera
accessible depuis le reste du réseau.

Voila la feuille de route
– créer une interface qu’on appellera uml0 avec tunctl
– la configurer pour l’intégrer au réseau existant
– lancer le switch virtuel avec un branchement sur l’interface
(uml_switch -tap uml0)
– démarrer la machine virtuelle et configurer son routage.

Création de l’interface virtuelle (par root)

Une interface réseau, c’est un truc qui discute par deux bouts [2]. D’un
côté, il y a un bout qui s’appelle eth0 (ou lo, ppp0 ...)
et qui échange des paquets IP avec la couche réseau de la machine hôte.

De l’autre côté, c’est du code qui échange des blocs de données (contenant
des paquets) avec un dispositif matériel - une carte réseau - en allant taper
dans les registres, la mémoire partagée, les interruptions et tout ça.

Ici nous allons utiliser une interface réseau spéciale, baptisée
TUN/TAP. Description traduite librement de
/usr/src/kernel-source-2.4.18/Documentation/networking/tuntap.txt :

`` TUN/TAP permet la réception et l’envoi de paquets par des programmes
utilisateurs (user space). On peut le voir comme un simple dispositif
(device) Point-à-Point ou Ethernet qui, au lieu de recevoir des
paquets d’un support physique, les reçoit de programmes normaux (et
inversement).’’

Ca tombe bien, uml_switch est précisément un de ces programmes. Pour pouvoir utiliser cette interface, il faut que l’administrateur
– fasse charger le module "tun" (à la main : modprobe tun)
– crée le périphérique /dev/net/tun

hote# mknod /dev/net/tun c 10 200

– donne le droit aux "lanceurs de machines virtuelles" de l’employer.
 [3]

Ensuite, il doit créer l’interface uml0, en précisant le nom
du propriétaire du futur switch.

hote# tunctl -u dupont -t uml0

(cette interface devra être recréée à chaque redémarrage de la machine hôte).

Configuration de l’interface virtuelle (par root)

Encore un petit effort.
– notre interface uml0 va servir de passerelle entre la machine hôte et
le sous-réseau
virtuel. On lui donne une adresse IP

hote# ifconfig uml0 172.16.99.254 netmask 255.255.255.0

– on annonce à tout le réseau local (qui est supposé connecté par l’eth0
de la machine hôte)
que pour causer avec la future machine virtuelle 172.16.99.1,
il faut envoyer les paquets à la machine hôte, qui transmettra

hote# arp -Ds 172.16.99.1 eth0 pub

C’est la technique du "Proxy-Arp" [4]
– et on convainc la machine hôte qu’il faut faire suivre (to forward)
les paquets qui
lui sont envoyés, mais qui ne lui sont pas directement destinés

hote# echo 1 > /proc/sys/net/ipv4/ip_forward

Quelques remarques :
– on doit pouvoir agir sur l’ip_forward des seules
interfaces concernées mais c’est fatigant.
– si votre machine hôte
sert également de firewall (iptables ou autres) pensez à ajouter des
règles pour permettre et contrôler l’accès à cette interface
suplémentaire. Bon courage dans ce cas [5].

Lancement du switch virtuel et de la machine

Le plus dur est fait. L’utilisateur dupont lance le switch par

hote$ uml_switch -tap uml0

et la machine virtuelle, comme d’habitude (avec eth0=daemon, évidemment).
Y a plus qu’à configurer son interface réseau

virtuelle# ifconfig eth0 172.16.99.1 netmask 255.255.255.0

A ce point-là, les machines hôtes et virtuelles peuvent déjà se "pinger"
par les adresses 172.16.99.1 et 172.16.99.254.

Reste plus qu’à désigner la machine hôte comme passerelle de la machine virtuelle

virtuelle# route add default gw 172.16.99.254

et voilà c’est fini. Normalement, la machine virtuelle est en état de dialoguer
avec le reste du réseau privé, et de joindre le reste du monde si ce réseau
privé est lui même connecté à internet, avec les proxies ou une passerelle de sortie
et le masquerading (NAT) qui convient.

Pour les distraits

N’oubliez pas de mettre un mot de passe au compte root de votre machine
virtuelle.