Association Bordelaise des Utilisateurs de Logiciels libres

Accueil ›› Utilisation de logiciels libres ›› Système ›› User-Mode-Linux (3) : relier une machine virtuelle au réseau

User-Mode-Linux (3) : relier une machine virtuelle au réseau

Posté le lundi 17 novembre 2003 par MIB

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.

[2sinon
ça ne s’appellerait pas une interface

[3La 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

[4voir 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 !)

[5personnellement je ne trouve pas raisonnable de faire du bidouillage réseau sur un firewall !

Répondre à cet article

3 commentaire(s)
  • Posté le 26 novembre 2004 à 13:43, par stefan (lien)

    Bonjour,

    j’ai suivi le plan pour installer UserModeLinux , ca fonctionne,
    j’ai néanmoins détecté quelques fautes de frappe dans les adresse IP ...
    Une fois vous utilisez 172.16.99.** et une autre fois 172.16.94.**
    Voila,
    Je vous remercie pour vos explications ...

    Si vous avez encore d’autres informations à donner sur UserModeLinux, faites moi signe ... (je réalise un mémoire pour la fin de mes études en informatique qui se repose sur UML ...)

    Bien à Vous

    Stefan

    repondre message

  • Posté le 29 novembre 2004 à 12:14, par stefan (lien)

    Bonjour,

    pour mon mémoire je dois utiliser UML,
    En suivant ce manuel, j’arrive à lancer UML ( enfin, je n’ai qu’une seule consolle et pas trois comme décrit précédemment ...)
    J’aimerais plutôt prendre un noyeau linux et le patcher pour avoir un uml compilé par moi-même, seulement , peu importe la version du noyeau que je choisisse avec son uml patch correspondant, la compilation ne fonctionne pas ! enfin, j’obtient toujours une erreur (différente selon le noyeau).
    La seule fois où cette compilation a fonctionné c’est quand je n’ai rien modifié avec le
    ’make menuconfig ARCH=um’ ,
    j’ai essayé une fois juste de permettre les modules loadable, et la compilation génére des erreurs ,
    voici les quelques dernières lignes affichées à la fin de cette compilation qui ne marche pas :

    rm -f arch/um/sys-i386/module.c
    ln -sf /mnt/uml/test3/linux-2.6.0/arch/i386/kernel/module.c arch/um/sys-i386/mod ule.c
    CC arch/um/sys-i386/module.o
    arch/um/sys-i386/module.c : Dans la fonction « apply_relocate » :
    arch/um/sys-i386/module.c:79 : error : R_386_32' undeclared (first use in this fu nction) arch/um/sys-i386/module.c:79: error: (Each undeclared identifier is reported onl y once arch/um/sys-i386/module.c:79: error: for each function it appears in.) arch/um/sys-i386/module.c:83: error:R_386_PC32’ undeclared (first use in this function)
    make[1] : *** [arch/um/sys-i386/module.o] Erreur 1
    make : *** [arch/um/sys-i386] Erreur 2

    Pourriez-vous me dire pourquoi je n’arrive pas à compiler un noyeau patché avec uml ?

    Un grand Merci !!

    Stefan

    repondre message

  • Posté le 6 février 2006 à 19:07, par MIB (lien)

    Un petit complément, pour aller dans le sens de la "ferme de machines virtuelles" :

    On suppose qu’on a lancé plein de machines virtuelles. Trop bien. Maintenant, comment on
    les arrête (proprement) ?

    Solution :
     on donne à chacune un nom au lancement, avec le paramètre umid=le-nom
     dans chaque machine, on bidouille le fichier /etc/inittab pour que la combinaison ctrl-alt-del
    fasse un "shutdown -h" plutôt qu’un "shudown -r".
     pour arrêter une machine, on fait : uml_mconsole le-nom cad

    et voilà !

    repondre message