我相信我已经实现了一个路由数据包的表从 eth1/192.168.3.x 到 192.168.3.1和数据包从 eth0/192.168.1.x 到 192.168.1.1（有用的来源）。
问题：当从 192.168.3.20（从虚拟服务器内部）执行跟踪路径时，我达到kernel: [318535.927489] martian source 192.168.3.20 from 212.47.223.33, on dev eth0或接近目标 IP，而中间跳跃没有到达（下面的日志）。
我不明白为什么这个数据包到达的是eth0，而不是eth1，即使读完这篇文章：
请注意，运行 traceroute 或 tracepath 命令时，您可能会看到来自不可路由 IP 地址的数据包。虽然数据包无法路由到这些路由器，但在两个路由器之间发送的数据包只需要知道本地网络中下一跳的地址，而该地址可能是不可路由的地址。
有人能用人类语言解释一下那段话吗？根据迄今为止的短暂初步试验，其他一切似乎都正常，没有造成火星人。这是否包含在跟踪路径操作的性质中，还是我还有其他更大的路由问题会导致工作流量中断？
附注：是否可以使用 tcpdump 或 wireshark 或类似程序检查火星数据包？我无法让它自己显示出来。
vserver-20 / # tracepath -n 212.47.223.33
1: 192.168.3.2 0.064ms pmtu 1500
1: 192.168.3.1 1.076ms
1: 192.168.3.1 1.259ms
2: 90.191.8.2 1.908ms
3: 90.190.134.194 2.595ms
4: 194.126.123.94 2.136ms asymm 5
5: 195.250.170.22 2.266ms asymm 6
6: 212.47.201.86 2.390ms asymm 7
7: no reply
8: no reply
9: no reply
^C
主机路由：
$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:24:1d:de:b3:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:46:46:a3:6a brd ff:ff:ff:ff:ff:ff
inet 192.168.3.2/27 scope global eth1
inet 192.168.3.20/27 brd 192.168.3.31 scope global secondary eth1 # linux-vserver instance
$ sudo ip route
default via 192.168.1.1 dev eth0 metric 3
unreachable 127.0.0.0/8 scope host
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
192.168.3.0/27 dev eth1 proto kernel scope link src 192.168.3.2
$ sudo ip rule
0: from all lookup local
32764: from all to 192.168.3.0/27 lookup dmz
32765: from 192.168.3.0/27 lookup dmz
32766: from all lookup main
32767: from all lookup default
$ sudo ip route show table dmz
default via 192.168.3.1 dev eth1 metric 4
192.168.3.0/27 dev eth1 scope link metric 4
网关路由
# ip route
10.24.0.2 dev tun0 proto kernel scope link src 10.24.0.1
10.24.0.0/24 via 10.24.0.2 dev tun0
192.168.3.0/24 dev br-dmz proto kernel scope link src 192.168.3.1
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
$ISP_NET/23 dev eth0.1 proto kernel scope link src $WAN_IP
default via $ISP_GW dev eth0.1
其他背景
答案1
如果您收到火星数据包，wireshark 应该能够显示它。
我还看到您通过为 127.0.0.0/8 设置不可访问路由来禁用环回。这不符合标准，而且可能没什么用，但我怀疑这与这个问题没有太大关系。
文档段落只是意味着您可能会在跟踪路由中看到 RFC1918 地址或其他无法访问的内容，因为这些地址在许多情况下可以在路由器之间使用（例如，在一个 AS 内），但当数据包超过其 TTL 时，路由器会给出这些地址。这并不意味着您应该期待火星人。我也怀疑它与这个特定的数据包有任何关系。
火星数据包可能与跟踪路由无关。但是，它可能与跟踪路由无关。这通常是由于网关没有在应该执行源 NAT 时执行源 NAT 造成的，但也可能是您在某个地方有一条损坏的 NAT 规则，该规则将从 eth1 出站的数据包的目标地址转换为 eth0 的 IP。考虑到数据包的来源，这似乎最有可能。这也可能意味着您忘记在网关上对出站数据包执行源 NAT。
您应该在 eth1 和 eth0 上都运行 wireshark 捕获，然后尝试在 eth0 中找到数据包，看看是否可以将其与 eth1 中的数据包关联起来。另外，请检查您的 NAT 规则。
答案2
我认为“问题”在于您的两个接口都连接到同一个网络。在某个时候，您会在 eth0 接口上收到源 IP 为 192.168.3.20 的数据包，这会导致 log_martians 配置条目出现在 actino 中。
我很确定你已经启用了 rp_filter，并且如果你禁用它（例如 /proc/sys/net/ipv4/conf/all/rp_filter），这个问题就会消失，但请阅读以下内容：
这可能有两个原因：
- 您从这个（即错误的）接口接收到来自您自己网络的合法数据包。理论上，对于您而言，子网 192.168.3.0/27 的所有数据包都应到达 eth1，除非您有多路径路由，在这种情况下您需要禁用 rp_filter。
- 在您的跟踪路径中，其中一个中间链路使用来自子网 192.168.3.0/27 的 IP 地址。即假设您和目的地之间的其中一个中间 ISP 在其路由器上使用来自该子网的 IP 地址。由于跟踪路由的工作方式，您将收到带有该源 IP 的 ICMP TTL EXCEEDED 数据包（因为路由器将发送它们）。并且由于您的默认路由是通过 eth0，因此内核会发出抱怨（因为它期望来自 192.168.3.0/27 的所有内容都到达 eth1 - 因为 rp_filter）。
有多种方法可以解决这个问题，是的，您可以在此使用 tcpdump（例如 tcpdump -ni eth0'host 192.168.3.20'）。
答案3
我可以回答你的中间问题。我有一个 /29，我可以从中独立路由每个 /32：
ip route add 8.4.3.3/32 via 192.168.17.33.
这样，我可以使用全部八个 /32，而不必丢失一个用于广播地址，另一个用于该子网上的路由器接口。
至于错误的接口；你能显示你的 NAT 规则吗？谢谢：
iptables -vnL -t nat