Fièrement, je ne peux pas faire de ping de ma passerelle à partir de machines virtuelles linux

Supposons les situations suivantes:

Gateway IP: 10.0.0.60
Host IP (Win7): 10.0.0.81
Invité 1 sur cet hôte (VMWare-Linux-Kali): 10.0.0.16
Guest 2 sur cet hôte (VMWare-Win7): 10.0.0.27
Gateway est un serveur Kerio.

Le problème:

Je ne peux pas faire de ping sur la passerelle de la machine virtuelle Kali-Linux, alors que je peux faire un ping de la machine virtuelle Host et Win7!

Configuration:

Tous les pare-feu de l'hôte et des invités sont désactivés.
Les invités peuvent effectuer un ping et faire ping sur l'hôte!
L'hôte peut faire un ping aux deux invités avec succès!
Les paramètres du réseau Adabpter pour les deux invités sont égaux et la seule différence est leur IP.
Les adaptateurs réseau de machines virtuelles sont reliés à la carte réseau hôte.

Qu'est-ce que j'ai fait jusqu'ici?

J'ai remplacé l'adresse IP invité de Kali-linux par l'adresse IP hôte Win7 (et vice-versa). Bien, rien n'a changé!
J'ai essayé d'autres systèmes d'exploitation en tant qu'invité. Pour Ubuntu et Backtrack, je ne peux pas faire de ping sur la passerelle, mais pour Win7 et Win XP, c'est correct.
Je lance Wireshark sur mon hôte et surveille le trafic. Eh bien, je peux voir les paquets de demande ICMP pour les clients Linux et les invités Windows, mais la réponse de Gateway est uniquement pour Windows.

Solution instable:

Dans le passé, lorsque je fais face à ce problème, la manipulation du tableau de route sur la machine virtuelle Linux a été résolue (50% -50%), mais maintenant, cela ne fonctionne plus!

Paramètres:

Mon hôte:

 C:\Users\asdf.IT>ipconfig -all Windows IP Configuration Host Name . . . . . . . . . . . . : asdf-PC Primary Dns Suffix . . . . . . . : it.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : it.com Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller Physical Address. . . . . . . . . : 08-60-6E-70-4C-E4 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::6079:96ba:2ea2:18e9%11(Preferred) IPv4 Address. . . . . . . . . . . : 10.0.0.81(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.0.0.60 DHCPv6 IAID . . . . . . . . . . . : 235429998 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : 10.0.0.10 8.8.4.4 NetBIOS over Tcpip. . . . . . . . : Enabled Ethernet adapter VMware Network Adapter VMnet1: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet 1 Physical Address. . . . . . . . . : 00-50-56-C0-00-01 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::45cc:c483:1d0a:a9a%17(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.227.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 218124374 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled Ethernet adapter VMware Network Adapter VMnet8: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet 8 Physical Address. . . . . . . . . : 00-50-56-C0-00-08 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::19cc:79f0:bc05:ce97%18(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.153.1(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 251678806 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-B7-B0-8E-08-60-6E-70-4C-E4 DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled Tunnel adapter isatap.{1FD7A0A9-BE6F-44F9-8BA7-E7E0043D4B36}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.{41D1949E-CADB-47E2-BBDC-F907E48DBA03}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes

Gagnez 7 invités (sur VMware): Entrez la description de l'image ici

Invité Kali Linux (sur VMware): Entrez la description de l'image ici

Est-ce que quelqu'un a une idée de l'origine de ce problème?

Votre table de routage est correcte, en fait elle est identique à la mienne.

Mais vous indiquez:

Je lance Wireshark sur mon hôte et surveille le trafic. Eh bien, je peux voir les paquets de demande ICMP pour les clients Linux et les invités Windows, mais la réponse de Gateway est uniquement pour Windows.

Cela signifie que votre passerelle répond de manière différente aux deux paquets ping. La meilleure façon de procéder est de capturer les deux paquets et de les comparer. Étant donné que vous utilisez wireshark, écoutez l'interface sortante de l'hôte, restreignez votre capture au protocole icmp et à la destination 10.0.60.0 , 10.0.60.0 ping une seule fois à partir de host1 nd host2, enregistrez les 2 paquets dans un fichier, étudiez ce qui est différent entre eux.

La différence entre les deux paquets est ce qui déclenche le comportement de la passerelle différente. Si , à la fin, la seule différence est l'adresse IP source, cela signifie qu'il y a un problème avec votre adresse kali Ip. S'il s'agit d'une adresse statique, assurez-vous qu'il se trouve en dehors de la plage DHCP. Sinon, vous pouvez essayer de redémarrer la passerelle, l'hôte et les machines virtuelles pour assurer la libération des baux DHCP, en cas de conflit avec les adresses précédemment attribuées.

J'ai eu un problème presque identique (Google m'a amené ici) mais dans mon cas, le problème était que la configuration de la VM avait en quelque sorte changé de Bridged (assigné à sa propre NIC) à NAT, d'où la VM pensait qu'il avait une adresse IP attribuée par Le pont virtuel de VMWare, malgré moi, a modifié / etc / networking / interfaces et j'ai redémarré le service réseau …

En rétrospective, je ne peux pas penser à la façon dont les paramètres de réseau pourraient changer dans VMWare, donc je suis plus enclin à penser que c'était mon erreur, mais je pourrais avoir juré de mettre la VM sur «bridged» avant de lancer le Kali VMDK. …