☰

数据包返回但跟踪路由失败

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..

但在另一个终端我可以看到来自目标主机的正确回复（端口不可达）：

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 跟踪（显然使用不同的源 IP） - 但 traceroute 命令会成功。

我不明白为什么 wireshark 可以看到回复但是 traceroute 在第二个 NIC 上失败了。

我想我在这里遗漏了一些非常基本的东西......

答案1

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

有一些事情可能出错，导致内核决定不传递这些数据包。

  • 您可能有一个不适合反向路径过滤的不对称路由，但仍保持rp_filter启用状态。
  • 内核可能无法将 ICMP 错误消息的内容与本地套接字进行匹配。这可能是因为数据包被截断，没有足够的信息来做出这样的决定。这也可能是由于某些损坏的 NAT 配置导致数据包在一个方向上通过 NAT 路由，而在另一个方向上则不会。
  • 由于校验和错误，内核可能会丢弃数据包。

其中，我认为rp_filter听起来最有可能。您没有指定操作系统，但看起来可能是 Linux 系统，因此请尝试以下命令：head /proc/sys/net/ipv4/conf/*/rp_filter。您可能会1在每个命令上看到 ，这意味着过滤器已启用。尝试将 写入0与丢弃数据包的接口对应的设备名称以及all设备名称。

答案2

您可以在此处发布每个框的路由表输出吗？如果您的默认路由无效/缺失，则数据包将没有返回路径。请发布以下输出：

# IP 路由列表

在每个 Linux 机器上。

相关内容