Dlaczego mogę pingować adres IP, ale nie „śledzić go”?

Mogę pingować adres IP, ale nie mogę go śledzić. Jak to może być?

[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 CENSOREDadres IP w traceroute nie jest taki sam jak w „ping CENSORED.CENSORED”.

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

Na przykład zauważ różnicę między ICMP a 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 opiera się na pakietach ICMP lub UDP. Skutecznie pinguje każdy router na ścieżce między tobą a cenzurą. Cenzura. Zwiększa czas wygaśnięcia (TTL) dla każdego kolejnego wysyłanego pakietu (zwykle od 1 do 30), oczekując, że ponieważ każdy pakiet zostanie wysłany ze zwiększonym czasem TTL od ostatniego, następny router na ścieżce zwróci kod błędu .

Jeśli przeskok 6 nie odpowiada, prawdopodobnie blokuje wiadomości ICMP / UDP. Ping działa więc, ponieważ routery między tobą a nim przesyłają do niego pakiety ICMP / UDP, zamiast na nie odpowiadać, jak to robi w przypadku traceroute.

Nie widziałem odpowiedzi na pytanie, dlaczego część pytań.

Znanych jest kilku dostawców usług internetowych, którzy ukrywają swoje routery na traceroute na dwa sposoby: albo nie zmniejszają TTL w pakietach IP (robiąc się tunelami czasoprzestrzennymi IP), albo nie reagują na wygasłe TTL podczas przesyłania dalej ICMP.

Powodem jest utrzymanie prywatnej topologii sieci wewnętrznej. To wszystko.

Wydawanie traceroutes z / do wielu źródeł / miejsc docelowych ujawnia informacje o topologii sieci, co jest czymś, czego nie wszyscy doceniają.

Traceroute polega na komunikatach ICMP, na które niektóre routery mogą być skonfigurowane tak, aby nie odpowiadały.

Czasami warto użyć, pingaby 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 polecenie ping z argumentem -t $ TTL, można czasem wymknąć się zaporze ogniowej i znaleźć adresy IP itp. Routerów za zaporami ogniowymi.

Albo wszystkie węzły od 6 nie reagują na pakiety UDP, albo sam węzeł 6 blokuje pakiety udp. Możesz wypróbować metody fllowing, które, mam nadzieję, zadziałają w zależności od tego, który węzeł na ścieżce do bloków detekcji 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 to chmiel przekracza, użyj jednej z następujących opcji: $ sudo traceroute -I -m 60

LUB

$ sudo traceroute -T -m 60

Ten ostatni działał dla mnie podczas śledzenia trasy do ftp na całym kontynencie.

Aby użyć polecenia ping do traceroute w środowisku unix, spróbuj tego:

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