
Я получаю такой вывод от 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.