Чому я можу пінг IP-адреси, але не "простежувати" її?

Я можу пінг IP-адреси, але не можу простежити її. Як це могло бути?

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

П'ята CENSOREDIP-адреса у traceroute не така, як у "ping CENSORED.CENSORED".

Спробуйте використовувати інший метод у вашій послідовній послідовності, наприклад, TCP SYN або ICMP замість методу UDP за замовчуванням.

Наприклад, зверніть увагу на різницю між ICMP та 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 базується на пакетах ICMP або UDP. Він ефективно записує кожен маршрутизатор на шлях між вами та censored.censored. Він збільшує час роботи (TTL) для кожного наступного пакету, який він надсилає (з 1 по 30 нормально), очікуючи, що як кожен пакет буде відправлений із збільшеним TTL від останнього, наступний маршрутизатор у шляху поверне код помилки .

Якщо hop 6 не відповідає, це, ймовірно, блокує ICMP / UDP-повідомлення. Отже, Ping працює, тому що маршрутизатори між вами та ним просто передають пакети ICMP / UDP до нього, а не відповідають на них, як це роблять з кадровим кодом.

Я не побачив відповіді на те, чому частина питань.

Відомо, що декілька провайдерів примушують своїх маршрутизаторів приховати відстежувати двома способами: вони або не декрементують TTL в IP-пакетах (роблячи себе червоточиками IP), або не реагують на термін дії TTL з минулим терміном, продовжуючи пересилати ICMP.

Причиною є збереження приватної топології внутрішньої мережі. Це все.

Випуск traceroutes / з кількох джерел / пункту призначення виявляє інформацію про топологію мережі, яку не так цінують не всі.

Traceroute покладається на повідомлення ICMP, на які деякі маршрутизатори можуть бути налаштовані так, щоб не відповідати.

Іноді варто скористатися, pingщоб отримати інформацію, схожу на прослідкування:

#!/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

Викликаючи ping за допомогою аргументу -t $ TTL, ви можете іноді уникати брандмауера та знаходити IP-адреси та інше маршрутизатори за брандмауерами.

Або всі кивані від 6 далі не відповідають UDP-пакетам, або вузол 6 сам блокує udp-пакети. Ви можете спробувати способи пропускання, які, я сподіваюся, будуть працювати на основі того, який вузол на шляху до блокування дезінфекції блокує ICMP / TCP SYN:

1. Використовуйте ICMP для відстеження: $ sudo traceroute -I

2. Використовуйте TCP syn для traceroute: $ sudo traceroute -T

3. Якщо це хміль, якого він перевищує, то скористайтеся одним із наступних: $ sudo traceroute -I -m 60

АБО

$ sudo traceroute -T -m 60

Останній працював на мене під час проходження маршруту на ftp через континент.

Для використання команди ping для відстеження в unix середовищі, спробуйте це:

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