Guide des réseaux dans VMware Workstation

VMware Workstation est l’un des hyperviseurs de type 2 les plus utilisés (installé par-dessus un système d’exploitation), bien connu de toute personne ayant étudié ou enseigné en TI. Avec VirtualBox, il est devenu un classique pour les labs, les tests et l’expérimentation, et sert encore aujourd’hui de base dans la majorité des programmes collégiaux et universitaires.
C’est un excellent « simulateur » avant de passer à des environnements plus sérieux comme Proxmox (gratuit et open source) ou VMware ESXi (qui devient payant, surtout en mode production).
Mais dès qu’on touche aux réglages réseau, même les utilisateurs avancés peuvent se gratter la tête : NAT? Host-only? LAN Segment? Bridged? Qu’est-ce que ça veut dire et en quoi ça change?
Dans cet article, j’explique tout calmement et simplement. Pas de magie — juste une bonne compréhension de quand et pourquoi choisir chaque type de réseau dans VMware Workstation.
On se fait un café ou un thé — et on plonge dedans.

Matériel nécessaire

Pour la démonstration, j’utilise VMware Workstation 17 Pro sous Linux. Sur Windows, l’interface est pratiquement identique, que ce soit la version 15, 16 ou une plus récente. Si tu utilises Workstation Player, les bases restent exactement les mêmes.
VMware Workstation permet de lancer plusieurs machines virtuelles (VM) sur un seul ordinateur. Mais pour qu’elles puissent communiquer entre elles, accéder à Internet, ou au contraire, ne pas y accéder directement (mais plutôt passer par une autre VM — comme dans les exemples où Windows ou Linux agit comme routeur), il faut bien configurer leurs cartes réseau.
En ouvrant les réglages réseau dans VMware Workstation, on retrouve plusieurs options :

– NAT
– Bridged
– Host-only

 

On retrouve aussi
LAN Segment (qu’on sélectionne directement dans les paramètres de la machine virtuelle).

 

1. NAT (Network Address Translation)

Commençons par NAT — c’est sans doute le mode réseau le plus utilisé dans VMware Workstation. Dans ce mode, la machine virtuelle reçoit une adresse IP privée dans un réseau interne distinct, par exemple 192.168.208.0/24, mais accède à Internet en passant par l’hôte, via sa propre connexion.
Du point de vue de la VM, tout se passe comme si elle était connectée directement à Internet, mais en réalité, tout le trafic passe par un service NAT local, géré par l’hyperviseur sur ton poste. Ce mode est à la fois pratique et sécuritaire : on ne modifie rien sur le réseau externe, on ne dépend pas du routeur ni du DHCP de l’organisation, et on évite tout risque de « briser » quoi que ce soit dans l’infrastructure.
Autre point important : toutes les VMs connectées au réseau NAT sont accessibles depuis l’hôte. On peut donc s’y connecter en SSH, en RDP, tester des APIs localement ou ouvrir des services web dans le navigateur. Pour les labs ou les usages pédagogiques, c’est plus que suffisant.
C’est aussi la raison pour laquelle NAT est le mode par défaut — idéal quand on veut que « ça fonctionne tout de suite ».

La configuration est minimale :

– lancer la VM
– ouvrir VM → Settings → Network Adapter
– choisir « NAT: Used to share the host’s IP address »
– sauvegarder et démarrer

À ce stade, la connexion Internet dans la VM devrait déjà fonctionner.

En complément : les paramètres NAT dans le Virtual Network Editor

Dans le Virtual Network Editor, il existe une fenêtre spécifique pour NAT (« NAT Settings »), visible dans la capture d’écran. On peut y voir la sous-réseau interne, le masque, l’adresse IP de la passerelle, ainsi que des réglages comme le port forwarding ou d’autres options avancées.

Mais c’est bon à savoir : il n’est pas nécessaire de toucher à ces paramètres. Par défaut, NAT fonctionne « out of the box » sans rien changer. Ces options ne sont utiles que dans des cas particuliers — par exemple pour faire du port forwarding entre l’hôte et la VM, ou pour ajuster le sous-réseau si un conflit d’adresses survient.
Pour la majorité des labs et des usages courants, il suffit de savoir que ça existe, sans y aller trop vite.

 

2. Host-only

Host-only est un type de réseau isolé où les machines virtuelles peuvent communiquer uniquement entre elles et avec l’hôte. Elles sont totalement coupées du réseau externe, donc pas d’accès à Internet dans ce mode.
On peut voir ça comme un réseau privé virtuel interne à VMware. L’hôte dispose d’une interface virtuelle (par exemple vmnet1) qui lui permet de voir toutes les VMs connectées. Les VMs, quant à elles, peuvent se voir entre elles, mais rien ne passe en dehors de cette bulle.
Un scénario typique serait de créer un mini-lab avec un Windows Server et quelques clients, qui interagissent entre eux et avec l’hôte, mais sans aucun accès vers Internet. C’est pratique et sécuritaire, surtout pour pratiquer DHCP, Active Directory ou des scans réseau entre machines.

Dans ce genre de configuration :

– l’hôte possède une IP comme 192.168.56.1
– les VMs reçoivent leur IP via le serveur DHCP intégré : 192.168.56.101, 192.168.56.102, etc.
– la plage réseau est généralement 192.168.56.0/24 ou quelque chose de similaire

Le paramétrage est aussi simple que pour NAT :

– ouvrir VM → Settings → Network Adapter
– choisir « Host-only: A private network shared with the host »
– sauvegarder et démarrer la VM

Il n’y aura pas de connexion Internet, mais l’hôte verra les VMs — et inversement.

DHCP et Virtual Network Editor

Comme pour NAT, Host-only utilise un adaptateur virtuel et un serveur DHCP intégré. Ces paramètres sont visibles dans le Virtual Network Editor. Sur la capture d’écran, on voit par exemple que vmnet1 utilise le réseau 10.10.10.0, que le DHCP est actif, et que l’hôte est connecté via cette interface.
Si nécessaire, on peut modifier la plage IP ou désactiver le serveur DHCP. Par contre, ces changements nécessitent des droits administrateur. Sous Linux, on utilise sudo vmware-netcfg; sous Windows, il faut lancer le Virtual Network Editor en mode administrateur.
Dans la majorité des cas, ce n’est pas nécessaire. Le système fonctionne dès l’installation, et si la configuration par défaut te convient, il n’y a rien à changer.

 

3. LAN Segment

Un LAN Segment est un réseau totalement isolé, qui n’existe qu’à l’intérieur de VMware Workstation. Dans ce type de réseau, les machines virtuelles peuvent uniquement communiquer entre elles. Elles n’ont aucun accès à l’hôte, à Internet, ni même à un serveur DHCP intégré.

Contrairement aux modes NAT ou Host-only, aucun adaptateur virtuel n’est créé sur l’hôte, et le système d’exploitation ne participe pas du tout. C’est un réseau interne pur, géré exclusivement par VMware.

L’utilisation est simple à comprendre : on veut simuler un sous-réseau qu’on doit construire à la main. Par exemple, faire en sorte qu’une VM agisse comme serveur DHCP, pendant que les autres seront des clients. Ou encore, tester les interactions entre un Windows Server et plusieurs stations de travail sans risquer d’impacter le vrai réseau.
Ce mode est souvent utilisé dans les cégeps et les centres de formation, justement parce qu’on n’a pas besoin des droits administrateur pour créer de nouveaux LAN Segments. C’est un gros avantage dans les environnements partagés ou verrouillés, où les étudiants travaillent sur des postes contrôlés.

Le choix se fait directement dans les paramètres de la VM. On sélectionne le type de réseau LAN Segment, puis on clique sur LAN Segments… pour créer ou sélectionner un segment existant.
Sur la capture d’écran, on voit plusieurs segments créés : LAN 1, LAN WIN, LAN 2. Toutes les VMs connectées à un même segment se retrouveront dans un réseau fermé commun.

Comme il n’y a aucun serveur DHCP, deux solutions :

– configurer un serveur DHCP manuellement dans une des VMs
– attribuer des adresses IP statiquement

LAN Segment, c’est la liberté totale, mais aussi toute la responsabilité. Il faut tout faire soi-même, mais en échange on obtient un environnement parfaitement isolé, très proche d’un vrai réseau physique sans aucune interférence externe.

 

4. Bridged

Le mode Bridged est le seul type de réseau dans VMware Workstation où la machine virtuelle se connecte directement au réseau physique, sans passer par l’hôte. Du point de vue du routeur ou du switch, la VM apparaît comme un ordinateur distinct, avec sa propre adresse MAC, recevant une IP via DHCP, et participant pleinement au réseau.
Si l’hôte est connecté par câble (Ethernet), tout fonctionne de façon transparente. La VM obtient une adresse IP dans la même plage que l’hôte, par exemple 192.168.0.x, et devient visible par les autres appareils sur le réseau. Si on lance un serveur web, Samba ou tout autre service, il pourra être accessible depuis un téléphone, un portable ou un autre poste du réseau.

Ce mode est idéal pour simuler un hôte réel dans le réseau, tester des applications réseau, ou encore pour monter des labs avec des serveurs DHCP ou des environnements accessibles de l’extérieur.
Mais si l’hôte est connecté en Wi‑Fi, il peut y avoir des problèmes. Certains pilotes ou cartes réseau ne permettent pas de transmettre correctement le trafic aux interfaces virtuelles. Dans ces cas, on peut essayer de sélectionner manuellement un autre adaptateur physique, ou repasser temporairement en NAT.
Sur la capture d’écran, le mode Bridged est sélectionné, avec en plus l’option Replicate physical network connection state activée.
Cette option permet à la VM de refléter l’état de la connexion physique de l’hôte. Si le câble est débranché ou que la connexion Wi‑Fi est perdue, l’adaptateur de la VM sera lui aussi désactivé, ce qui peut être utile pour reproduire un comportement réaliste ou tester des scripts qui réagissent aux coupures réseau.

 

Cette case signifie que l’adaptateur virtuel va suivre l’état de la connexion physique. Si l’adaptateur de l’hôte se désactive (par exemple en cas de perte de réseau, câble débranché ou Wi‑Fi déconnecté), VMware désactivera aussi l’interface réseau de la VM. C’est utile pour reproduire un comportement réaliste ou si on souhaite que des scripts dans la VM réagissent à une coupure réseau.
Si l’option est décochée, l’adaptateur de la VM restera toujours actif, même si l’hôte n’a plus de connexion — ce qui peut parfois être plus pratique dans un environnement de lab.
Le mode Bridged ne demande aucun paramétrage avancé. On le sélectionne simplement dans les paramètres réseau de la VM, on démarre la machine, et le reste dépend du serveur DHCP du réseau physique.

Nous avons donc découvert les principaux types de réseau dans VMware Workstation : NAT, Host-only, LAN Segment et Bridged. Chacun a ses particularités et s’adapte à des scénarios différents, que ce soit pour un simple accès Internet ou pour un environnement totalement isolé.
Comprendre ces modes permet de mieux structurer son labo virtuel — et d’éviter bien des surprises lors de la configuration.

Bonne chance !

👤

📁