Почему я могу отследить этот IP-адрес, но не пинговать?

21

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

Вы видите, я могу трассировку 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

Но я не могу пинговать это

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

Если есть запрет на ICMP, tracerouteтоже не должно работать. В чем причина?

Я проверил, что брандмауэр сервера остановлен.

— 244boy
источник

может ли быть так, что время ожидания для ping слишком ограничено и было бы успешным, учитывая более мягкие ограничения по времени? Traceroute дал более 500 мс для некоторых узлов.

— вс

Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.

— Рон Мопин

39

На подобный вопрос здесь Люк Сэвидж объяснил это прекрасно:

Traceroute не сам протокол, это приложение, и используемые протоколы зависят от реализации, которую вы используете. В первую очередь это ICMP.

Есть две основные реализации:

tracert - tracert - это приложение для Windows, которое использует пакеты ICMP с увеличивающимся полем TTL для сопоставления прыжков с конечным адресом назначения.

traceroute - traceroute - это приложение * nix, доступное в большинстве систем на базе Linux, включая сетевые устройства и устройства Cisco. При этом используются UDP-пакеты с возрастающим полем TTL для сопоставления прыжков с конечным пунктом назначения.

Разницу между ними полезно знать, так как некоторые сети теперь блокируют ICMP по умолчанию, поэтому PING и tracert с компьютера с Windows не будут работать, но трассировка маршрута с устройства Linux все еще может работать.

— naïveRSA
источник

2

Итак, почему мой сервер IP может трассировать, но не пинговать?

— 244 мальчика

10

Из вашего общего вывода я вижу, что вы используете tracerouteкоманду, а не то, tracertчто заставило меня думать, что вы используете операционную систему на основе Unix или GNU. В ответе, который я упомянул, вы можете видеть, что системы на основе Unix не используются ICMPдля traceroute. Другими словами, поскольку PINGиспользование ICMP(которое, я думаю, заблокировано системой, к которой вы пытаетесь связаться), а traceroute использует UDPпакеты с методом увеличения TTLполя (которое, я думаю, не заблокировано в системе, к которой вы пытаетесь обратиться), PINGзавершается неудачно. но Tracerouteудается.

— naïveRSA

4

Вместо добавления нового комментария к вашему сообщению, когда кто-то вроде 244boy предлагает улучшение, было бы лучше отредактировать ваше сообщение так, чтобы будущие люди, читающие ответ, не читали все комментарии, чтобы получить полный ответ.

— Keeta - восстановить Монику

@ naïveRSA Строго говоря, tracerouteэто с помощью ICMP, даже если он посылает UDP, а именно он ожидает и оценивает TTL exceededсообщения от перелетов на пути. Хост, блокирующий все ICMP, является плохой идеей, но в pingлюбом случае он потерпит неудачу, когда ICMP echoзапросы или ответы будут заблокированы на целевом хосте

— Хаген фон Айцен

17

Чтобы добавить к ответу @ naïveRSA , если в пути есть фильтрация / межсетевой экран, может также возникнуть ситуация, когда ICMP-пакет «эхо-ответа» (ping) блокируется, но разрешен ICMP-пакет «превышено время» (tracert). , Это даст те же результаты, даже если используется только ICMP (Windows).

В обоих случаях (отправитель использует UDP или ICMP) сообщение об ошибке будет ICMP (т. Е. Узел, отвечающий на пакет ping или tracer *).

— Арьян
источник

6

Давайте посмотрим, что происходит, не так ли?

8.8.8.8 является хорошим примером, потому что, по крайней мере, из моего местоположения, я могу достичь его как с помощью, так tracerouteи ping.

Сначала давайте попробуем ping 8.8.8.8посмотреть, что происходит:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

Поэтому pingотправляет эхо-запрос ICMP и ожидает эхо-ответа ICMP.

Сейчас traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

Так что traceroute, по крайней мере, реализация, которую я установил, не отправляет ICMP. Скорее, он отправляет пакеты UDP.

Что не видно на этой трассировке (хотя было бы, если бы я дал tcpdumpa -vдля увеличения многословия), так это то, что первые пробники имеют значение ttl, равное 1, а затем оно увеличивает значение ttl для последующих проб. Это заставляет маршрутизаторы между мной и 8.8.8.8 отвечать сообщением об ошибке ICMP ttl превышено, и именно так traceroute обнаруживает маршрутизаторы между здесь и там.

В конце концов, ttl достаточно длинный, чтобы пройти весь путь до 8.8.8.8, и 8.8.8.8 отвечает с ошибкой недоступности порта ICMP, потому что у него нет процесса, прослушивающего UDP-порт 44838. Таким образом, traceroute знает, что достигло конечного пункта назначения ,

Если что-то между здесь и там блокирует все ICMP, то ни ping, ни traceroute работать не будут.

Но обычно это не тот случай, когда все ICMP блокируются, хотя это также не редкость. Блокировать все ICMP проблематично: например, он нарушает обнаружение MTU пути , которое основано на ошибке фрагментации ICMP. Пакеты ICMP имеют тип и код, и ответственные операторы сети будут только выборочно блокировать некоторые типы или коды, которые могут быть использованы для злоупотребления или разглашать конкретную информацию.

Например, некоторые хосты вообще не будут отвечать на эхо-запрос ICMP, и, следовательно, ping не будет работать. Идея состоит в том, что, не отвечая на эхо-запросы, злоумышленнику будет сложнее обнаружить, какие хосты существуют в сети. На практике это сомнительно, так как существуют другие способы поиска хоста. Например, можно отправить TCP SYN на порт 80, чтобы найти веб-серверы.

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

Поскольку traceroute - это программа, а не какой-либо конкретный протокол, у нее есть другие способы проверки. Все они полагаются на увеличение TTL для обнаружения маршрутизаторов, но могут быть отправлены различные типы проб, которые могут иметь больше или меньше шансов вызвать ответ от конечной точки. Например, в моих man tcpdumpсписках есть -Iвозможность использовать эхо-сигналы ICMP, такие же как ping. Также -Tнеобходимо использовать зонды TCP SYN вместо UDP. Если вы знаете, что хозяин ответит, pingтогда -Iимеет смысл. Если вы знаете, что хост прослушивает определенный порт TCP, это -Tимеет смысл, возможно, в сочетании с -pвозможностью выбора порта.

К сожалению, для этих опций могут потребоваться права root или специальные возможности, поэтому UDP делает справедливое значение по умолчанию. На самом деле похожий инструмент, tracepathимеет это сказать на своей странице руководства:

ОПИСАНИЕ

Он отслеживает путь к месту назначения, обнаруживая MTU по этому пути. Он использует порт UDP-порт или какой-то случайный порт. Он похож на traceroute, только не требует привилегий суперпользователя и не имеет причудливых опций.

— Фил Фрост
источник

2

TLDR; эхо-запросы могут быть заблокированы (блокировка ICMP) на удаленном хосте, но traceroute все еще может найти маршрут к нему, используя стандартную сетевую маршрутизацию UDP или TCP / IP (любой протокол на самом деле; ref /networkengineering//a/36509/ 58968 ). Обратите внимание, что ваш пинг может также достигать хоста (если, возможно, у вас нет очень умного брандмауэра, блокирующего где-то трафик ICMP-пинга), хост просто не отвечает.

— Роэль Ван де Паар
источник

0

Linux использует UDP вместо ICMP для traceroute, брандмауэр не блокирует этот порт UDP

— фаршад хазаи
источник

0

Вы можете установить nmap (insecure.org) и использовать nping с UDP или TCP и любым портом. Прекрасно работает в сетях с заблокированным исходящим пингом.

Пинговать веб-сервер nping --tcp -p 80,443

Пинговать сервер времени nping --udp -p 123

https://nmap.org/book/nping-man.html

— Майкл Хаббард
источник

0

Краткий ответ на ваш вопрос заключается в том, что pingутилита использует протокол ICMP, который иногда блокируется сетевым брандмауэром или брандмауэром на самом устройстве. Наиболее распространенная причина, по которой сетевые администраторы блокируют ICMP, состоит в том, чтобы предотвратить «сканирование» сети, которое они считают проблемой безопасности. tracerouteУтилита на Linux использует UDP, совершенно другой протокол, который в данном случае не блокированных сетевых администраторов. UDP имеет множество применений, и его блокировка может привести к невозможности использования многих вещей в сети. Тип «управляющего сообщения» ICMP, необходимый для этого, pingявляется подмножеством протокола, что означает, что блокировка этого типа пакета ICMP вызывает меньше проблем в сети и, следовательно, с большей вероятностью будет заблокирована, чем UDP.

— Cybernaut
источник