我相信我已经实现了将数据包从eth1 / 192.168.3.x到192.168.3.1 ，以及从eth0 / 192.168.1.x到192.168.1.1 （ 有用的源 ）的数据包路由到一个表。
问题 ：从192.168.3.20（从vserver内部）做tracepath时，我得到kernel: [318535.927489] martian source 192.168.3.20 from 212.47.223.33, on dev eth0在或接近目标IP，而中间kernel: [318535.927489] martian source 192.168.3.20 from 212.47.223.33, on dev eth0没有下面的日志）。
我不明白为什么这个数据包到达eth0而不是eth1， 即使读了这个 ：
请注意，在运行traceroute或tracepath命令时，您可能会看到来自不可路由的IP地址的数据包。 虽然数据包不能路由到这些路由器，但在两个路由器之间发送的数据包只需要知道本地networking内下一跳的地址，这可能是一个不可路由的地址。
有人能用人类语言来解释那段吗？ 基于迄今为止的短暂初步试验，其他一切似乎都不会造成火星人的工作。 这是否包含tracepath操作的本质，还是我还有其他更大的路由问题会导致工作stream量中断？
附注：是否有可能用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
额外的背景
非虚拟化networking接口隔离选项？
如果你收到火星包，wireshark应该能够显示它。
我也看到你已经通过设置127.0.0.0/8的不可达路由来禁用环回。 这不符合标准，可能没有什么用处，但我怀疑这个问题有多大关系。
文档段落仅仅意味着你很可能会在跟踪路由中看到RFC1918地址或其他不可达的东西，因为这些地址在许多情况下可以在路由器之间使用（例如，在一个AS内），但是当路由器数据包在那里超过了TTL。 这并不意味着你应该期待火星人。 我也怀疑这与这个特定的数据包有什么关系。
火星包可能与traceroute无关。 但是，可能。 这通常是由于某个网关没有进行源NAT操作而造成的，但是也有可能是由于某个地方的NAT数据包的目的地址从eth1出站到eth0的IP地址而导致NAT规则失效。 这似乎最有可能给予数据包的来源。 这也可能意味着你忘记在你的网关上对你的出站数据包做源NAT。
您应该在eth1和eth0上运行wireshark捕获，并尝试在eth0中查找数据包，并查看是否可以将其与eth1中的数据库相关联。 还要检查你的NAT规则。
我相信“问题”是两个接口都连接到同一个networking。 在某些时候，你会在eth0接口上获取源IP为192.168.3.20的数据包，导致log_martiansconfiguration条目进入actino。
我很确定你已经启用了rp_filter，如果你禁用了它（例如/ proc / sys / net / ipv4 / conf / all / rp_filter），它将会消失，但是请阅读下面的内容：
这可能是由于两个原因：
有多种方法来解决这个问题，是的你可以tcpdump（例如tcpdump -ni eth0'主机192.168.3.20'）。
我可以回答你的中间问题。 我有一个/ 29从哪个路由每个/ 32独立：
ip route add 8.4.3.3/32 via 192.168.17.33.
这样，我可以使用所有八/ 32而不是丢失一个广播地址，另一个用于该子网上的路由器接口。
至于错误的界面; 你能显示你的NAT规则吗？ 感谢会是：
iptables -vnL -t nat