linux – 在tracepath期间导致火星数据包(目前为止)的路由策略有多么破碎？

我相信我已经实现了一个表,用于将数据包从eth1 / 192.168.3.x路由到192.168.3.1,以及从eth0 / 192.168.1.x到192.168.1.1( helpful source)的数据包.

问题：当从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

附加背景

Options for non-virtualized network interface isolation?

解决方法

如果你收到火星包,wireshark应该能够显示它.

我还看到你通过设置127.0.0.0/8的无法访问路由来禁用环回.这不符合标准,可能没那么有用,但我怀疑它与这个问题有很大关系.

文档段落只是意味着您可能会在traceroute中看到RFC1918地址或其他无法访问的内容,因为在许多情况下(例如,在一个AS内)这些地址可以在路由器之间使用,但是将是路由器在数据包超过了它的TTL.这并不意味着你应该期待火星人.我也怀疑它与这个特定的数据包有什么关系.

火星包可能与traceroute无关.但是,它可能.它通常是由一个网关在它应该的时候没有做源nat引起的,但是你也可能在某个地方有一个破坏的NAT规则,它将从eth1出站的数据包的目的地址转换为eth0的IP.这似乎很可能是给出了数据包的来源.这也可能意味着您忘记在您的网关上对您的出站数据包执行源NAT.

您应该在eth1和eth0上运行wireshark捕获,并尝试在eth0中找到该数据包,看看是否可以将其与eth1中的数据包相关联.还要检查NAT规则.

linux – 在tracepath期间导致火星数据包(目前为止)的路由策略有多么破碎？

解决方法

相关推荐