Pourquoi puis-je envoyer un ping à une adresse IP mais pas la "traceroute" ?

Essayez d'utiliser une méthode différente dans votre traceroute, par exemple TCP SYN ou ICMP au lieu de la méthode UDP par défaut.

Par exemple, notez la différence entre ICMP et TCP :

x@x:~$ ping -qc4 94.254.2.51
PING 94.254.2.51 (94.254.2.51) 56(84) bytes of data.
--- 94.254.3.90 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3009ms
rtt min/avg/max/mdev = 7.781/7.807/7.836/0.067 ms

x@x:~$ sudo traceroute -I 94.254.2.51
traceroute to 94.254.2.51 (94.254.2.51), 30 hops max, 40 byte packets
1 <REDACTED>
2 <REDACTED>
3 <REDACTED>
4 <REDACTED>
5 netnod-ix-ge-a-sth-1500.bahnhof.net (194.68.123.85) 1.307 ms 1.299 ms 1.432 ms
6 sto-cr1.sto-cr3.bahnhof.net (85.24.151.165) 7.166 ms 7.364 ms 7.336 ms
7 sto-cr3.gav-cr1.bahnhof.net (85.24.151.195) 7.251 ms 7.099 ms 7.220 ms
8 zitius-a322-gw-c.bahnhof.net (85.24.153.249) 7.059 ms 7.074 ms 7.145 ms
9 h-2-51.A322.priv.bahnhof.se (94.254.2.51) 7.619 ms 7.750 ms 8.070 ms

x@x:~$ sudo traceroute -T 94.254.2.51
traceroute to 94.254.2.51 (94.254.2.51), 30 hops max, 40 byte packets
1 <REDACTED>
2 <REDACTED>
3 <REDACTED>
4 <REDACTED>
5 netnod-ix-ge-a-sth-1500.bahnhof.net (194.68.123.85) 1.621 ms 1.683 ms 1.817 ms
6 sto-cr1.sto-cr3.bahnhof.net (85.24.151.165) 8.530 ms 7.861 ms 7.820 ms
7 sto-cr3.gav-cr1.bahnhof.net (85.24.151.195) 7.724 ms 7.539 ms 7.486 ms
8 zitius-a322-gw-c.bahnhof.net (85.24.153.249) 7.572 ms 7.537 ms 7.553 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *

Traceroute est basé sur des paquets ICMP ou UDP. Il pique effectivement chaque routeur sur le chemin entre vous et censuré.censuré. Il augmente le Time-To-Live (TTL) pour chaque paquet suivant qu'il envoie (de 1 à 30 normalement) en s'attendant à ce que, comme chaque paquet est envoyé avec un TTL augmenté par rapport au dernier, le routeur suivant dans le chemin renvoie un code d'erreur.

Si le saut 6 ne répond pas, c'est probablement parce qu'il bloque spécifiquement les messages ICMP/UDP. Le ping fonctionne donc parce que les routeurs entre vous et lui ne font que lui transmettre les paquets ICMP/UDP au lieu de leur répondre, comme ils le font avec un traceroute.

Je n'ai pas vu de réponse à la partie pourquoi des questions.

Plusieurs FAI sont connus pour rendre leurs routeurs furtifs pour traceroute de deux façons : soit ils ne décrémentent pas le TTL dans les paquets IP (se faisant des trous de ver IP), soit ils ne répondent pas au TTL expiré tout en transmettant l'ICMP.

La raison est de garder leur topologie de réseau interne privée. C'est tout.

L'émission de traceroutes depuis/vers plusieurs sources/destinations révèle des informations sur la topologie du réseau, ce que tout le monde n'apprécie pas.

Traceroute s'appuie sur les messages ICMP, auxquels certains routeurs peuvent être configurés pour ne pas répondre.

Parfois, il vaut la peine d'utiliser ping pour obtenir des informations de type traceroute :

#!/bin/bash
for TTL in 1 2 3 4 5 6 7 8 9 10 11 12
do
    ping -c 1 -n -t $TTL a.b.c.d
done

En appelant le ping avec un argument -t $TTL, vous pouvez parfois échapper au pare-feu, et trouver les adresses IP et ainsi de suite des routeurs derrière les pare-feu.

Soit tous les noeuds à partir de 6 ne répondent pas aux paquets UDP, soit le noeud 6 lui-même bloque les paquets udp. Vous pouvez essayer les méthodes flottantes qui, je l'espère, fonctionneront en fonction du nœud qui, dans le chemin vers la détermination, bloque ICMP/TCP SYN :

1. Utilisez ICMP pour traceroute : $ sudo traceroute -I

2. Utiliser TCP syn pour traceroute : $ sudo traceroute -T

3. Si c'est le houblon qu'il dépasse, alors utilisez l'un des éléments suivants : $ sudo traceroute -I -m 60

OR

$ sudo traceroute -T -m 60

Ce dernier élément a fonctionné pour moi lors du traçage vers un ftp à travers le continent.

Pour utiliser la commande ping pour traceroute dans l'environnement unix, essayez ceci :

for ((TTL=1;TTL<30;TTL++));
do
ping -c 1 -t $TTL <IP>;
done