☰

Пакеты возвращаются, но трассировка не удалась

tag-icon • tag-icon wireshark networking
Пакеты возвращаются, но трассировка не удалась

Я получаю такой вывод от traceroute:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

Но в другом терминале я вижу правильные ответы (Port Unreachable), поступающие от целевого хоста:

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

Сначала я думал, что это проблема с брандмауэром, но я проверил, и пакеты не теряются. Единственное, что приходит на ум, это то, что это вторая сетевая карта...

Если я запускаю traceroute к тому же хосту на первой сетевой карте, я получаю ту же трассировку Wireshark, что и выше (очевидно, с другим исходным IP-адресом), но команда traceroute выполняется успешно.

Я не понимаю, как Wireshark видит ответы, но traceroute не работает на второй сетевой карте.

Мне кажется, я упускаю здесь что-то очень простое...

решение1

Wireshark покажет, что приходит на сетевой интерфейс. Ядро, очевидно, увидело эти пакеты, но по какой-то причине решило, что они не должны передаваться команде traceroute.

Есть несколько вещей, которые могли пойти не так, из-за чего ядро ​​решило не доставлять эти пакеты.

  • Возможно, у вас асимметричная маршрутизация, которая не подходит для фильтрации обратного пути, но вы оставили ее rp_filterвключенной.
  • Ядро может не сопоставить содержимое сообщения об ошибке ICMP с локальным сокетом. Это может произойти из-за того, что пакет был усечен с недостаточной информацией для принятия такого решения. Это также может произойти из-за какой-то сломанной конфигурации NAT, когда пакеты в одном направлении маршрутизируются через NAT, а в другом — нет.
  • Ядро может отбрасывать пакеты из-за неверной контрольной суммы.

Из них, я думаю, это rp_filterзвучит как наиболее вероятное объяснение. Вы не указали операционную систему, но похоже, что это может быть система Linux, поэтому попробуйте эту команду: head /proc/sys/net/ipv4/conf/*/rp_filter. Вы, вероятно, увидите 1на каждом из них, что означает, что фильтр включен. Попробуйте написать a 0в тот, который соответствует интерфейсу, с которого сбрасываются пакеты, а также в allимя устройства.

решение2

Можете ли вы разместить вывод таблицы маршрутизации каждого ящика здесь? Если у вас недействительный или отсутствующий маршрут по умолчанию, пакеты не будут иметь обратного пути. Пожалуйста, разместите вывод:

# список маршрутов IP

на каждой машине Linux.

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