Je peux tracer une adresse IP, mais pas la cingler

19

Sous Windows, si je tracert vers Google, j'obtiens ce qui suit;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Maintenant, si je cingle la troisième dernière adresse IP de 66.249.95.234, j'obtiens ceci ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Comment se fait-il que le «ping» interne à tracert fonctionne différemment de celui du vrai ping? Comment sont-ils différents? Que dois-je faire pour que ping fonctionne comme tracert?

ping traceroute DJA
la source
3
Il se peut simplement que ICMP ECHO soit bloqué.
Burhan Khalid

Réponses:

27

Tout cela a à voir avec le fonctionnement de tracert. Ping est ICMP droit du point A au point B, qui traverse les réseaux via des règles de routage. Tracert fonctionne très différemment, même s'il utilise ICMP.

Tracert fonctionne en ciblant le saut final, mais en limitant le TTL et en attendant un message dépassé, puis en l'augmentant d'une unité pour la prochaine itération. Par conséquent, la réponse qu'il obtient n'est pas une réponse d'écho ICMP à la demande d'écho ICMP de l'hôte en cours de route, mais un message dépassé dans le temps de cet hôte - donc même s'il utilise ICMP, il l'utilise d'une manière très différente .

Vous pouvez lire plus de détails à ce sujet ici .

MaQleod
la source
12
Pour ajouter le dernier point pour lequel les pings expirent: Apparemment, le 3ème dernier 3 hôte est configuré pour fonctionner comme routeur pour le trafic à travers lui (ce qui inclut l'envoi de messages de contrôle ICMP TTL EXCEEDED pour les échecs) mais pour bloquer le trafic vers celui-ci, en particulier pour ne pas répondre à ICMP ECHO REQ. Soit dit en passant, le client traceroute pourrait envoyer n'importe quoi avec le bond final comme destination - il pourrait s'agir d'ICMP ECHO REQ mais il pourrait tout aussi bien s'agir de TCP SYN (qui pourrait déclencher d'autres messages ICMP, en particulier lorsque l'hôte jhost cible est atteint. En fait, l'implémentation diffère selon les systèmes d'exploitation et puis il y a tracepath...
Hagen von Eitzen
@HagenvonEitzen Cela ferait une réponse décente à elle seule (la meilleure, IMO!)
Courses de légèreté avec Monica
3
Il convient également de noter que de nombreuses implémentations "tracert" n'envoient même pas de paquets ICMP. C'est du moins le cas pour la tracerouteplupart des systèmes Linux, qui envoient des datagrammes UDP, bien que je ne sois pas sûr de ce que fait la version Windows. Les sauts intermédiaires doivent envoyer un ICMP TTL EXCEEDED pour tout type de paquet, pas seulement ICMP.
Digital Trauma
1
@DigitalTrauma Wireshark dit que tracertsur Windows 7 envoie des demandes d'écho ICMP.
Bob
4

Tout d'abord, vos deux commandes envoient des paquets avec des adresses IP de destination différentes. Cela signifie qu'ils peuvent emprunter des itinéraires différents.

Lorsque vous voyez 66.249.95.234sur l'itinéraire vers 216.58.220.100, vous pouvez supposer que les paquets avec l'adresse de destination 66.249.95.234utiliseraient le même itinéraire jusqu'à ce point. Ce n'est cependant pas une hypothèse valable.

Il est tout à fait valable que l'itinéraire 66.249.95.234soit plus long que celui vers 216.58.220.100. Parfois, il arrive même qu'il n'y ait aucune route qui pourrait emmener vos paquets vers ce routeur intermédiaire, mais ce ne serait pas un réseau bien conçu, si c'était le cas.

Je ne sais pas si les commandes tracertet que pingvous utilisez toutes les deux utilisent le même protocole. La plupart des implémentations de ping utilisent des paquets de demande d'écho ICMP. Cependant, il existe des implémentations traceroute prenant en charge un large éventail de protocoles, y compris la demande d'écho ICMP, TCP SYN et les paquets UDP. Si les deux utilisent des protocoles différents, cela pourrait être un facteur contribuant à voir des résultats différents.

Enfin, même si tous les paquets devaient être atteints 66.249.95.234, il est possible que 66.249.95.234le comportement soit extrêmement différent selon qu'il doit:

  • Transférer le paquet
  • Produire une erreur ICMP sur un paquet adressé à lui-même
  • Produire une erreur ICMP sur un paquet adressé à quelqu'un d'autre

Choisir de supprimer silencieusement des paquets dans l'un des trois cas va évidemment casser de nombreux outils de diagnostic réseau, ce qui n'empêche cependant pas certains administrateurs système de le faire de toute façon.

kasperd
la source
0

Comme la sécurité sur le réseau n'a cessé d'augmenter, une chose facile que beaucoup de gens font maintenant est de désactiver essentiellement les aspects du protocole ICMP. Cela empêche de répondre aux traceroutes et de renvoyer le nom de domaine complet du saut. Parfois, les administrateurs verrouillent les choses afin que même un ping ne fonctionne pas. Il s'agit d'une décision de l'administrateur du système concerné.

Il y a aussi la possibilité que le système gère une charge réseau importante, ICMP a généralement une priorité très faible dans le traitement par rapport aux données réelles.

mdpc
la source
5
Cela ne répond pas vraiment à la question. La question est de savoir pourquoi, si traceroute et ping utilisent ICMP, ping échoue et traceroute réussit.
MaQleod