Le blog de Sébastien Chevallier

Autrefois réservée à un public averti (voire un peu geek), l’utilisation des machines virtuelles s’est énormément démocratisée au cours de ces dernières années. Si vous n’êtes pas familier avec le monde de la virtualisation, je vous invite à consulter ce livre blanc édité par la société Smile. De la plateforme de démonstration à celle de crash-test en passant par les environnements de développement, les fameuses VM (Virtual Machines) font désormais partie de notre quotidien.

Personnellement j’utilise l’application VirtualBox, qui répond parfaitement à mes attentes, ne serait-ce que parce qu’elle est disponible gratuitement pour les 3 plateformes Mac OS X, Linux et Windows. Elle possède cependant quelques lacunes, notamment dans la prise en charge des communications réseau de l’OS hôte vers l’OS invité, qui fait l’objet de ce billet. Les manipulations sont effectuées avec une machine invitée Ubuntu et un hôte Mac OS X, mais s’adaptent (presque) sans problème à des configurations différentes.

Les différents modes d’accès réseau

Comme la plupart des logiciels de virtualisation, VirtualBox propose quatre modes d’accès réseau pour ses machines invitées :

• NAT : le plus courant, il permet à l’OS invité d’accéder au réseau externe de façon transparente. Techniquement, les connexions initiées par la machine guest sont relayées par l’interface réseau de la machine hôte, qui possède une addresse IP sur le réseau externe, selon le principe du NAT (Network Address Translation).
• Accès par pont (bridge) : la carte réseau de l’OS invité possède sa propre addresse IP sur le réseau externe.
• Réseau interne (internal network) : utilisé pour créer un sous-réseau de plusieurs machines virtuelles.
• Accès privé hôte (host-only) : les seules connexions possibles sont celles établies entre la machine hôte et la machine invitée.

Focus sur le mode NAT

Il est souvent nécessaire de pouvoir accéder à Internet depuis la machine invitée, ce qui exclue les deux derniers modes. Le réglage par défaut de la carte réseau étant positionné sur NAT, mettons nous dans la peau de l’utilisateur lambda. Une fois la machine invitée démarrée, on se connecte sur notre site préféré et… ça fonctionne !

Maintenant, supposons que notre utilisateur, qui n’est pas si lambda que ça, dispose d’un serveur Web sur sa machine virtuelle. Comme faire pour s’y connecter avec un navigateur installé sur la machine hôte ? Un ifconfig nous indique que l’adresse IP de la machine virtuelle est 10.0.2.15, mais cette fois-ci la connexion échoue. Hé oui, nous voilà face à un comportement assez pénible de VirtualBox : le NAT ne fonctionne que dans un sens (contrairement aux solutions VMware) ! Le contournement le plus simple consiste à passer en mode bridge car la machine virtuelle possèdera alors sa propre IP sur le réseau, et sera donc considérée comme un client à part entière, au même titre que son hôte. Notons quand même, pour les plus étourdis, que TOUT le traffic réseau passe par la carte physique de la machine hôte, le mode bridge consistant simplement en un dédoublement logiciel de celle-ci (un alias de l’interface réseau en quelque sorte).

Si cette solution répond tout à fait au besoin, elle possède un inconvénient de taille : la machine hôte doit être connectée à un réseau IP. Impossible donc de travailler dans le train, ou tout autre environnement déconnecté. Heureusement pour nous il existe encore deux solutions !

NB : Avant de continuer, un petit point sur l’addressage IP utilisé par le mode NAT s’impose. Toutes les machines configurées pour l’utiliser se voient attribuer l’adresse 10.0.2.15, et peuvent communiquer avec la machine hôte addressée en 10.0.2.2. On se rend compte ici que chacune d’elles est isolée et ne peut donc pas communiquer directement avec ses voisines, à moins de configurer une deuxième interface réseau uilisant le mode internal-network.

L’utilitaire VBoxManage

Si vous utilisez régulièrement VirtualBox vous avez forcémment rencontré cette commande, véritable couteau-suisse de l’application. Le « déblocage » de l’accès au port 80 (http) de la machine invitée depuis la machine hôte s’effectue à l’aide de trois lignes de commande du type :

vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/Protocol" TCP
vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/GuestPort" 80
vboxmanage setextradata "{nom de machine virtuelle}" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/{nom du mapping}/HostPort" 8080

Je ne vais pas plus loin dans les explications car je n’aime vraiment cette façon de procéder, pour les raisons suivantes :

• La commande est trop difficile à mémoriser et donc peu propice à des interventions d’urgence ;
• En fonction du paramétrage de la carte réseau de la VM, le type de driver passe de pcnet à e1000 ;
• lors de mes tests elle ne fonctionnait plus à partir de 3 ports ouverts (ce qui n’a peut être rien à voir, je n’ai pas investigué davantage).

Si vous souhaitez tout de même utiliser cette commande, toute la documentation nécessaire est disponible sur Internet. De mon côté j’ai opté pour une autre solution, un peu plus geek par contre.

Le retour du tunnel SSH

Ayant prévu de faire un billet dédié au tunneling SSH, je passe directement à la phase pratique. Pour reprendre l’exemple abordé précédemment, voici la procédure de connexion au port 80 de la VM :

1. Sur la VM, on tape la commande suivante en console

   ssh -NfR 8080:localhost:80 username@10.0.2.2

   avec username un compte existant sur la machine hôte. Notez que si cet utilisateur ne dispose pas des privilèges d’administrateur, le premier port indiqué dans la commande doit être >1024.

2. Puis on se connecte, depuis la machine hôte, à l’adresse http://localhost:8080 à l’aide d’un navigateur web :
   

Et… c’est tout ! Vous admettrez que c’est quand même plus simple :) Mais comme rien n’est jamais parfait :

• La méthode présentée ne fonctionne que pour le protocole TCP. Même si cela comprend la grande majorité des cas d’utilisation, cela peut s’évérer insuffisant et il est préférable dans ce cas d’employer la commande VboxManage. Sachez tout de même qu’il existe un contournement pour faire transiter des paquets UDP au travers d’un tunnel SSH, mais il ne sera pas abordé ici. Je n’ai fait aucun test pour ICMP car il semble être mal implémenté au niveau des drivers de VirtualBox, mais suis preneur de toute information intéressante.
• La machine hôte doit disposer d’un serveur SSH. Si cela ne pose pas de problème sur Linux et Mac OS X (Préférences Système > Partage > Session à distance) , les Windowsiens devront s’amuser un peu avec Cygwin.