Pourquoi traceroute échoue pour amazon.com, yahoo.com et ebay.com?

13

Tout en résolvant les problèmes de performances sur notre réseau, j'ai couru traceroutesur divers sites Web. Les sites Web suivants ne se termineraient pas à plusieurs reprises traceroute:

yahoo.com
amazon.com
ebay.com

Des questions

Ces sites protègent-ils leur réseau d'une manière qui tracerouten'est pas en mesure de se terminer?
Je suppose que cela est basé sur les réseaux de ces sites Web et n'est pas lié à nos problèmes de performances réseau. Est-ce une hypothèse sûre à faire?

Exemple Traceroute pour ebay.com

$ traceroute ebay.com
traceroute: Warning: ebay.com has multiple addresses; using 66.135.205.13
traceroute to ebay.com (66.135.205.13), 64 hops max, 52 byte packets
 1  10.10.100.1 (10.10.100.1)  56.518 ms  2.390 ms  2.082 ms
 2  mo-69-34-118-1.sta.embarqhsd.net (69.34.118.1)  9.943 ms  10.007 ms  10.177 ms
 3  mo-69-68-209-249.dyn.embarqhsd.net (69.68.209.249)  10.976 ms  21.159 ms  10.015 ms
 4  ge-6-20.car1.stlouis1.level3.net (4.53.160.13)  26.562 ms  26.278 ms  25.818 ms
 5  ae-11-11.car2.stlouis1.level3.net (4.69.132.186)  26.393 ms  26.519 ms  79.884 ms
 6  ae-4-4.ebr2.chicago1.level3.net (4.69.132.190)  32.965 ms  26.123 ms  48.123 ms
 7  ae-5-5.ebr2.chicago2.level3.net (4.69.140.194)  27.308 ms  26.784 ms  26.693 ms
 8  ae-2-52.edge4.chicago3.level3.net (4.69.138.166)  27.137 ms  26.473 ms  27.047 ms
 9  chp-brdr-03.inet.qwest.net (63.146.27.17)  26.315 ms  26.329 ms  26.449 ms
10  dvr-edge-13.inet.qwest.net (67.14.24.89)  51.270 ms  51.355 ms  51.134 ms
11  * * *
12  * * *
. . . . .
33  * * *
34  * *^C

security networking

— Matthew Rankin
source

16

Si vous bloquez du trafic ICMP, pour le pare-feu ou pour une autre raison, les traceroutes ne fonctionnent pas complètement. Ils sont généralement un mélange d'UDP (les recherches DNS) et d'ICMP.

Si vous courez traceroute -I yahoo.comou traceroute -T yahoo.comvous devriez voir des résultats différents (yahoo.com se termine pour moi). Cela utilise l'écho ICMP et les SYN TCP.

Depuis la page de manuel de la traceroutecommande sur Linux:

In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).

— Jonathan Ross
source

Certaines versions de traceroute peuvent ne pas prendre en charge l' -Tindicateur, mais beaucoup prennent en charge l' -P [protocol]indicateur. Sur FreeBSD 8 traceroute comprend UDP, TCP, GREamd ICMP(et peut définir le champ de protocole pour tout protocole IP valide, bien que le contenu des paquets peuvent ne pas être utile / sain d' esprit.)

— voretaq7

15

Traceroute utilise des groupes de messages ICMP. chacun a 3 messages ICMP. (Incrément du compte HOP de un dans chaque groupe de messages).

Habituellement, les administrateurs bloquent les paquets ICMP pour «protéger» leur réseau. (principalement pour obscurcir la structure du réseau et du DoS).

Voilà pourquoi vous obtenez des étoiles.

— Amirali Sanatinia
source

0

Tracert n'est pas un outil pour analyser les problèmes de performances, c'est un outil pour découvrir le chemin vers un hôte particulier. L'exécution de tracert sur un hôte externe ne vous dit rien sur votre propre réseau.

Commencez par examiner votre réseau interne en mesurant la latence et la perte de paquets entre deux hôtes internes. Ensuite, exécutez une capture de paquets sur votre poste de travail et recherchez des preuves de congestion du réseau comme les inondations ARP, les tempêtes de diffusion, les retransmissions TCP et les accusés de réception en double.

— joeqwerty
source

Merci pour l'info. J'aurais dû préciser que nos problèmes de performances sont principalement liés à l'accès à des sites Web externes. Je dis «principalement» parce que nous avons de multiples problèmes liés au réseau. J'ai éliminé notre seul et grand domaine de collision en raison de l'utilisation de concentrateurs en échangeant 3 ou 4 concentrateurs avec des commutateurs. Notre fournisseur DSL a admis qu'il n'y avait pas assez de cuivre dans notre région compte tenu de la demande des clients (nous sommes dans une petite ville et c'est notre seule option viable de FAI). J'essaie donc d'améliorer notre réseau interne, tout en collectant des données pour prouver au FAI qu'il a un problème.

— Matthew Rankin

D'accord, mais encore une fois, tracert n'est pas le bon outil et le traçage vers Google et cela n'aidera pas beaucoup car une fois que le trafic quitte votre FAI, il n'y a plus rien à faire. Vous devez vous préoccuper de la connexion entre vous et le FAI. Connectez-vous à votre modem DSL, découvrez ce que c'est DG et exécutez pathping de vous à là. Ensuite, exécutez tracert vers Google pour déterminer le dernier saut dans votre réseau ISP et exécutez pathping de vous à là-bas. Fournissez ces résultats à votre FAI et voyez ce qu'ils ont à dire.

— joeqwerty