返回的包但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..

但在另一个terminal中，我可以看到从目标主机到达的正确答复（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)

起初我以为这是一个防火墙的问题，但我检查，没有数据包被丢弃。唯一想到的是这是第二个NIC …

如果我运行traceroute到第一个网卡上的同一个主机，我会得到与上面相同的wireshark trace（显然是使用不同的源IP） – 但traceroute命令成功。

我不明白wireshark如何看到答复，但第二个网卡上的traceroute失败。

我想我错过了这里很基本的东西….

Wireshark将显示networking接口上的内容。内核显然看到了这些数据包，但由于某种原因，决定不将它们传递给traceroute命令。

有几件事可能会导致内核决定不交付这些数据包。

你可能有一个不对称的路由，不适合反向path过滤，但已经启用了rp_filter 。
内核可能无法将ICMP错误消息的内容与本地套接字相匹配。这可能是由于数据包被截断，没有足够的信息来作出这样的决定。这也可能由于一些破坏的NATconfiguration而发生，其中一个方向的数据包通过NAT路由，而另一个方向则不通过。
内核可能由于错误校验和而丢弃数据包。

在那些我认为rp_filter听起来像最可能的解释。你没有指定操作系统，但它看起来可能是一个Linux系统，所以试试这个命令： head /proc/sys/net/ipv4/conf/*/rp_filter 。你可能会看到每一个1 ，这意味着filter启用。尝试写一个0到相应的数据包被丢弃的接口以及all设备名称。

你可以在这里发布每个盒子的路由表的输出吗？如果您有一个无效/缺less默认路由，数据包将不具有返回path。请张贴以下的输出：

＃ip路由列表

在每个Linux机器上。