È possibile - almeno, nel caso comune, in cui la rete in stile NAT è configurata per il guest. Poiché VMWare fornisce il NAT-ing, dovrebbe essere in grado di dirci, per quali indirizzi è attualmente NAT-ing. Qualcosa del genere vmrun listdovrebbe fornire queste informazioni. Che non lo sia è un difetto ...
Ma, in ogni caso, ecco come si può scoprire comunque. Innanzitutto, esegui ifconfigsul tuo Mac (forse, ipconfigfarebbe lo stesso su Windows, ma non l'ho provato). Questo elencherà tutte le interfacce di rete sulla macchina, sia fisiche che virtuali. Cerca quelli vmnet. Sul mio Mac questo produce:
% 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
Quindi, l'IP del mio ospite è su una di queste due reti private VM: 192.168.82.0/24 o 192.168.123.0/24. Sul tuo host potrebbe essercene solo uno, per fortuna, o più di due: dobbiamo controllarli tutti. Ecco uno script tcsh molto semplice, inserito direttamente dalla riga di comando, che l'ha fatto per me. Tenta di eseguire il ping di ciascun indirizzo in tutte le reti private di classe C gestite da vmnet e termina quando un ping ha esito positivo. L' -W 500opzione dice a ping di attendere solo mezzo secondo per una risposta (potrebbe, probabilmente, usare anche meno) e gli -c 1dice di inviare esattamente un pacchetto:
% 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
Il piccolo script sopra è stato eseguito per qualche tempo elencando tutti i tentativi falliti di raggiungere gli indirizzi inesistenti:
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
...
Fino a quando finalmente è riuscito e finito:
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à, sono stato in grado di entrare nel mio ospite:
% ssh 192.168.123.130
Password:
Ora avevo un solo guest in esecuzione, quindi il primo indirizzo IP per rispondere a un ping era quello giusto. Se si eseguono più guest contemporaneamente, potrebbe essere necessario utilizzare lo stesso comando ping o simile per creare un elenco di tutti questi indirizzi IP privati validi e quindi provarli tutti fino a quando non si arriva al guest corretto ...
(E, forse, .130 è comunque una buona ipotesi per gli indirizzi basati su NAT. Ma non posso dirlo con certezza.)