Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

qui peut m'expliquer les options ethernet de VMWare ?

14 réponses
Avatar
pehache-tolai
Bonjour,

J'ai un VMWare sur un OS hôte WinXP, avec un OS guest W98.

J'ai un réseau local avec une Neuf Box qui sert de routeur/serveur DHCP
(adresses 192.168.1.x). J'arrive à faire accéder le W98 au réseau, mais
j'aimerais mieux comprendre le principe des différentes options de
connection ethernet de VMWare:

* bridged :

Si je comprends bien c'est l'option à préférer quand on a sur l'hôte une
carte ethernet physique reliée à un réseau local. L'OS guest obtient bien
dans ce cas une adresse 192.169.1.x, et est visible sur le réseau local (je
peux le pinguer depuis n'importe quelle machine, et pinguer n'importe quelle
machine depuis ce guest).

Mais qu'est-ce que fait VMWare ici ? Il transforme la carte ethernet
physique en un switch ethernet virtuel ?

Par contre impossible pour l'invité d'accéder à l'hôte par FTP dans cette
configuration: pourquoi ?

* host-only

Si je comprends bien, VMWare installe ici une carte ethernet virtuelle sur
l'hôte et créé un réseau privé 192.168.217.x indépendant du réseau local
(l'invité ne voit pas les adresses 192.168.1.x).

FTP de l'invité vers l'hôte toujours impossible, néanmoins.

* NAT

C'est la seule configuration où le FTP de l'invité vers l'hôte est possible,
pourquoi ?

Comme en host-only, VMWare installe une carte virtuelle pour créer un réseau
privé 192.168.131.x entre l'hôte et l'invité. Par contre à la différence de
host-only, l'invité voit les adresses 192.168.1.x : qu'est-ce qui change
dans l'implémentation, par rapport à host-only ?

Merci !

(X-post)

--
pehache
http://pehache.free.fr/public.html

10 réponses

1 2
Avatar
Jean-Claude BELLAMY
"pehache-tolai" a écrit dans le message de
news:
Bonjour,

J'ai un VMWare sur un OS hôte WinXP, avec un OS guest W98.

J'ai un réseau local avec une Neuf Box qui sert de routeur/serveur DHCP
(adresses 192.168.1.x). J'arrive à faire accéder le W98 au réseau, mais
j'aimerais mieux comprendre le principe des différentes options de
connection ethernet de VMWare:




Par défaut, VMWare crée 3 cartes Ethernet virtuelles :

VMnet 0 : carte virtuelle utilisée en cas de fonctionnement "bridged"
(elle se "superpose" à la carte réseau physique du PC hôte)
VMnet 1 : carte virtuelle utilisée en cas de réseau local isolé
VMnet 8 : carte virtuelle utilisée en cas de fonctionnement "NAT"
(on peut en créer d'autres si on veut)

Ensuite, on dispose de 4 modes de fonctionnement réseau, au choix, :

- non connecté
pas de réseau, la machine virtuelle est donc totalement isolée.
Ce mode peut s'avérer utile dans des circonstances très
particulières, telles que le test de l'action de certains virus.

- réseau local isolé
les machines virtuelles communiquent entre elles via un
réseau virtuel, mais ne peuvent pas communiquer avec la
machine hôte ou les autres machines réelles du réseau réel

- intégration au réseau réel
les machines virtuelles se comportent comme n'importe
quelle autre machine réelle du LAN, reçoivent p.ex. une
adresse IP d'un serveur DHCP, et sont vues depuis les
autres machines du LAN comme si elles étaient réelles.
Sous VMWare, c'est le mode standard, appelé "bridged"

- NAT (Network Addresses Translation)
De la même façon qu'un routeur connecté à Internet
va effectuer une conversion des adresses locales
(en 192.168.x.x p.ex.) pour toute requête vers Internet
émise par une machine locale, ici la machine hôte effectue
une conversion analogue des adresses locales des
machines invitées.
Donc une machine invitée pourra accéder au LAN réel ,
voire à Internet, mais ne sera pas vue du LAN réel.

NB: dans le cas "Bridged" (le plus pratique AMHA quand on est dans un LAN
réel), je désactive systématiquement sur la machine hôte les cartes Ethernet
virtuelles VMnet1 et VMnet8, car si elles sont présentes, elles bloquent
presque tout le réseau sur la machine hôte.

Suivant la métrique qui leur est attribuée, j'ai constaté qu'elles passaient
parfois en 1er, quand je faisais un parcours réseau, et je me goinfrais des
tas d'erreurs 53 sur un "NET VIEW" p.ex., et au minimum des temps de réponse
phénoménaux.
Vu qu'elles avaient des adresses IP dans des plages qui n'avaient aucun
rapport avec mon LAN en 192.168.0.x (198.168.224.1 ou 192.168.29.1), leur
requêtes tombaient systématiquement dans le vide!


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Avatar
Jean-Claude BELLAMY
"pehache-tolai" a écrit dans le message de
news:
Bonjour,

J'ai un VMWare sur un OS hôte WinXP, avec un OS guest W98.

J'ai un réseau local avec une Neuf Box qui sert de routeur/serveur DHCP
(adresses 192.168.1.x). J'arrive à faire accéder le W98 au réseau, mais
j'aimerais mieux comprendre le principe des différentes options de
connection ethernet de VMWare:




Par défaut, VMWare crée 3 cartes Ethernet virtuelles :

VMnet 0 : carte virtuelle utilisée en cas de fonctionnement "bridged"
(elle se "superpose" à la carte réseau physique du PC hôte)
VMnet 1 : carte virtuelle utilisée en cas de réseau local isolé
VMnet 8 : carte virtuelle utilisée en cas de fonctionnement "NAT"
(on peut en créer d'autres si on veut)

Ensuite, on dispose de 4 modes de fonctionnement réseau, au choix, :

- non connecté
pas de réseau, la machine virtuelle est donc totalement isolée.
Ce mode peut s'avérer utile dans des circonstances très
particulières, telles que le test de l'action de certains virus.

- réseau local isolé
les machines virtuelles communiquent entre elles via un
réseau virtuel, mais ne peuvent pas communiquer avec la
machine hôte ou les autres machines réelles du réseau réel

- intégration au réseau réel
les machines virtuelles se comportent comme n'importe
quelle autre machine réelle du LAN, reçoivent p.ex. une
adresse IP d'un serveur DHCP, et sont vues depuis les
autres machines du LAN comme si elles étaient réelles.
Sous VMWare, c'est le mode standard, appelé "bridged"

- NAT (Network Addresses Translation)
De la même façon qu'un routeur connecté à Internet
va effectuer une conversion des adresses locales
(en 192.168.x.x p.ex.) pour toute requête vers Internet
émise par une machine locale, ici la machine hôte effectue
une conversion analogue des adresses locales des
machines invitées.
Donc une machine invitée pourra accéder au LAN réel ,
voire à Internet, mais ne sera pas vue du LAN réel.

NB: dans le cas "Bridged" (le plus pratique AMHA quand on est dans un LAN
réel), je désactive systématiquement sur la machine hôte les cartes Ethernet
virtuelles VMnet1 et VMnet8, car si elles sont présentes, elles bloquent
presque tout le réseau sur la machine hôte.

Suivant la métrique qui leur est attribuée, j'ai constaté qu'elles passaient
parfois en 1er, quand je faisais un parcours réseau, et je me goinfrais des
tas d'erreurs 53 sur un "NET VIEW" p.ex., et au minimum des temps de réponse
phénoménaux.
Vu qu'elles avaient des adresses IP dans des plages qui n'avaient aucun
rapport avec mon LAN en 192.168.0.x (198.168.224.1 ou 192.168.29.1), leur
requêtes tombaient systématiquement dans le vide!


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
Avatar
Pascal Hambourg
Salut,

pehache-tolai a écrit :

J'ai un VMWare sur un OS hôte WinXP, avec un OS guest W98.

J'ai un réseau local avec une Neuf Box qui sert de routeur/serveur DHCP
(adresses 192.168.1.x). J'arrive à faire accéder le W98 au réseau, mais
j'aimerais mieux comprendre le principe des différentes options de
connection ethernet de VMWare:

* bridged :

Si je comprends bien c'est l'option à préférer quand on a sur l'hôte une
carte ethernet physique reliée à un réseau local. L'OS guest obtient bien
dans ce cas une adresse 192.169.1.x, et est visible sur le réseau local (je
peux le pinguer depuis n'importe quelle machine, et pinguer n'importe quelle
machine depuis ce guest).

Mais qu'est-ce que fait VMWare ici ? Il transforme la carte ethernet
physique en un switch ethernet virtuel ?



Oui, en quelque sorte. C'est ce qu'on appelle un pont.

Par contre impossible pour l'invité d'accéder à l'hôte par FTP dans cette
configuration: pourquoi ?



Peut-être un pare-feu ou une limitation d'accès dans le serveur FTP de
l'hôte. Les autres postes du réseau local peuvent y accéder ?

* host-only

Si je comprends bien, VMWare installe ici une carte ethernet virtuelle sur
l'hôte et créé un réseau privé 192.168.217.x indépendant du réseau local
(l'invité ne voit pas les adresses 192.168.1.x).



Oui, avec un serveur DHCP virtuel si je me souviens bien.

FTP de l'invité vers l'hôte toujours impossible, néanmoins.

* NAT

C'est la seule configuration où le FTP de l'invité vers l'hôte est possible,
pourquoi ?

Comme en host-only, VMWare installe une carte virtuelle pour créer un réseau
privé 192.168.131.x entre l'hôte et l'invité. Par contre à la différence de
host-only, l'invité voit les adresses 192.168.1.x : qu'est-ce qui change
dans l'implémentation, par rapport à host-only ?



VMware réalise un routeur NAT virtuel entre les deux interfaces. C'est
un peu comme le partage de connexion internet intégré dans Windows.
Avatar
Pascal Hambourg
Salut,

pehache-tolai a écrit :

J'ai un VMWare sur un OS hôte WinXP, avec un OS guest W98.

J'ai un réseau local avec une Neuf Box qui sert de routeur/serveur DHCP
(adresses 192.168.1.x). J'arrive à faire accéder le W98 au réseau, mais
j'aimerais mieux comprendre le principe des différentes options de
connection ethernet de VMWare:

* bridged :

Si je comprends bien c'est l'option à préférer quand on a sur l'hôte une
carte ethernet physique reliée à un réseau local. L'OS guest obtient bien
dans ce cas une adresse 192.169.1.x, et est visible sur le réseau local (je
peux le pinguer depuis n'importe quelle machine, et pinguer n'importe quelle
machine depuis ce guest).

Mais qu'est-ce que fait VMWare ici ? Il transforme la carte ethernet
physique en un switch ethernet virtuel ?



Oui, en quelque sorte. C'est ce qu'on appelle un pont.

Par contre impossible pour l'invité d'accéder à l'hôte par FTP dans cette
configuration: pourquoi ?



Peut-être un pare-feu ou une limitation d'accès dans le serveur FTP de
l'hôte. Les autres postes du réseau local peuvent y accéder ?

* host-only

Si je comprends bien, VMWare installe ici une carte ethernet virtuelle sur
l'hôte et créé un réseau privé 192.168.217.x indépendant du réseau local
(l'invité ne voit pas les adresses 192.168.1.x).



Oui, avec un serveur DHCP virtuel si je me souviens bien.

FTP de l'invité vers l'hôte toujours impossible, néanmoins.

* NAT

C'est la seule configuration où le FTP de l'invité vers l'hôte est possible,
pourquoi ?

Comme en host-only, VMWare installe une carte virtuelle pour créer un réseau
privé 192.168.131.x entre l'hôte et l'invité. Par contre à la différence de
host-only, l'invité voit les adresses 192.168.1.x : qu'est-ce qui change
dans l'implémentation, par rapport à host-only ?



VMware réalise un routeur NAT virtuel entre les deux interfaces. C'est
un peu comme le partage de connexion internet intégré dans Windows.
Avatar
pehache-tolai
"Jean-Claude BELLAMY" a écrit dans le
message de news: 4870ed5b$0$878$


Par défaut, VMWare crée 3 cartes Ethernet virtuelles :

VMnet 0 : carte virtuelle utilisée en cas de fonctionnement "bridged"
(elle se "superpose" à la carte réseau physique du PC



Comment ça, elle "se superpose" ?


Ensuite, on dispose de 4 modes de fonctionnement réseau, au choix, :
... - réseau local isolé
les machines virtuelles communiquent entre elles via un
réseau virtuel, mais ne peuvent pas communiquer avec la
machine hôte ou les autres machines réelles du réseau réel



Pourtant dans ce mode que je peux pinguer l'hôte depuis l'invité, en
utilisant l'adresse 192.169.217.1. Mais c'est bien le but, non ?

Je ne peux pas pinguer les autres machines du LAN réel, par contre, en
effet.

Mais comment se fait-il qu'en spécifiant l'hôte comme passerelle, on
n'accède pas à internet ?

- intégration au réseau réel
les machines virtuelles se comportent comme n'importe
quelle autre machine réelle du LAN, reçoivent p.ex. une
adresse IP d'un serveur DHCP, et sont vues depuis les
autres machines du LAN comme si elles étaient réelles.
Sous VMWare, c'est le mode standard, appelé "bridged"



OK.

- NAT (Network Addresses Translation)
De la même façon qu'un routeur connecté à Internet
va effectuer une conversion des adresses locales
(en 192.168.x.x p.ex.) pour toute requête vers Internet
émise par une machine locale, ici la machine hôte effectue
une conversion analogue des adresses locales des
machines invitées.
Donc une machine invitée pourra accéder au LAN réel ,
voire à Internet, mais ne sera pas vue du LAN réel.



à part par la machine hôte, quand même...



NB: dans le cas "Bridged" (le plus pratique AMHA quand on est dans un
LAN réel), je désactive systématiquement sur la machine hôte les
cartes Ethernet virtuelles VMnet1 et VMnet8, car si elles sont
présentes, elles bloquent presque tout le réseau sur la machine hôte.



C'est pas idiot, ça, en effet... Je le fais pour les cartes physiques
inactives, mais je n'y avais pas pensé pour ces cartes là.

--
pehache
http://pehache.free.fr/public.html
Avatar
pehache-tolai
"Jean-Claude BELLAMY" a écrit dans le
message de news: 4870ed5b$0$878$


Par défaut, VMWare crée 3 cartes Ethernet virtuelles :

VMnet 0 : carte virtuelle utilisée en cas de fonctionnement "bridged"
(elle se "superpose" à la carte réseau physique du PC



Comment ça, elle "se superpose" ?


Ensuite, on dispose de 4 modes de fonctionnement réseau, au choix, :
... - réseau local isolé
les machines virtuelles communiquent entre elles via un
réseau virtuel, mais ne peuvent pas communiquer avec la
machine hôte ou les autres machines réelles du réseau réel



Pourtant dans ce mode que je peux pinguer l'hôte depuis l'invité, en
utilisant l'adresse 192.169.217.1. Mais c'est bien le but, non ?

Je ne peux pas pinguer les autres machines du LAN réel, par contre, en
effet.

Mais comment se fait-il qu'en spécifiant l'hôte comme passerelle, on
n'accède pas à internet ?

- intégration au réseau réel
les machines virtuelles se comportent comme n'importe
quelle autre machine réelle du LAN, reçoivent p.ex. une
adresse IP d'un serveur DHCP, et sont vues depuis les
autres machines du LAN comme si elles étaient réelles.
Sous VMWare, c'est le mode standard, appelé "bridged"



OK.

- NAT (Network Addresses Translation)
De la même façon qu'un routeur connecté à Internet
va effectuer une conversion des adresses locales
(en 192.168.x.x p.ex.) pour toute requête vers Internet
émise par une machine locale, ici la machine hôte effectue
une conversion analogue des adresses locales des
machines invitées.
Donc une machine invitée pourra accéder au LAN réel ,
voire à Internet, mais ne sera pas vue du LAN réel.



à part par la machine hôte, quand même...



NB: dans le cas "Bridged" (le plus pratique AMHA quand on est dans un
LAN réel), je désactive systématiquement sur la machine hôte les
cartes Ethernet virtuelles VMnet1 et VMnet8, car si elles sont
présentes, elles bloquent presque tout le réseau sur la machine hôte.



C'est pas idiot, ça, en effet... Je le fais pour les cartes physiques
inactives, mais je n'y avais pas pensé pour ces cartes là.

--
pehache
http://pehache.free.fr/public.html
Avatar
pehache-tolai
"Pascal Hambourg" a écrit dans le
message de news: g4qtma$1ork$

Oui, en quelque sorte. C'est ce qu'on appelle un pont.




OK, je vois en gros.

Par contre impossible pour l'invité d'accéder à l'hôte par FTP dans
cette configuration: pourquoi ?



Peut-être un pare-feu ou une limitation d'accès dans le serveur FTP de
l'hôte. Les autres postes du réseau local peuvent y accéder ?




Gagné, c'était le pare-feu. J'ai ouvert le port 21 et maintenant ça passe.

Mai zalors, comment se fait-il qu'en NAT le FTP pouvait accéder à l'hôte
malgré le pare-feu ?


Comme en host-only, VMWare installe une carte virtuelle pour créer
un réseau privé 192.168.131.x entre l'hôte et l'invité. Par contre à
la différence de host-only, l'invité voit les adresses 192.168.1.x :
qu'est-ce qui change dans l'implémentation, par rapport à host-only ?



VMware réalise un routeur NAT virtuel entre les deux interfaces. C'est
un peu comme le partage de connexion internet intégré dans Windows.



OK. Donc par rapport à host-only, il y a en plus un routeur logiciel qui
"relie" la carte physique et la carte virtuelle sur l'hôte.

--
pehache
http://pehache.free.fr/public.html
Avatar
pehache-tolai
"Pascal Hambourg" a écrit dans le
message de news: g4qtma$1ork$

Oui, en quelque sorte. C'est ce qu'on appelle un pont.




OK, je vois en gros.

Par contre impossible pour l'invité d'accéder à l'hôte par FTP dans
cette configuration: pourquoi ?



Peut-être un pare-feu ou une limitation d'accès dans le serveur FTP de
l'hôte. Les autres postes du réseau local peuvent y accéder ?




Gagné, c'était le pare-feu. J'ai ouvert le port 21 et maintenant ça passe.

Mai zalors, comment se fait-il qu'en NAT le FTP pouvait accéder à l'hôte
malgré le pare-feu ?


Comme en host-only, VMWare installe une carte virtuelle pour créer
un réseau privé 192.168.131.x entre l'hôte et l'invité. Par contre à
la différence de host-only, l'invité voit les adresses 192.168.1.x :
qu'est-ce qui change dans l'implémentation, par rapport à host-only ?



VMware réalise un routeur NAT virtuel entre les deux interfaces. C'est
un peu comme le partage de connexion internet intégré dans Windows.



OK. Donc par rapport à host-only, il y a en plus un routeur logiciel qui
"relie" la carte physique et la carte virtuelle sur l'hôte.

--
pehache
http://pehache.free.fr/public.html
Avatar
Pascal Hambourg
pehache-tolai a écrit :

Gagné, c'était le pare-feu. J'ai ouvert le port 21 et maintenant ça passe.



Je suggère d'activer le pare-feu en dernier, après avoir vérifié la
connectivité sans pare-feu. Ainsi si ça ne passe pas avant ça ne vient
pas de lui, et si ça ne passe plus après ça vient de lui.

Mai zalors, comment se fait-il qu'en NAT le FTP pouvait accéder à l'hôte
malgré le pare-feu ?



Je crois me rappeler que le NAT de VMware est limité aux connexions TCP
et UDP, et au ping. Je soupçonne que ça fonctionne en fait plus ou moins
comme une sorte de proxy TCP/UDP/ping transparent, et que les connexions
qui viennent de l'invité apparaissent à l'hôte comme provenant de
lui-même, VMware étant un processus local. Le pare-feu devait autoriser
toutes le connexions d'origine locale.

Pour répondre à la question posée à JCB :
- réseau local isolé



Mais comment se fait-il qu'en spécifiant l'hôte comme passerelle, on
n'accède pas à internet ?



Parce que pour cela l'hôte devrait fonctionner en routeur, et
probablement aussi faire du NAT dans ton cas. Pour être un routeur, il
ne suffit pas d'avoir plusieurs interfaces réseau ; il faut aussi savoir
faire passer les paquets d'une interface à l'autre.
Avatar
Pascal Hambourg
pehache-tolai a écrit :

Gagné, c'était le pare-feu. J'ai ouvert le port 21 et maintenant ça passe.



Je suggère d'activer le pare-feu en dernier, après avoir vérifié la
connectivité sans pare-feu. Ainsi si ça ne passe pas avant ça ne vient
pas de lui, et si ça ne passe plus après ça vient de lui.

Mai zalors, comment se fait-il qu'en NAT le FTP pouvait accéder à l'hôte
malgré le pare-feu ?



Je crois me rappeler que le NAT de VMware est limité aux connexions TCP
et UDP, et au ping. Je soupçonne que ça fonctionne en fait plus ou moins
comme une sorte de proxy TCP/UDP/ping transparent, et que les connexions
qui viennent de l'invité apparaissent à l'hôte comme provenant de
lui-même, VMware étant un processus local. Le pare-feu devait autoriser
toutes le connexions d'origine locale.

Pour répondre à la question posée à JCB :
- réseau local isolé



Mais comment se fait-il qu'en spécifiant l'hôte comme passerelle, on
n'accède pas à internet ?



Parce que pour cela l'hôte devrait fonctionner en routeur, et
probablement aussi faire du NAT dans ton cas. Pour être un routeur, il
ne suffit pas d'avoir plusieurs interfaces réseau ; il faut aussi savoir
faire passer les paquets d'une interface à l'autre.
1 2