Association Bordelaise des Utilisateurs de Logiciels libres
User-Mode-Linux (3) : relier une machine virtuelle au réseau
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.
Notes
[1] - pour un particulier, disposer de plusieurs distributions
simultanément sans avoir à consacrer une machine pour chaque. Par
exemple pour utiliser des logiciels qui n’existent que sur des Debian
"unstable" voire "testing" sans mettre en péril votre brave Woody (la
version stable actuelle). Et pourquoi pas une Mandrake,
en plus de la Slackware.
– pour un ingénieur sécurité, faire tourner des machines
volontairement mal protégées, histoire de voir
les pirates à l’oeuvre (honeypots).
– pour une entreprise ou une institution, faire tourner des
services accessibles de
l’extérieur sur une machine dédiée, par mesure de sécurité (par
exemple une machine pour le DNS, une autre pour un serveur LDAP ...)
– pour un "centre de calcul" fournir une ferme de machines
virtuelles aux utilisateurs, pour
qu’ils fassent tourner chacun leur serveur Web etc. sans mettre en
péril la sécurité des autres utilisateurs. Au fur et à mesure de
l’évolution des besoins, ces machines virtuelles pourront être
déménagées facilement vers des hôtes supplémentaires.
Vous voyez, les applications ne manquent pas.
[2] sinon
ça ne s’appellerait pas une interface
[3] La technique standard :
– créer un groupe d’utilisateurs "umlusers"
hote# addgroup umlusers
– lui donner l’accès par
hote# chmod 660 /dev/net/tun
hote# chgrp umlusers /dev/net/tun
– y mettre les personnes concernées
hote# usermod -FG umlusers dupont
[4] voir détails dans les mini-HowTo
Proxy-ARP
et/ou
Proxy-ARP-Subnet.
Attention, le mandatement ARP de sous-réseau ne fonctionne
plus depuis les noyaux 2.2.x !)
[5] personnellement je ne trouve pas raisonnable de faire du bidouillage réseau sur un firewall !