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

Question

В 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),

Как получается, что внутренний пинг для tracert каким-то образом работает иначе, чем реальный пинг? Насколько они разные? Что мне нужно сделать, чтобы ping работал как tracert?

Answer 1

Все это связано с тем, как работает tracert. Ping - это прямой ICMP из точки A в точку B, который пересекает сети с помощью правил маршрутизации. Tracert работает совсем по-другому, хотя и использует ICMP.

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

Подробнее об этом вы можете прочитать здесь.

Answer 2

Прежде всего две ваши команды отправляют пакеты с разными 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 для пакета, адресованного кому-то другому

Выбор молча отбрасывать пакеты только в одном из трех случаев, очевидно, приведет к поломке многих инструментов диагностики сети, которые, тем не менее, не мешают некоторым системным администраторам делать это в любом случае.

Answer 3

Поскольку безопасность в сети неуклонно возрастает, одной простой вещью, которую сейчас делают многие, является в основном отключение аспектов протокола ICMP. Это предотвращает ответ на traceroutes и возврат полного доменного имени из прыжка. Иногда администраторы блокируют работу, даже если пинг не работает. Это решение администратора системы.

Также существует вероятность того, что система обрабатывает большую сетевую нагрузку, поскольку ICMP обычно имеет низкий приоритет при обработке по сравнению с реальными данными.