Pourquoi puis-je traceroute vers cette adresse IP, mais pas ping?

21

J'ai une adresse IP et je peux tracer la route, mais je ne peux pas cingler.

Vous voyez, je peux traceroute 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

Mais je ne peux pas le cingler:

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

S'il y a une interdiction d'ICMP, cela traceroutene devrait pas fonctionner non plus. Quelle en est la raison?

J'ai vérifié que le pare-feu du serveur est arrêté.

ping  networking  icmp  traceroute 
— 244boy
source
peut-il être que le délai d'attente pour le ping est trop restrictif, et il aurait été réussi, compte tenu des délais plus clément? Traceroute a donné plus de 500 ms pour certains nœuds.
— vsz
Une réponse vous a-t-elle aidé? Si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
— Ron Maupin

Réponses:

39

Sur une question similaire ici, Luke Savage l'a parfaitement expliqué:

Traceroute n'est pas un protocole lui-même, c'est une application et les protocoles utilisés dépendent de l'implémentation que vous utilisez. Il s'agit principalement d'ICMP.

Il existe deux implémentations principales:

tracert - tracert est une application Windows qui utilise des paquets ICMP avec comme champ TTL incrémentiel pour mapper les sauts à l'adresse de destination finale.

traceroute - traceroute est une application * nix disponible sur la plupart des systèmes basés sur Linux, y compris les périphériques réseau, et sur les périphériques Cisco. Cela utilise des paquets UDP avec un champ TTL incrémenté pour mapper les sauts vers la destination finale.

La différence entre ceux-ci est utile à savoir car certains réseaux bloquent désormais ICMP par défaut, donc PING et tracert à partir d'une machine Windows échoueront, mais une traceroute à partir d'un périphérique Linux peut toujours fonctionner.

— naïveRSA
source
2
alors, pourquoi mon IP de serveur peut traceroute mais pas ping?
— 244boy
10
De votre sortie partagée, je peux voir que vous utilisez la traceroutecommande et non tracertce qui m'a fait penser que vous utilisez un système d'exploitation basé sur Unix ou GNU. Dans la réponse que j'ai mentionnée, vous pouvez voir que les systèmes basés sur Unix n'utilisent pas ICMPfor traceroute. En d'autres termes, puisque PINGutilise ICMP(que je pense est bloqué par le système que vous essayez d'atteindre) et traceroute utilise des UDPpaquets avec une méthode d'incrémentation de TTLchamp (qui, je pense, n'est pas bloqué sur le système que vous essayez d'atteindre) PINGéchoue mais Tracerouteréussit.
— naïveRSA
4
Plutôt que d'ajouter un nouveau commentaire à votre message lorsque quelqu'un comme 244boy suggère une amélioration, il serait préférable de modifier votre message afin que les futurs lecteurs de la réponse n'aient pas à lire tous les commentaires pour obtenir la réponse complète.
— Keeta - réintègre Monica le
@ naïveRSA à proprement parler, tracerouteest en utilisant ICMP, même si elle est l' envoi UDP, à savoir qu'il attend et évalue les TTL exceededmessages du houblon sur le chemin. Un hôte qui bloque tous les ICMP est une mauvaise idée, mais pingéchouera déjà lorsque les ICMP echodemandes ou les réponses sont bloquées sur l'hôte cible
— Hagen von Eitzen
17

Pour ajouter à la réponse de @ naïveRSA , s'il y a un filtrage / pare-feu sur le chemin, on pourrait également avoir la situation où un paquet ICMP de "réponse d'écho" (ping) est bloqué, mais un paquet ICMP "temps dépassé" (tracert) est autorisé . Cela donnerait les mêmes résultats même lorsque seul ICMP (Windows) est utilisé.

Dans les deux cas (expéditeur utilisant UDP ou ICMP), la communication d'erreur sera ICMP (c'est-à-dire le nœud répondant à un paquet ping ou tracer *).

— Arjan
source
6

Voyons ce qui se passe, d'accord?

8.8.8.8 est un bon exemple, car au moins depuis mon emplacement, je peux y accéder à la fois avec tracerouteet ping.

Essayons d'abord de ping 8.8.8.8regarder ce qui se passe:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

pingEnvoie donc une demande d'écho ICMP et attend une réponse d'écho ICMP.

Maintenant traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

Donc traceroute, au moins l'implémentation que j'ai installée, n'envoie pas ICMP. Il envoie plutôt des paquets UDP.

Ce qui n'est pas visible dans cette trace (même si ce serait le cas si je donnais tcpdumpun -vpour augmenter la verbosité) est que les premières sondes ont un ttl de 1, puis il incrémente le ttl pour les sondes ultérieures. Cela provoque les routeurs entre moi et 8.8.8.8 à répondre avec une erreur ICMP ttl dépassée, c'est ainsi que traceroute découvre les routeurs entre ici et là.

Finalement, le ttl est suffisamment long pour se rendre jusqu'à 8.8.8.8, et 8.8.8.8 répond avec une erreur de port ICMP inaccessible, car il n'a aucun processus d'écoute sur le port UDP 44838. C'est ainsi que traceroute sait qu'il a atteint la destination finale .

Si quelque chose entre ici et là bloque tous les ICMP, alors ni ping ni traceroute ne fonctionneront.

Mais ce n'est généralement pas le cas que tous les ICMP sont bloqués, bien que ce ne soit pas rare non plus. Le blocage de tous les ICMP est problématique: par exemple, il rompt la découverte du chemin MTU , qui repose sur une erreur de fragmentation ICMP requise. Les paquets ICMP ont un type et un code, et les opérateurs de réseau responsables ne bloqueront que de manière sélective certains types ou codes, ceux qui présentent un risque d'abus ou divulguent des informations particulières.

Par exemple, certains hôtes ne répondront pas du tout à une demande d'écho ICMP, et donc le ping ne fonctionnera pas. L'idée est qu'en ne répondant pas aux pings, il est plus difficile pour un attaquant de découvrir quels hôtes existent sur le réseau. En pratique, cela est discutable, car il existe d'autres façons de rechercher un hôte. Par exemple, on peut envoyer un TCP SYN au port 80 pour trouver des serveurs Web.

De nombreux hôtes n'envoient pas non plus d'erreur de port ICMP inaccessible lorsqu'ils obtiennent un datagramme UDP ou un TCP SYN vers un port sur lequel ils n'ont pas d'écoute de processus, ce qui interrompt la traceroute. Encore une fois, l'idée est de rendre plus difficile pour un attaquant de cartographier le réseau, mais là encore, ce n'est qu'une frustration mineure pour un attaquant.

Parce que traceroute est un programme et non un protocole particulier, il a d'autres façons de sonder. Ils s'appuient tous sur l'incrémentation de la TTL pour découvrir les routeurs, mais différents types de sondes peuvent être envoyés, ce qui peut avoir plus ou moins de chance d'obtenir une réponse du point de terminaison. Par exemple, ma man tcpdumpliste une -Ioption pour utiliser des sondes d'écho ICMP, la même chose que ping. Il doit également -Tutiliser des sondes TCP SYN au lieu d'UDP. Si vous connaissez un hôte répondra à pingalors -Ifait beaucoup de sens. Si vous savez que l'hôte écoute sur un port TCP particulier, -Tcela a du sens, peut-être en conjonction avec l' -poption de sélection du port.

Malheureusement, ces options peuvent nécessiter des capacités root ou spéciales, donc UDP fait un bon choix par défaut. En fait, un outil similaire,, tracepatha ceci à dire dans sa page de manuel:

LA DESCRIPTION

Il trace le chemin vers la destination en découvrant MTU le long de ce chemin. Il utilise le port de port UDP ou un port aléatoire. Il est similaire à traceroute, ne nécessite que des privilèges de superutilisateur et n'a pas d'options fantaisistes.

— Phil Frost
source
2

TLDR; les pings peuvent être bloqués (bloc ICMP) sur un hôte distant mais traceroute peut toujours trouver la route vers celui-ci en utilisant le routage réseau standard UDP ou TCP / IP (tout protocole vraiment; ref /networkengineering//a/36509/ 58968 ). Notez que votre ping peut également atteindre l'hôte (sauf si vous avez peut-être un pare-feu très intelligent bloquant le trafic ping ICMP quelque part), l'hôte ne répond tout simplement pas.

— Roel Van de Paar
source
0

Linux utilisant UDP au lieu d' ICMP pour traceroute, le pare-feu n'a pas bloqué ce port UDP

— farshad khazaee
source
0

Vous pouvez installer nmap (insecure.org) et utiliser nping avec UDP ou TCP et n'importe quel port. Fonctionne très bien sur les réseaux avec le ping bloqué sortant.

Pour envoyer une requête ping à un serveur Web nping --tcp -p 80,443

Pour envoyer une requête ping à un serveur de temps nping --udp -p 123

https://nmap.org/book/nping-man.html

— Michael Hubbard
source
0

Une réponse brève à votre question est que l' pingutilitaire s'appuie sur le protocole ICMP qui est parfois bloqué au niveau du pare-feu réseau ou du pare-feu sur l'appareil lui-même. La raison la plus courante pour laquelle les administrateurs réseau bloquent ICMP est d'empêcher le "scan" du réseau qu'ils considèrent comme un problème de sécurité. L' tracerouteutilitaire sous Linux utilise UDP, un protocole complètement différent, qui dans ce cas n'est pas bloqué par les administrateurs réseau. UDP a une variété d'utilisations et son blocage rendrait beaucoup de choses inutilisables sur un réseau. Le type de «message de contrôle» ICMP requis par pingest un sous-ensemble d'un protocole, ce qui signifie que le blocage de ce type de paquet ICMP provoque moins de problèmes sur un réseau et est donc plus susceptible d'être bloqué que UDP.

— Cybernaut
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.