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.

[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 !

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

    Répondre à ce 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

    Répondre à ce 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à !

    Répondre à ce message