Pourquoi est-ce que je peux cingler une adresse IP mais pas la "traceroute"?
Je peux envoyer une requête ping à une adresse IP, mais je ne peux pas la tracer. Comment cela pourrait-il être?
[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 de traceroute n’est pas la même que celle du "ping CENSORED.CENSORED".
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 les paquets ICMP ou UDP. Il pince efficacement chaque routeur sur le chemin entre vous et censored.censored. Il augmente la durée de vie (TTL) de chaque paquet suivant qu'il envoie (de 1 à 30 normalement) en s'attendant à ce que chaque paquet soit envoyé avec une augmentation de TTL depuis le dernier, le prochain routeur de la liste. chemin retournera un code d'erreur.
Si le saut 6 ne répond pas, il bloque probablement spécifiquement les messages ICMP/UDP. Ping fonctionne donc parce que les routeurs entre vous et lui ne font que transmettre les paquets ICMP/UDP au lieu de répondre, comme ils le font avec un traceroute.
Je n'ai vu aucune réponse au pourquoi une partie des questions.
Plusieurs fournisseurs de services Internet sont connus pour rendre leurs routeurs furtifs à traceroute de deux manières: soit ils ne décrémentent pas TTL dans les paquets IP (se faisant eux-mêmes des trous de ver IP), soit ils ne répondent pas aux expirés TTL tout en transférant 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 qui ne ressemble pas à tout le monde.
Parfois, il vaut la peine d'utiliser ping pour obtenir des informations semblables à celles de 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 ping avec un argument -t $ TTL, vous pouvez parfois contourner le pare-feu et rechercher des adresses IP, etc., de routeurs derrière des pare-feux.
Traceroute s'appuie sur les messages ICMP, sur lesquels certains routeurs peuvent être configurés pour ne pas répondre.
Tous les nœuds à partir de 6 ne répondent pas aux paquets UDP ou le nœud 6 lui-même bloque les paquets UDP. Vous pouvez essayer les méthodes fllowing, qui, je l’espère, fonctionneront en fonction du nœud situé sur le chemin des blocs de détection, ICMP/TCP SYN:
Utilisez ICMP pour traceroute: $ Sudo traceroute -I
Utilisez TCP syn pour traceroute: $ Sudo traceroute -T
Si ce sont les sauts qu’il dépasse, utilisez l’une des méthodes suivantes: $ Sudo traceroute -I -m 60
OR
$ Sudo traceroute -T -m 60
Ce dernier a travaillé pour moi tout en effectuant un traçage jusqu'à un ftp à travers le continent.
Pour utiliser la commande ping pour traceroute dans un environnement unix, essayez ceci:
for ((TTL=1;TTL<30;TTL++));
do
ping -c 1 -t $TTL <IP>;
done