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

Dlaczego mogę pingować adres IP, ale nie mogę go traceroute'ować?

Mogę pingować adres IP, ale nie mogę go przekierować. Jak to możliwe? 

[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 ~]$

Piąty CENSORED adres IP w traceroute nie jest taki sam jak w “ping CENSORED.CENSORED”.
Źródło

Odpowiedzi (7)

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

Spróbuj użyć innej metody w swoim traceroute, na przykład TCP SYN lub ICMP zamiast domyślnej metody UDP.

Na przykład zauważ różnicę pomiędzy ICMP i 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 * * *
Źródło
23
23
23
2011-05-04 11:11:20 +0000

Traceroute jest oparty na pakietach ICMP lub UDP. To skutecznie pings każdy router na ścieżce między tobą a censored.censored. Zwiększa on Time-To-Live (TTL) dla każdego kolejnego wysyłanego pakietu (od 1-30 normalnie) oczekując, że jak każdy pakiet jest wysyłany z zwiększonym TTL od ostatniego, następny router na ścieżce zwróci kod błędu.

Jeśli hop 6 nie odpowiada, to prawdopodobnie specjalnie blokuje wiadomości ICMP/UDP. Ping działa więc dlatego, że routery pomiędzy tobą a nim po prostu przepuszczają pakiety ICMP/UDP do niego, zamiast odpowiadać na nie, tak jak to robią w przypadku traceroute.
Źródło
12
12
12
2014-03-09 21:54:36 +0000

Nie widziałem odpowiedzi na część why pytania.

Niektórzy dostawcy usług internetowych są znani z tego, że ich routery ukrywają się przed traceroute na dwa sposoby: albo nie zmniejszają TTL w pakietach IP (robiąc z siebie IP wormholes), albo nie odpowiadają na wygasłe TTL, podczas gdy nadal przesyłają ICMP.

Powodem jest utrzymanie topologii ich sieci wewnętrznej w tajemnicy. To wszystko.

Wystawianie traceroutes z/do wielu źródeł/destynacji ujawnia informacje o topologii sieci, co jest czymś, co nie każdy docenia.
Źródło
2
2
2
2011-05-04 11:04:50 +0000

Traceroute opiera się na komunikatach ICMP, na które niektóre routery mogą być skonfigurowane tak, aby na nie nie odpowiadać.
Źródło
2
2
2
2011-05-04 15:44:09 +0000

Czasami warto użyć ping aby uzyskać informacje podobne do 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

Wywołując ping z argumentem -t $TTL, można czasem wymknąć się firewallowi i poznać adresy IP itp. routerów znajdujących się za firewallami.
Źródło
0
0
0
2014-03-09 21:24:29 +0000

Albo wszystkie węzły od 6 nie odpowiadają na pakiety UDP, albo węzeł 6 sam blokuje pakiety udp. Możesz spróbować następujących metod, które mam nadzieję będą działać w oparciu o to, który węzeł na ścieżce do detalizacji blokuje ICMP/TCP SYN :

  1. Użyj ICMP do traceroute : $ sudo traceroute -I

  2. Użyj TCP syn do traceroute : $ sudo traceroute -T

  3. Jeśli jest to hops, który przekracza, a następnie użyć jednego z następujących: $ sudo traceroute -I -m 60

LUB

$ sudo traceroute -T -m 60

Ten ostatni działał dla mnie podczas traceroute do ftp przez kontynent.
Źródło
0
0
0
2014-03-09 21:29:44 +0000

Aby użyć polecenia ping do traceroute w środowisku unixowym, spróbuj następująco: 

for ((TTL=1;TTL<30;TTL++));
do
ping -c 1 -t $TTL <IP>;
done
Źródło