Réseau VirtualBox : configurer NAT et hôte uniquement

NAT : une sortie Internet isolée

En mode NAT, VirtualBox fait passer le trafic de la VM par la connexion réseau de l'hôte. En général, la VM arrive à consulter Internet, et VirtualBox lui fournit une configuration réseau automatiquement. Par contre, l'hôte et les autres appareils du LAN ne peuvent pas initier une connexion directe vers la VM.

Ce mode convient bien à une VM de test qui doit télécharger des mises à jour sans devenir un « vrai » hôte visible sur le réseau local. Si vous voulez accéder à un service depuis l'hôte, il faut ajouter une redirection de ports. Par exemple, pour SSH, vous pouvez rediriger le TCP 2222 de l'hôte vers le port 22 de la VM. Ça marche, mais ça implique de gérer ports et règles.

À noter : avec le NAT standard, chaque VM a en pratique son propre réseau NAT, donc elles ne communiquent pas entre elles « par défaut ». C'est une différence importante avec le réseau NAT.

Réseau NAT : plusieurs VM sur un même réseau

Le réseau NAT permet de regrouper plusieurs VM sur un réseau partagé. Elles peuvent alors se joindre entre elles, tout en sortant vers Internet via l'hôte. Comme avec le NAT standard, l'accès entrant depuis l'hôte passe souvent par une redirection de ports.

C'est utile pour tester une architecture avec plusieurs machines sans les exposer au réseau physique. Pour un petit cluster Kubernetes, par exemple, ce mode peut suffire pour que les nœuds discutent entre eux. Si vous devez administrer chaque nœud facilement depuis votre poste, ajoutez aussi un accès hôte-VM.

Adaptateur en pont : la VM rejoint le réseau local

En mode accès par pont (Bridged Adapter), la VM apparaît sur le réseau local comme un appareil à part entière. Elle peut récupérer une adresse via DHCP (du routeur ou du serveur DHCP du LAN), et être jointe par les autres machines selon les règles de filtrage.

C'est pratique pour tester un service depuis un autre poste ou vérifier un comportement « proche production ». Mais il y a un coût : la VM est réellement sur le réseau physique. Son exposition dépend notamment du pare-feu dans la VM (et des services actifs), ainsi que des contrôles réseau en place. Le pare-feu de l'hôte ne garantit pas, à lui seul, le trafic vers la VM.

Le pont peut aussi être plus capricieux en Wi-Fi, ou dans certains réseaux d'entreprise qui limitent les adresses MAC autorisées. Utilisez ce mode quand la visibilité sur le LAN est vraiment nécessaire, pas juste « pour avoir Internet ».

Hôte uniquement, réseau interne et réseau cloud

L'adaptateur hôte uniquement crée un réseau privé entre l'hôte et les VM qui y sont connectées. Par défaut, il ne donne pas Internet à la VM. L'intérêt ici est simple : administrer une VM depuis l'hôte sans la publier sur le LAN.

Le réseau interne fait un pas de plus : il relie les VM entre elles, mais ne connecte pas l'hôte. On l'utilise pour simuler un segment isolé. Dans ce cas, il faut prévoir l'adressage et éventuellement le DHCP (selon la configuration).

Enfin, un réseau cloud sert à relier VirtualBox à des ressources Oracle Cloud Infrastructure (OCI), si vous avez la configuration et les accès nécessaires. Ce scénario ne ressemble pas trop à un labo local « classique ».

Le point à ne pas oublier : la passerelle par défaut

En NAT, vous avez généralement déjà la route par défaut pour sortir. L'interface hôte uniquement sert aux échanges privés entre l'hôte et la VM. Donc, dans une configuration simple, ne mettez pas de passerelle par défaut sur la seconde interface.

Si vous ajoutez une passerelle sur les deux interfaces, la VM peut choisir le mauvais chemin pour certains paquets. Une adresse IP statique sur l'interface hôte uniquement suffit, et la route Internet doit rester sur l'interface NAT.

L'adresse choisie doit appartenir au sous-réseau de l'adaptateur hôte uniquement, sans conflit avec l'adresse de l'hôte, une autre VM, ou une plage DHCP. Attention : les plages affichées peuvent changer d'une machine à l'autre. Ne recopiez pas une adresse vue dans un tutoriel sans la vérifier.

Quand cette combinaison ne suffit pas

Si plusieurs VM doivent communiquer, mettez-les sur le même réseau NAT (si vous voulez qu'elles partagent une sortie) ou sur le même réseau hôte uniquement (si vous voulez un trafic privé entre elles). Et si des appareils du LAN doivent accéder à un service hébergé dans la VM, le mode pont peut être justifié, mais vous devez traiter ça comme une exposition réelle : pare-feu, ports, règles.

Pour un cluster de labo, vous pouvez aussi adapter le schéma : NAT pour la sortie Internet, réseau privé partagé pour le trafic entre nœuds, et hôte uniquement pour administrer. Le bon montage dépend des flux que vous cherchez à reproduire. Multiplier les interfaces « au cas où » finit par compliquer le diagnostic.

1. Créer un adaptateur hôte uniquement

Dans VirtualBox, ouvrez le gestionnaire de réseaux - souvent accessible via Outils > Réseau - puis créez un réseau hôte uniquement. Vérifiez l'adresse IPv4 de l'interface hôte et le masque. Une config fréquente utilise un sous-réseau privé en /24, mais les valeurs exactes dépendent de votre environnement.

Vous pouvez activer le serveur DHCP si vous voulez laisser VirtualBox attribuer une adresse aux VM. Si vous préférez quelque chose de stable, passez plutôt sur une adresse statique (ou une réservation DHCP). Dans tous les cas, vérifiez que la plage DHCP ne recouvre pas l'adresse que vous comptez utiliser.

2. Affecter les deux adaptateurs à la VM

Arrêtez la VM avant de toucher aux interfaces. Dans Configuration > Réseau :

1. Activez l'adaptateur 1 et choisissez NAT.
2. Activez l'adaptateur 2 et choisissez Réseau hôte uniquement.
3. Sélectionnez le réseau hôte uniquement que vous venez de créer.
4. Vérifiez que les deux interfaces sont activées, et gardez une adresse MAC distincte pour chacune.

Démarrez ensuite la VM. Dans Linux, identifiez les interfaces avec ip addr. Le nom peut être enp0s3, enp0s8 ou autre : ça dépend du système invité et de l'ordre des cartes. Ne partez pas du principe que la deuxième interface s'appellera toujours enp0s8.

3. Configurer l'interface privée avec NetworkManager

Sur une distribution qui utilise NetworkManager, vous pouvez utiliser nmtui (côté interface) ou nmcli (en ligne de commande). Avant de modifier quoi que ce soit, relevez le nom de la connexion et l'interface correspondante :

nmcli connection show
ip addr

Supposons que la connexion de la seconde carte s'appelle enp0s8 et que le réseau hôte uniquement soit 192.168.56.0/24. Choisissez une adresse libre, par exemple 192.168.56.10 (après avoir vérifié l'adresse de l'hôte et la plage DHCP).

La commande suivante fixe une adresse statique et évite de transformer cette interface en route par défaut :

sudo nmcli connection modify "enp0s8" \
ipv4.method manual \
ipv4.addresses 192.168.56.10/24 \
ipv4.never-default yes

Remplacez le nom de connexion et le sous-réseau par ceux de votre machine. Dans le cas courant, n'ajoutez pas de passerelle sur cette interface. L'interface NAT doit garder la route par défaut fournie automatiquement.

Appliquez ensuite :

sudo nmcli connection down "enp0s8"
sudo nmcli connection up "enp0s8"

Si la connexion n'existe pas encore, créez-la en ciblant le bon nom d'interface, par exemple :

sudo nmcli connection add type ethernet \
con-name reseau-prive ifname enp0s8 \
ipv4.method manual \
ipv4.addresses 192.168.56.10/24 \
ipv4.never-default yes

nmtui est une alternative : lancez-le, choisissez Modifier une connexion, sélectionnez l'interface concernée, puis renseignez l'adresse IPv4 et le préfixe. Enregistrez et redémarrez la connexion si nécessaire. Les écrans diffèrent un peu selon la distribution.

Côté interface NAT, la configuration passe généralement par DHCP. Si vous avez déjà modifié ses paramètres, assurez-vous qu'elle reste en mode automatique pour obtenir une adresse et la route par défaut. Et ne dupliquez pas les réglages statiques sur les deux cartes.

Pour les détails selon les versions installées, consultez le manuel officiel de VirtualBox et la documentation de NetworkManager.

Contrôler les adresses et les routes

Dans l'invité, lancez :

ip addr
ip route

Vous devez voir une adresse sur chaque interface. Côté NAT, il y a en général une route par défaut. Côté hôte uniquement, vous devez juste avoir l'adresse privée choisie, sans seconde route par défaut. Sur l'hôte, repérez aussi l'adresse de son interface VirtualBox : elle doit être dans le même sous-réseau privé.

Testez ensuite la communication entre la VM et l'hôte sur le réseau hôte-uniquement :

ping -c 4 192.168.56.1

Remplacez 192.168.56.1 par l'adresse réellement attribuée à l'interface VirtualBox sur l'hôte. Un échec au ping ne suffit pas à conclure : un pare-feu peut bloquer ICMP. Regardez aussi les adresses et les routes avant de paniquer.

Pour la sortie Internet depuis Linux, testez d'abord une IP puis un nom :

ping -c 4 1.1.1.1
getent hosts example.com

Si l'IP répond mais pas le nom, le souci vient probablement du DNS. Si rien ne répond vers une destination externe, vérifiez l'état de l'interface NAT et l'existence de la route par défaut.

Tester SSH depuis l'hôte

Dans la VM, vérifiez que le serveur SSH est bien installé et actif. Avec systemd, selon les distributions, ça peut donner :

sudo systemctl status sshd
sudo ss -lntp | grep ':22'

Le nom du service est parfois ssh plutôt que sshd. Si le pare-feu de l'invité est activé, autorisez SSH sur le réseau privé selon l'outil de la distribution.

Depuis l'hôte, connectez-vous à l'adresse de l'interface hôte uniquement :

ssh utilisateur@192.168.56.10

En général, vous n'avez pas besoin de redirection NAT pour accéder à la VM si le réseau hôte uniquement fonctionne déjà. La redirection devient utile si vous devez passer par le NAT standard ou si votre architecture l'exige.

Les causes fréquentes d'échec

• Mauvaise interface configurée : sous Linux, les noms ne sont pas garantis. Reconfirmez avec ip addr et nmcli connection show.
• Adresse hors sous-réseau : hôte et VM doivent être dans le même réseau hôte uniquement, avec un masque cohérent.
• Conflit d'adresses : l'adresse statique peut être déjà utilisée ou tomber dans la plage DHCP.
• Passerelle ajoutée au mauvais adaptateur : en général, gardez la route par défaut sur le NAT, pas sur hôte uniquement.
• Service SSH absent ou arrêté : le réseau peut marcher, mais si rien n'écoute sur le port 22, vous ne pourrez pas vous connecter.
• Pare-feu trop restrictif : vérifiez côté invité et, s'il y en a, les règles de sécurité applicables.
• Mauvais mode réseau : hôte uniquement ne donne pas Internet « tout seul ». Et il ne rend pas la VM automatiquement joignable depuis l'hôte si vous avez mal configuré l'adressage.

L'objectif n'est pas de « tout ouvrir » pour faire disparaître le symptôme. Isolez par couches : lien et IP, routage, DNS, pare-feu, puis service applicatif. Vous gagnerez du temps et vous éviterez une exposition inutile.