问题：当从192.168.3.20(从vserver内部)执行tracepath时,我得到内核：[318535.927489]火星源192.168.3.20,来自212.47.223.33,在目标IP或其附近的dev eth0,而中间跃点没有(记录下面).
我不明白为什么这个数据包到达eth0而不是eth1,even after reading this：
请注意,在运行traceroute或tracepath命令时,您可能会看到来自不可路由IP地址的数据包.虽然数据包不能路由到这些路由器,但是在两个路由器之间发送的数据包只需要知道本地网络中下一跳的地址,这可能是一个不可路由的地址.
有人可以用人类语言解释那段吗？基于迄今为止的短暂初步试验,其他一切似乎都能在不引起火星人的情况下发挥作这是否包含在tracepath操作的性质中,还是有其他更大的路由问题会导致工作流量中断？
旁注：是否可以使用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,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,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
附加背景
解决方法
我还看到你通过设置127.0.0.0/8的无法访问路由来禁用环回.这不符合标准,可能没那么有用,但我怀疑它与这个问题有很大关系.
文档段落只是意味着您可能会在traceroute中看到RFC1918地址或其他无法访问的内容,因为在许多情况下(例如,在一个AS内)这些地址可以在路由器之间使用,但是将是路由器在数据包超过了它的TTL.这并不意味着你应该期待火星人.我也怀疑它与这个特定的数据包有什么关系.
火星包可能与traceroute无关.但是,它可能.它通常是由一个网关在它应该的时候没有做源nat引起的,但是你也可能在某个地方有一个破坏的NAT规则,它将从eth1出站的数据包的目的地址转换为eth0的IP.这似乎很可能是给出了数据包的来源.这也可能意味着您忘记在您的网关上对您的出站数据包执行源NAT.
您应该在eth1和eth0上运行wireshark捕获,并尝试在eth0中找到该数据包,看看是否可以将其与eth1中的数据包相关联.还要检查NAT规则.
