Probléme de ping serveur/client....

Fermé
bigpush92 Messages postés 25 Date d'inscription vendredi 21 décembre 2012 Statut Membre Dernière intervention 12 janvier 2013 - 21 déc. 2012 à 15:35
 Scorpius - 1 janv. 2013 à 17:30
Bonjour à tous !

Je travaille sur un projet linux, sous debian master.
Pour cela, je travaille sous VMware et j'utilise deux machines virtuelles. Les deux tournent sur debian.

Les deux machines sont sur le même réseau, une fait office de serveur et l'autre de client.
j'ai configuré du dhcp sur ma machine serveur, afin qu'elle distribue une adresse ip a des machines clientes du reseau local. Jusqu'ici tout va bien :)

Par la suite, lorsque j'essaye de pinger mon serveur depuis la machine cliente, cela ne fonctionne pas. Cependant, lorsque je ping le client depuis le serveur, tadam cela fonctionne. Et, suite a ce ping réussit, le ping du client vers le serveur fonctionne a son tour.

Donc, je me demande d'ou cela peut venir, si quelqu'un a une idée parce que la... je ne vois vraiment pas.

Merci a ceux qui prendront le temps de repondre :)


2 réponses

Bonjour,

Peut-être un problème d'ARP. L'ARP est le protocole qui permet de résoudre une adresse IP en adresse MAC sur un LAN, c'est ce qui est à la base de la discutions entre les machine sur un lan.

Âpres le premier ping depuis le client vers le serveur, peux-tu lancer arp -a et donner la réponse à cette commande?
0
bigpush92 Messages postés 25 Date d'inscription vendredi 21 décembre 2012 Statut Membre Dernière intervention 12 janvier 2013
21 déc. 2012 à 16:22
Merci de la rapidité a laquelle tu as répondu :)
donc, j'ai lancé un ping du client vers le serveur. Suite a quoi j'ai tapé la commande arp-a.

j'obtiens pour réponse :

? (192.168.16.2) at 00:50:56:e9:8a:44 [ether] on eth1
? (172.17.2.1) at 00:50:56:c0:00:01 [ether] on eth0

(j'ai deux cartes reseau, une pour le host-only et une pour profiter de ma connection itnernet en NAT)
Evidemment, 172.17.2.1 est l'adresse ip du serveur.
0
Ok, dans cette réponse on voit qu'il à bien résolu l'adresse mac du serveur, et donc qu'ils ont réussis à communiquer sur le lan. Qu'elle erreur te sort la commande ping?

Peux-tu aussi donner la sortie de route -n?
0
bigpush92 Messages postés 25 Date d'inscription vendredi 21 décembre 2012 Statut Membre Dernière intervention 12 janvier 2013
21 déc. 2012 à 17:00
lorsque j'effectue mon ping, c'est sans fin, du coup j'annule avec ctrl+c...
s'affiche alors : 31 packets transmitted, 0 received, 100%packet loss.

route -n m'affiche :

192.168.16.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
172.17.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.16.2 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 172.17.2.1 0.0.0.0 UG 0 0 0 eth0
0
En fait, sur chaque ligne de ton ping tu as un message en début de ligne.
Ce message spécifie comment il s'est rendu compte du problème.

Mais ta commande route est très intéressante, tu as deux passerelles par défaut ce qui est mauvais dans ta configuration précisé.

Si tu va sur le net par eth1, alors tu peux supprimer la deuxième avec un route del default gw 172.17.2.1 dev eth0

Supprime cette route et retest le ping.

Peux-tu faire un route -n sur ton serveur aussi?
0
bigpush92 Messages postés 25 Date d'inscription vendredi 21 décembre 2012 Statut Membre Dernière intervention 12 janvier 2013
21 déc. 2012 à 17:15
je débute dans linux... et je n'y connais pas grand chose en reseau... en fait peux tu m'expliquer a quoi sert une passerelle ?

sinon voila un screen... le ping echoue toujours
http://imageshack.com/f/0lpingxqp
0
Sur un lan, les échanges réseau sont constitués de paquets, et chaque paquet comporte une destination.

Sur un lan toutes les machines discutent entre elles grâce à leurs adresse mac, les paquet qu'envoi une machine vers une autre contient comme destination l'adresse mac de la machine de destination. C'est à quoi sert le protocole ARP., transformer une IP en adresse mac pour pouvoir envoyer le paquet vers la bonne machine.

Pour contacter une machine sur le LAN c'est donc transparent.

Mais quand tu veux contacter un serveur sur un autre réseau, alors la ton serveur ne connait pas l'adresse mac de la machine distante puisqu'elle est pas dans le lan.

Quand ton serveur se rend compte que la machine qu'il doit contacter n'est pas dans le lan, alors cette fois il va mettre en destination l'adresse mac de la passerelle par défaut, ton paquet arrive donc à la passerelle par défaut qui va ensuite faire suivre ce paquet en fonction des routes qu'elle a.

En gros une passerelle par défaut est la machine vers laquelle est envoyé tout les paquets dont les destinataires ne sont pas dans le lan.

Peux-tu faire un route -n sur ton serveur?
0