J'utilise VM Player 4.0.2 sous OS OS invité Ubuntu 11.10 sur un hôte WinXP, avec configuration de la connexion réseau NAT.
J'ai une application fonctionnant sous Win XP qui communique avec un service de gestionnaire de périphériques à l'aide de sockets TCP à l'adresse du serveur 127.0.0.1:4401. Je souhaite que le service de périphérique s'exécute sur un système d'exploitation invité VM (Ubuntu) tout en restant en mesure de communiquer avec l'application sur le système d'exploitation hôte.
Je peux atteindre l'hôte local du système d'exploitation hôte en utilisant l'adresse IP (192.168.1.100) de la carte réseau hôte. Mais si j'utilise 127.0.0.1 cela ne fonctionne pas. Il semble que les paquets soient consommés par le bouclage lo du système d'exploitation invité.
Configuration de l'hôte Win:
Windows IP Configuration
Ethernet adapter VMware Network Adapter VMnet8:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.59.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter VMware Network Adapter VMnet1:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.48.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter LoopBack:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.1.121
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.2
Ethernet adapter EtherLAN:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
Configuration du système d'exploitation invité Ubuntu:
eth0 Link encap:Ethernet HWaddr 00:0c:29:5f:4f:c1
inet addr:192.168.59.129 Bcast:192.168.59.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe5f:4fc1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6108 errors:0 dropped:0 overruns:0 frame:0
TX packets:4745 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6638533 (6.6 MB) TX bytes:371359 (371.3 KB)
Interrupt:19 Base address:0x2024
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2916 (2.9 KB) TX bytes:2916 (2.9 KB)
Quelqu'un peut-il me dire si cela est possible et quelle est la méthode recommandée pour le configurer?
J'ai le serveur openssh installé sur la machine virtuelle et à l'écoute
rootuser@ubuntu:~$ sudo netstat -tap | grep sshd
tcp 0 0 *:ssh *:* LISTEN 3469/sshd
Réponses:
Vous pouvez considérer une machine virtuelle comme étant une machine physique. La plage de bouclage 127.xxx n'est pas routée, elle est donc accessible uniquement à partir de la machine sur laquelle elle est configurée. Ceci est une partie et une garantie de la spécification IP, et accéder à une adresse 127.xxx à partir d’un périphérique autre que celui sur lequel il est configuré nécessiterait une implémentation d’IP qui était très défectueuse, et donc quelque chose que vous ne trouverez pas facilement.
Comme nous pouvons considérer qu'une machine virtuelle est identique à une machine physique, il s'ensuit qu'elle est distincte de l'hôte et qu'elle ne peut donc pas accéder à une adresse 127.0.0.1 sur son hôte.
Vous avez le choix entre modifier la configuration du service pour qu’il écoute une adresse IP routable, telle que son adresse d’interface.
Une autre option consisterait à utiliser la redirection de port sur ssh. Ainsi, si le service écoutait 127.0.0.1:4401 sur un périphérique avec l'adresse IP 192.168.1.100, vous pouvez créer un port qui lui serait redirigé depuis un autre périphérique à l'aide de la commande:
Cela ouvrirait donc une session SSH vers 192.168.1.100 et créerait en même temps un port local 127.0.0.1:4401 sur la machine qui initiait la connexion. Tout trafic en provenance et à destination de 127.0.0.1:4401 sur la machine locale passerait par le tunnel ssh à 127.0.0.1:4401 sur la machine distante.
la source
Ce n'est pas possible. 127.0.0.1 est local chez l'hôte.
Cela signifie que votre hôte XP a un 127.0.0.1 local uniquement pour cet hôte XP
et que votre invité vm a son propre 127.0.0.1 qui est local pour cet invité uniquement.
Ni l’un ni l’autre n’est censé quitter son hôte, et dans de nombreux cas, il est codé en dur dans les pilotes (pas sûr de XP, mais du matériel sous Linux et Win7 dans la DLL et le noyau).
Si vous souhaitez une communication entre les deux, liez le programme à différentes adresses IP.
la source