Я могу проследить до 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),

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

Все это связано с тем, как работает 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. Это предотвращает ответ на traceroutes и возврат полного доменного имени из прыжка. Иногда администраторы блокируют все, что даже пинг не работает. Это решение администратора системы.

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