Я можу відстежити IP-адресу, але не пінг

У Windows, якщо я відстежую Google, я отримую таке;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Тепер, якщо я запитую третю останню IP-адресу 66.249.95.234, я отримую це ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Як це так, що внутрішній "пінг" для відстеження якось працює інакше, ніж реальний пінг? Чим вони відрізняються? Що мені потрібно зробити, щоб пінг працював як trackrt?

Це все пов'язано з тим, як працює tracert. Ping - це прямий ICMP від ​​точки A до точки B, яка обходить мережі за допомогою правил маршрутизації. Tracert працює дуже по-різному, навіть якщо він використовує ICMP.

Tracert працює, орієнтуючись на остаточний перехід, але обмежуючи TTL та очікуючи на час, який перевищив повідомлення, а потім збільшує його на одиницю для наступної ітерації. Тому відповідь, яку вона отримує, - це не відповідь відлуння ICMP на запит ехо від ICMP від ​​хоста по дорозі, а повідомлення, яке перевищило час від цього хоста - тому, хоча він використовує ICMP, він використовує його зовсім по-іншому .

Детальніше про це ви можете прочитати тут .

Перш за все ваші дві команди надсилають пакети з різними цільовими IP-адресами. Це означає, що вони можуть приймати різні маршрути.

Коли ви бачите 66.249.95.234на маршруті до 216.58.220.100, ви можете припустити, що пакети з адресою призначення 66.249.95.234будуть використовувати той самий маршрут до досягнення цієї точки. Однак це не є припустимим припущенням.

Цілком справедливо, щоб маршрут 66.249.95.234був довшим, ніж маршрут до 216.58.220.100. Іноді навіть трапляється, що немає маршруту, який міг би доставити ваші пакети до проміжного маршрутизатора, але це не була б добре спроектована мережа, якби це було так.

Я не знаю, чи команди tracertта pingкоманди, які ви використовуєте, використовуєте один і той же протокол. Більшість реалізацій ping використовують пакети ехо-запитів ICMP. Однак реалізація traceroute існує, підтримуючи широкий спектр протоколів, включаючи ICMP ехо-запит, TCP SYN та UDP пакети. Якщо ці два випадки використовують різні протоколи, це може стати фактором, що бачить різні результати.

Нарешті, навіть якщо всі пакети мали би досягти 66.249.95.234, можливо, 66.249.95.234він поводитиметься дико по-різному, залежно від того, чи потрібно:

• Переслати пакет
• Створити помилку ICMP на пакеті, адресованому собі
• Створити помилку ICMP на пакеті, адресованому комусь іншому

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

Оскільки безпека в мережі постійно зростає, одна легка річ, яку зараз роблять багато людей, - це в основному відключити аспекти протоколу ICMP. Це запобігає реагуванню на трасування і повернення FQDN від стрибка. Іноді адміністратори блокують такі речі, що навіть пінг не працює. Це рішення адміністратора залученої системи.

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