Je peux tracert à une adresse IP, mais pas cingler
Sous Windows, si je me connecte à Google, je reçois le message suivant:
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, je reçois 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?
Tout est lié au fonctionnement de Tracert. Ping est directement ICMP 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 dernier saut, mais en limitant le TTL, en attendant un message dépassé, puis en l'augmentant d'un 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 dont le temps a dépassé le délai imparti par cet hôte. 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 .
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.234 sur l'itinéraire en direction de 216.58.220.100, vous pouvez supposer que les paquets avec l'adresse de destination 66.249.95.234 utiliseraient le même itinéraire jusqu'à atteindre ce point. Ce n’est cependant pas une hypothèse valable.
Il est tout à fait valide que la route vers 66.249.95.234 soit plus longue que celle vers 216.58.220.100. Parfois, il arrive même qu’aucune route ne puisse acheminer vos paquets vers ce routeur intermédiaire, mais ce ne serait pas un réseau bien conçu, si tel était le cas.
Je ne sais pas si les commandes tracert et ping que vous utilisez toutes les deux utilisent le même protocole. La plupart des implémentations de ping utilisent des paquets de requête d'écho ICMP. Cependant, des implémentations de traceroute existent, prenant en charge un large éventail de protocoles, notamment les requêtes d'écho ICMP, TCP SYN et UDP. Si les deux utilisent des protocoles différents, cela pourrait contribuer à obtenir des résultats différents.
Enfin, même si tous les paquets devaient atteindre 66.249.95.234, il est possible que 66.249.95.234 se comporte de manière très différente selon qu'il doit:
- Transférer le paquet
- Produire une erreur ICMP sur un paquet qui lui est adressé
- Produire une erreur ICMP sur un paquet adressé à quelqu'un d'autre
Choisir de supprimer silencieusement les paquets dans un seul des trois cas va évidemment ruiner de nombreux outils de diagnostic réseau, ce qui n'empêche toutefois pas certains administrateurs système de le faire.
La sécurité sur le réseau étant en augmentation constante, une chose facile à faire pour de nombreuses personnes consiste à désactiver les aspects du protocole ICMP. Cela empêche de répondre aux traceroutes et de renvoyer le nom de domaine complet (FQDN) du saut. Parfois, les administrateurs verrouillent que même un ping ne fonctionne pas. Ceci est une décision de l'administrateur du système impliqué.
Il est également possible que le système traite une charge réseau importante. ICMP a généralement une priorité de traitement très faible par rapport aux données réelles.