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
la source
la source
Réponses:
Sur une question similaire ici, Luke Savage l'a parfaitement expliqué:
la source
traceroutecommande et nontracertce 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 pasICMPfortraceroute. En d'autres termes, puisquePINGutiliseICMP(que je pense est bloqué par le système que vous essayez d'atteindre) et traceroute utilise desUDPpaquets avec une méthode d'incrémentation deTTLchamp (qui, je pense, n'est pas bloqué sur le système que vous essayez d'atteindre)PINGéchoue maisTracerouteréussit.tracerouteest en utilisant ICMP, même si elle est l' envoi UDP, à savoir qu'il attend et évalue lesTTL exceededmessages du houblon sur le chemin. Un hôte qui bloque tous les ICMP est une mauvaise idée, maispingéchouera déjà lorsque lesICMP echodemandes ou les réponses sont bloquées sur l'hôte ciblePour 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 *).
la source
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
tracerouteetping.Essayons d'abord de
ping 8.8.8.8regarder ce qui se passe:pingEnvoie donc une demande d'écho ICMP et attend une réponse d'écho ICMP.Maintenant
traceroute -n 8.8.8.8: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 source
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.
la source
Linux utilisant UDP au lieu d' ICMP pour traceroute, le pare-feu n'a pas bloqué ce port UDP
la source
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
la source
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 parpingest 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.la source