Назад | Перейти на главную страницу

Пакеты возвращаются, но traceroute не работает

Я получаю этот вывод от 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 на тот же хост на первом сетевом адаптере, я получаю ту же трассировку wirehark, что и выше (очевидно, с другим IP-адресом источника), но команда traceroute выполняется успешно.

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

Думаю, мне здесь не хватает чего-то очень простого ....

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

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

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

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

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

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

на каждом ящике Linux.