☰

Ping не работает, но Wireshark обнаруживает ICMP-запрос и ответ

tag-icon • tag-icon ping wireshark
Ping не работает, но Wireshark обнаруживает ICMP-запрос и ответ

Я столкнулся со странной проблемой и был бы признателен, если бы кто-нибудь из вас мог добавить информацию.

Я настроил две разные подсети и в качестве теста. Я пытаюсь пинговать одну машину 10.10.11.9/30 (в одной подсети) с другой машины 10.10.11.1/30 (в другой подсети). Пинг не работает (и правильно).

Однако, когда я пытаюсь обнаружить то же самое в Wireshark, вместо сообщений "недоступно" он показывает нормальные запросы и ответы ICMP. Как будто пакеты находят свой путь...

Я прикрепил скриншот введите описание изображения здесь для ping, а также для Wireshark

Я попытался вычислить контрольную сумму заголовка в IP-пакетах, но даже после этого контрольные суммы пакетов, захваченных в Wireshark, кажутся правильными, в то время как ping показывает, что все пакеты потеряны.

Может ли кто-нибудь добавить информацию?

Большое спасибо

решение1

Предполагая, что ваша настройка действительно такая, как вы ее описываете (ничего случайно не настроено неправильно): если у клиента 10.10.11.1/30 нет информации о том, как маршрутизироваться на 10.10.11.9/30 (через шлюз по умолчанию, статические маршруты и т. д.), никакие пакеты ICMP отправляться не должны.

Попробуйте на Cisco Paket Tracer. Настройте сеть с двумя клиентами и одним коммутатором между ними. Пока не настроен шлюз по умолчанию (и клиенты находятся в разных широковещательных доменах), клиент даже не будет отправлять никаких ARP-пакетов.

Это означает, что ваша текущая конфигурация обеспечивает некое "разрешение маршрутизации", так что пакеты ICMP фактически отправляются и принимаются. Возможно, через шлюз по умолчанию, статический маршрут и т. д. Проверьте уровень 2, на какой MAC-адрес устанавливаются кадры? Напрямую клиенту или маршрутизатору? Как я написал в своем комментарии:

ICMP-пакет должен был быть отправлен через маршрутизатор, статический маршрут, какую-то «экзотическую» конфигурацию, например «proxy-arp» и т. д. Что происходит на уровне 2? Как IP-адрес преобразуется в MAC-адрес? Я думаю, это приведет вас к решению, почему вообще есть ответ (чего быть не должно).

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

Единственное другое объяснение, которое у меня есть, это то, что есть какая-то другая странная конфигурация, которая портит систему (например, второй клиент с тем же IP-адресом, что и у получателя, и в пределах широковещательного домена, что и у источника и т. д.). Вы можете проверить это и на уровне 2, сравнив MAC-адреса кадров с MAC-адресами реальных клиентов.

Запоздалая мысль: может ли быть, что вы настроили шлюз по умолчанию, статический маршрут и т. д.? имеет ли маршрутизатор, например, 24-битную сетевую маску? В этом случае, хотя подсеть отличается, широковещательные домены маршрутизатора и клиентов перекрываются. Это может объяснить текущее поведение.

решение2

Ваша сеть в плохом состоянии, вероятно, из-за путаницы в масках сетей:

  • Запросу ICMP предшествует предыдущий запрос ARP, немедленно или некоторое время до этого. Очевидно, запрос ARP был успешным, поэтому какой-то узел знал, где находится, 10.10.11.9 и вернул свой MAC-адрес, иначе ICMP никогда бы не был отправлен.

  • Запрос PING должен был вернуть "net unreachable" (или, по крайней мере, "host unreachable"), чего не произошло. Поэтому запрос ICMP был успешно отправлен и возвращен с кодом успеха.

Остается вопрос, почему команда ping все равно сообщила о 100% потере пакетов.

Я могу только предположить, что сама команда ping отклонила ответ, возможно, потому, что он пришел из другой сети.

Я пришел к выводу, что некоторые другие узлы в сети используют 10.10.11.x/24, поэтому отправляют ping-запросы, что вызывает большую путаницу для 10.10.11.1/30узла.

Связанный контент