2011-05-04 10:05:03 +0000 2011-05-04 10:05:03 +0000
47
47

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

Je peux envoyer un ping à une adresse IP, mais je ne peux pas la tracer. Comment est-ce possible ? 

[USERNAME@HOSTNAME ~]$ ping CENSORED.CENSORED
PING CENSORED.CENSORED (CENSORED) 56(84) bytes of data.
64 bytes from CENSORED.CENSORED (CENSORED): icmp_req=1 ttl=49 time=52.8 ms
64 bytes from CENSORED.CENSORED (CENSORED): icmp_req=2 ttl=49 time=49.4 ms
64 bytes from CENSORED.CENSORED (CENSORED): icmp_req=3 ttl=49 time=49.2 ms
64 bytes from CENSORED.CENSORED (CENSORED): icmp_req=4 ttl=49 time=50.4 ms
^C
--- CENSORED.CENSORED ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 49.276/50.494/52.804/1.401 ms
[USERNAME@HOSTNAME ~]$
[USERNAME@HOSTNAME ~]$ traceroute CENSORED.CENSORED
traceroute to CENSORED.CENSORED (CENSORED), 30 hops max, 60 byte packets
 1 CENSORED (CENSORED) 5.733 ms 6.000 ms 5.977 ms
 2 CENSORED (CENSORED) 0.428 ms 0.417 ms 0.393 ms
 3 CENSORED (CENSORED) 1.726 ms 1.718 ms 1.682 ms
 4 CENSORED (CENSORED) 26.699 ms 26.693 ms 26.670 ms
 5 CENSORED (CENSORED) 27.785 ms 27.769 ms 27.746 ms
 6 * * *
 7 * * *
 8 * * *
 9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[USERNAME@HOSTNAME ~]$

La cinquième adresse IP CENSORED dans le traceroute n'est pas la même que dans le “ping CENSORED.CENSORED”.
Source

Réponses (7)

42
42
42
2011-05-04 12:21:00 +0000

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 * * *
Source
23
23
23
2011-05-04 11:11:20 +0000

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.
Source
12
12
12
2014-03-09 21:54:36 +0000

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.
Source
2
2
2
2011-05-04 11:04:50 +0000

Traceroute s'appuie sur les messages ICMP, auxquels certains routeurs peuvent être configurés pour ne pas répondre.
Source
2
2
2
2011-05-04 15:44:09 +0000

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.
Source
0
0
0
2014-03-09 21:24:29 +0000

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.
Source
0
0
0
2014-03-09 21:29:44 +0000

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
Source