1. Introduction

Cet article a pour but d'expliquer les principes et implications de la gestion réseau dans une machine virtuelle.

Pour aborder cet article, la connaissance du fonctionnement d'une VM et des notions de base sur le réseau sont nécessaires.

1-1. Abréviations utilisées 

Voici les abréviations qui vont être utilisées tout au long de cet article :

  • VM : Machine virtuelle (traduction de Virtual Machine) ;
  • NAT : Network Address Translation ;
  • Hôte/host : machine qui héberge les VMs ;
  • VLAN Virtual Local Area Network : réseau local virtuel.

1-2. Liens d'informations complémentaires

2. Les différents modes de fonctionnement réseau 

La ou les cartes réseau paramétrées dans une VM sont reliées au matériel par le biais de pilotes installés dans le système hôte par le logiciel de virtualisation. Au niveau de l'hôte, de nouvelles cartes réseau apparaîtront utilisées comme liens entre la ou les cartes réseau physiques et les cartes virtuelles vues dans les VMs. Elles ont leurs propres adresses MAC* et adresses IP** au niveau des VMs.

Les différents modes de fonctionnement réseau disponibles sont :

  • le mode pont ou bridge ;
  • le mode NAT ;
  • le mode HostOnly ;
  • le mode réseau privé.

Sous Windows, des cartes réseaux virtuelles vont être créées pour chaque type de connexion.

Exemples :

  • VMWare Network Adapter Vmnet1 ;
  • VirtualBox Host-Only Network.

Sous Linux, si il y a création d'interfaces virtuelles, celles-ci seront présentes dans le fichier /etc/network/interfaces.

*http://fr.wikipedia.org/wiki/Adresse_MAC

**http://fr.wikipedia.org/wiki/Adresse_IP

2-1. Le mode pont ou bridge

Dans ce mode, la carte réseau virtuelle est « pontée » à une carte réseau physique de l'hôte. Cette carte réseau aura donc 2 adresses IP, une dédiée à l'hôte et l'autre dédiée à la machine virtuelle. Avec ce mode, le DHCP du réseau fournit une adresse IP à la VM de la même façon que pour l'hôte. La VM communiquera avec les autres machines du réseau de la même façon qu'une machine réelle, aussi bien avec l'hôte qu'avec les autres machines du réseau. Il n'est pas obligatoire d'utiliser le DHCP, la carte réseau de l'hôte et/ou de la machine virtuelle peuvent être en IP fixe ou en DHCP. Comme pour une machine physique, en cas de non présence de DHCP, il faudra renseigner manuellement les paramètres réseau. Dans les exemples ci-dessous, nous supposerons l'accès à un serveur DHCP notamment fourni par une BOX Internet.

2-1-1. Exemple :

  • adresse IP de l'hôte : 192.168.1.13 (obtenu par DHCP d'une BOX) ;
  • adresse IP dans la machine virtuelle : 192.168.1.14 (obtenu par le DHCP de la même BOX) ;
  • adresse IP Box internet : 192.168.1.1

Les machines sont sur le même réseau avec chacune leur adresse IP, que la machine soit une machine physique ou une VM.

Vision sur le réseau :

Image non disponible
Image Bridge

Ce schéma pourrait également être présenté de cette façon :

Image non disponible
Image Bridge 2

Dans le cas d'une communication entre l'hôte et la VM au niveau IP, la stack IP du système d'exploitation enverra les paquets à la bonne destination : l'hôte ou la VM, de la même façon que pour l'accès entre 2 cartes réseau sur la même machine.

2-2. Le mode NAT

C'est le mode par défaut (du moins sur VirtualBox et VMWare).

En mode NAT, la VM va utiliser la translation d'adresse, la machine hôte servant de passerelle et effectuant la translation d'adresse.

La machine hôte effectue une translation d'adresse avant d'envoyer les paquets de la VM vers le réseau. Elle met son adresse IP en source du paquet et tient à jour une table de translation. Une fois la réponse reçue, la machine hôte sait que le paquet est à destination de la VM et met celui-ci à jour en conséquence avant de le transmettre à la VM.

Pour de plus amples informations sur le NAT :

Page Wikipedia sur le NAT

tutoriel de Lattite sur le NAT

2-2-1. Exemple

  • Adresse IP dans la VM obtenu de l'hôte : 10.0.2.15 (par DHCP du logiciel de virtualisation) ;
  • passerelle par défaut dans la VM obtenu par l'hôte : 10.0.2.2

Dans l'exemple ci-dessous, l'hôte aura pour adresse IP 192.168.1.14 et non plus 192.168.1.13 (celui-ci étant en DHCP, son adresse n'est pas fixe).

L'hôte, la VM, et d'autres postes pourront communiquer entre eux de la même façon que plusieurs machines derrière une BOX pourront se connecter à Internet, c'est l'IP de la BOX qui est vue sur internet.

Un autre poste que l'hôte ne pourra pas accéder à la VM. La carte réseau virtuelle de l'hôte ne comporte pas de passerelle vers les autres ordinateurs, uniquement une passerelle entre lui et ses VMs. Si plusieurs machines doivent communiquer avec la VM, il faut utiliser le mode pont (ou modifier les réglages réseau, ce qui implique une certaine maîtrise et sort du cadre de la configuration par défaut). Un ping de l'hôte (192.168.1.14) vers l'adresse IP de la VM 10.0.2.15 ne fonctionne pas.

Dans la VM, un ping sur 10.0.2.2 répond, un ping sur 192.168.1.14 aussi, ces deux adresses correspondent aux 2 cartes réseau de l'hôte, l'une réelle et l'autre virtuelle créée par VirtualBox.

Un ping de la VM vers 192.168.1.1 répond, l'hôte fait bien passerelle.

Un ping de la VM vers 192.168.1.16, une autre machine du réseau fonctionne (pas de Firewall sur le poste), toujours grâce à la passerelle et son NAT.

Ceci est également valable pour VMWare, le principe étant le même. Les adresses IP par défaut seront différentes de 10.0.0.x dans VMWare.

L'accès à Internet se fera de l'adresse 10.0.2.15 vers la passerelle 10.0.2.2, NAT entre l'adresse 10.0.2.2 et 192.168.1.14, puis passerelle du réseau 192.168.1.1

Image non disponible
Image NAT

2-3. Le mode Host Only

Il y a un réseau fermé entre la VM et la machine hôte. La VM ne peut pas communiquer avec une autre machine que l'hôte et aucune autre machine que l'hôte ne peut entrer en communication avec elle.

2-4. Le mode réseau privé

Ce mode permet à plusieurs VM d'être dans un réseau isolé, comme un VLAN. Les VMs doivent être sur le même hôte pour se voir. Le « VLAN » est sur la machine hôte.

Pour plus d'informations sur les VLANs :

3. Interconnexion de plusieurs postes 

C'est le choix du mode de réseau qui détermine la possibilité de communication entre plusieurs machines, réelles ou virtuelles. Le mode pont est plutôt adapté pour la communication VMs postes standards, le mode NAT étant plutôt pour séparer les VMs des autres postes du réseau, et le mode host-only étant plutôt pour une communication restreinte entre l'hôte et la VM.

Récapitulatif des possibilités selon le mode choisi :

Type de connexion

Pont/Bridge

NAT

Host Only

Réseau privé

VM vers hôte

OUI

OUI

OUI

OUI

VM vers LAN

OUI

NON

NON

NON

VM vers Internet

OUI

OUI

NON

NON

VM vers autre VM sur même hôte

OUI si les 2 en mode pont/bridge

OUI

NON

OUI si même réglage

VM vers autre VM sur autre machine

OUI si les 2 en mode pont/bridge

NON

NON

NON

VM vers autre machine du réseau

OUI

NON

NON

NON

4. Configuration du réseau dans une machine virtuelle

4-1. Les principaux acteurs du marché

Les principaux acteurs du marché sont :

  • les produits VMWare ;
  • Microsoft Hyper-V ;
  • Oracle VirtualBox.

Pour ces produits, des versions sont disponibles pour Windows, Linux, Mac OS X.

VMWare et Hyper-V ont des fonctionnalités évoluées d'administration de VM, contrairement à VirtualBox. Pour VMWare, toutes les fonctionnalités avancées ne sont pas présentes sur les produits gratuits.

4-1-1. Configuration réseau sous VirtualBox

Dans cet exemple, le réseau est paramétré en NAT. Dans les réglages avancés, on peut voir l'adresse MAC de la carte réseau virtuelle. Le type de carte correspond au type de carte réseau émulé. La VM verra une carte réseau PC-net Fast III, on aurait pu prendre aussi une carte Intel Pro-1000 MT. Cela n'a d'importance qu'au niveau driver dans la VM. Si les additions invitées sont installées, on n'aura pas à s'en préoccuper, les additions invitées installant les bons pilotes dans la VM.

La carte peut être vue branchée ou débranchée.

VirtualBox propose 4 cartes réseau, seule la 1ère carte réseau étant activée par défaut. Il suffit de cocher la croix « Activer la carte réseau » pour activer les autres au besoin.

Image non disponible
image VirtualBox

4-1-2. Configuration du réseau sous VMWare Player 

Dans cet exemple, on peut voir que les réglages sont similaires à VirtualBox. VMWare intègre une notion de segments réseau. Les VMs seront placées dans différents segments, qui pourront se voir entre eux ou non, si l'on souhaite utiliser cette fonctionnalité.

Il est à noter que d'autres produits VMWare payants gèrent la notion de segment de façon plus poussée et permettent de créer des switchs virtuels avec VLANs. Plusieurs cartes réseaux peuvent aussi être regroupées et être vues comme une seule carte réseau logique ayant la bande passante cumulée des différentes cartes réseau. Exemple : 2 cartes réseaux de 1 Gbit vont être vues comme une carte de 2Gbits, et en cas de panne d'une des deux cartes, le réseau restera opérationnel via la carte restant active. Cela s'appelle de l'agrégation de liens.

Sous VMWare Player, il n'est pas possible de configurer les VMnets, on ne peut qu'utiliser le mode bridge, ou le VMnet 8 : le NAT. Pour configurer les VMnets, il faut utiliser les produits payants. Sous VMWare Workstation, il y a un utilitaire en ligne de commande nommé vmnetcfg permettant le paramétrage des VMnets.

Image non disponible
img_vmware

4-1-3. Hyper-V

Hyper-V est la solution de virtualisation de Microsoft, celle-ci s'intégrant dans la console d'administration. Il est nécessaire d'être en serveur pour utiliser cela (Windows 2008 ou Windows 2012). Le rôle Hyper-V gère les services de virtualisation. Pour la gestion du réseau, le rôle Hyper-V utilise des Virtuals Switches. Ce fonctionnement est similaire à la gestion réseau avancée dans les produits VMWare payants.

Les options proposées dans les Virtuals Switches sont :

  • external network ;
  • internal network ;
  • private network.

Un « external network » est un switch virtuel relié à une carte réseau physique de l'hôte. Cela est équivalent au mode pont.

Un « internal network » correspond, comme le nom l'indique, à un réseau virtuel réservé aux VMs en faisant partie : le mode réseau privé. Il n'est pas nécessaire d'avoir de carte réseau pour ce mode.

Dans le mode « private network », le fonctionnement est identique au mode « internal network », mais l'hôte n'est pas accessible en réseau aux VMs.

La case à cocher VLAN Id permet une gestion avancée en plaçant les VMs dans des VLANs prédéfinis. Cela concerne la gestion avancée de réseau et nécessite la maîtrise des VLANs (cf, lien sur les VLANs).

Pour avoir accès à Internet, il faut ponter une carte réseau y accédant avec la carte réseau virtuelle créée par Hyper-V dans le panneau de configuration.

Pour utiliser le NAT, le rôle « Network Policy and Access Service » devra être installé. Il est plus difficile à mettre en service qu'avec WMWare ou VirtualBox.

Une partie de la gestion réseau est assurée au niveau de Windows même, contrairement aux autres solutions. Le service Hyper-V étant conçu pour s'intégrer à Active Directory, il est possible d'administrer les VMs via la console d'administration de la même façon que de créer des utilisateurs, gérer les partages, etc. Si les services Hyper-V sont installés sur un autre poste que le serveur, celui-ci peut administrer la VM hébergée sur le serveur, à condition que le compte utilisateur employé en ait les droits.

 
Image non disponible
Image Hyper-V

4-2. Des produits moins répandus

Je présente dans cette partie des produits moins répandus, mais qui fonctionnent de la même façon que les produits précités.

Les produits présentés sont :

  • Xen ;
  • Qemu ;
  • Parallels Desktop ;
  • VirtualPC.

4-2-1. Xen

Par défaut, une VM sous Xen est en mode Bridge. Le démarrage d'une VM Xen, appelée domaine (Dom0 étant l'hyperviseur, les DomUs les machines virtuelles) dans le jargon Xen, se fait par le biais d'un script shell contenant la configuration du DomU. Ce dernier comprend un sous-script pour le paramétrage du réseau. Les scripts fournis par Xen permettent la création, la modification et la supervision des VMs.

C'est le démon Xend qui est en charge des services Xen.

Xen utilise les outils Linux tels que bridge-utils (pour la création de ponts) et iptables (pour le filtrage, la redirection de ports et le NAT) pour gérer l'interface réseau. Les sous-scripts réseau règlent les interfaces présentes dans /etc/network/interfaces et les tables iptables en conséquence.

Le sous-script network-bridge démarre la VM en mode ponté, le sous-script network-nat en mode NAT, le sous-script network-route en mode routed, ce dernier mode paramétrant le dom0 comme routeur pour les VMs.

Documentation sur iptables.

4-2-2. Le cas Qemu

Qemu est un logiciel de virtualisation/émulation en ligne de commande. Il est disponible sous Windows et Linux. Il existe des Front-end (exemple : Qemu manager sous Windows, AQemu sous Linux) permettant de configurer plus simplement les VMs. Pour les processeurs x86, il utilise la virtualisation via KVM /Xen sous Linux. Pour les autres processeurs , il y a émulation,

KVM et Xen ne sont disponibles que sous Linux ( KVM=Kernel-based Virtual Machine ).

Qemu est un système hybride entre l'émulation et la virtualisation.

Image non disponible
Image QEmu

Dans la version Windows de Qemu, il y a 2 options :

  • le mode User Networking ;
  • le mode TAP networking.

Le mode « User Networking » correspond au mode NAT.

Le mode « TAP Networking » permet des réglages différents mais nécessite un pilote TUN/TAP. Qemu Manager renvoie un lien vers OpenVpn qui contient un pilote TAP.

Il est possible de paramétrer des redirections de ports soit depuis les réglages du front-end, soit en passant des paramètres dans la ligne de commande de Qemu.

Image non disponible
Image QEmu Linux

Dans cet écran sous Linux, on voit qu'il y a plus d'options que sous la version Windows. Les options supplémentaires concernent essentiellement les interfaces TUN/TAP. Il y a également une option « no connection ».

Plus d'infos sur les interfaces TUN/TAP.

Pour résumer, TAP travaille au niveau 2 de la couche OSI et se comporte comme un pont, tandis que TUN travaille au niveau 3 et sert au routage.

Exemple de ligne de commande démarrant une émulation Qemu :

 
Sélectionnez
Qemu.exe" -L "C:\Program Files (x86)\QemuManager\qemu" -M "pc"\
-m 256 -cpu "qemu32" -vga cirrus -serial vc -parallel vc -name "test"\
-drive "file=TinyCore-current.iso,index=2,media=cdrom"\
-boot order=dc,menu=off -soundhw es1370 -enable-kqemu -net\
nic,vlan=0,macaddr=52-54-00-70-97-09,model=e1000 -net user,vlan=0 -hwnd\
2426052 -monitor telnet:127.0.0.1:60001,server,nowait -localtime

Cette option correspond à la commande lancée par le front-end Windows Qemu Manager que j'ai utilisée.

La partie pertinente pour le réseau correspond aux informations derrière l'argument -net.

Dans cet exemple, on voit que le mode sélectionné est le mode user, que le modèle de carte émulée est e1000, qu'une adresse MAC est donnée.

L'option -monitor sert au contrôle de la VM. Dans notre cas, celui-ci est lancé sur le port réseau 60001.

4-2-3. Parallels Desktop

Parallels Desktop est un logiciel de virtualisation de la société Parallels, permettant la virtualisation sur Mac OS X uniquement. Il fonctionne sur le même principe que VirtualBox ou VMWare, eux aussi disponibles sur Mac OS X. Pour la gestion réseau, il comporte le mode pont, le mode hôte uniquement, et le mode réseau partagé correspondant au mode NAT.

4-2-4. VirtualPC

VirtualPC était un produit développé par la société Connectix, racheté par Microsoft en 2003.

VirtualPC était plus un émulateur. La version Macintosh de l'époque permettait de faire fonctionner Windows XP. Les macs de l'époque étaient équipés de processeurs PowerPC.

VirtualPC a servi de base pour le développement d'hyper-V, c'est à ce titre que ce paragraphe lui est dédié. La dernière version disponible fut la version 2007. Il a également servi au développement du « XP MODE » dans Windows 7 Intégrale. D'ailleurs, les programmes installés dans cet XP peuvent être démarrés depuis Windows 7 à partir du menu démarrer « Windows Virtual PC ».

http://fr.wikipedia.org/wiki/VirtualPC

5. Pour aller plus loin 

6. Conclusion

En conclusion, je dirais que j'utilise le mode NAT plutôt pour effectuer des tests et le mode bridge pour des VMs en production.

Les modes host-only ou réseau privé ne me servent pas. Pour communiquer entre l'hôte et une VM, soit j'utilise le réseau, que ce soit en bridge ou en NAT, soit le glisser-déplacer pour copier des fichiers par exemple.

Le mode réseau privé peut permettre de tester une communication multi-VMs sans avoir accès à Internet, ce qui est également possible en personnalisant les réglages réseau dans les VMs et en ne donnant pas de passerelle. Dans ce cas, il faudra modifier les réglages réseau dans les différentes VMs.

Dans le cas d'une seule VM, plutôt que d'utiliser le mode host-only, j'utilise le mode NAT, avec câble débranché, ce qui me permet d'avoir accès à Internet sur la VM en un clic si besoin sans changer de configuration ni redémarrer la VM.

Votre avis et vos suggestions sur cet article m'intéressent ! Alors, après votre lecture, n'hésitez pas ! 2 commentaires Donner une note à l'article (5)

6-1. Remerciements 

Je tiens particulièrement à remercier Viduc, Jipété, LittleWhite, et ram-0000 pour leur relecture et leurs conseils.

Merci à Ced pour la relecture orthographique.