Il est possible - au moins, dans le cas courant, où un réseau de style NAT est configuré pour l'invité. Étant donné que VMWare fournit le NAT-ing, il devrait être en mesure de nous dire à quelles adresses il est actuellement NAT-ing. Quelque chose comme vmrun list
devrait produire ces informations. Ce n'est pas le cas ...
Mais, en tout cas, voici comment on peut le découvrir de toute façon. Tout d'abord, exécutez ifconfig
sur votre Mac (peut-être, ipconfig
ferait la même chose sur Windows, mais je ne l'ai pas testé). Cela répertoriera toutes les interfaces réseau sur la machine - à la fois physiques et virtuelles. Recherchez les vmnet-ones. Sur mon Mac, cela produit:
% ifconfig | grep -A2 ^vmnet
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:01
inet 192.168.82.1 netmask 0xffffff00 broadcast 192.168.82.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:08
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255
Ainsi, l'adresse IP de mon invité se trouve sur l'un de ces deux réseaux privés de machine virtuelle: 192.168.82.0/24 ou 192.168.123.0/24. Sur votre hôte, il peut y en avoir un seul, vous avez de la chance, ou plus de deux - nous devons tous les vérifier. Voici un script tcsh très simple, entré directement en ligne de commande, qui l'a fait pour moi. Il tente d'envoyer une requête ping à chaque adresse dans tous les réseaux privés de classe C gérés par vmnet et se termine, lorsqu'un ping réussit. L' -W 500
option indique à ping d'attendre seulement une demi-seconde pour une réponse (pourrait, probablement, utiliser encore moins), et lui -c 1
dit d'envoyer exactement un paquet:
% set i=2
% while ( $i < 255 )
while? ping -W 500 -c 1 192.168.82.$i && break
while? ping -W 500 -c 1 192.168.123.$i && break
while? @ i++
while? end
Le petit script ci-dessus a fonctionné pendant un certain temps répertoriant toutes les tentatives infructueuses pour atteindre les adresses inexistantes:
PING 192.168.82.2 (192.168.82.2): 56 data bytes
--- 192.168.82.2 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
PING 192.168.123.2 (192.168.123.2): 56 data bytes
...
Jusqu'à ce qu'il réussisse et se termine finalement:
64 bytes from 192.168.123.130: icmp_seq=0 ttl=64 time=0.307 ms
--- 192.168.123.130 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
Voilà, j'ai pu me connecter à mon invité:
% ssh 192.168.123.130
Password:
Maintenant, je n'avais qu'un seul invité en cours d'exécution - donc la première adresse IP à répondre à un ping était la bonne. Si vous exécutez plusieurs invités à la fois, vous devrez peut-être utiliser la même commande ping ou une commande similaire pour créer une liste de toutes ces adresses IP privées valides, puis les essayer toutes jusqu'à ce que vous obteniez le bon invité ...
(Et, peut-être, .130 est une bonne supposition pour les adresses basées sur NAT de toute façon. Mais je ne peux pas dire avec certitude.)