通过linux路由表Ping不起作用[OR]怎么期望?

Deven Bansod:

简短的长问题:

中国平安在r1-r4-r2道路工程,并使用10.0.1.*10.0.2.*IP地址,但如果我们改变路径,以失败r1-r3-r2使用1.0.0.*1.0.1.*IP地址完全相同的数据包(除了一个事实,即包srcdstIP字段从改变10.*1.*,反之亦然,在s1s2分别)。为什么?


详细问题:

我有一个小的拓扑如下

 h1 -- s1 -- r1 -- r4 -- r2 -- s2 -- h2
              \         /
               \       /
                \     /
                  r3

s的是OpenvSwitch情况下,同时r的是Ubuntu的16台Linux机器。

IP地址是:

h1-eth0 - 10.0.1.10/24
s1      - 10.0.1.50/24
h2-eth0 - 10.0.2.10/24
s2      - 10.0.2.50/24
r1-eth0 - 10.0.1.1/24
r1-eth1 - 10.0.11.2/24
r1-eth2 - 10.0.12.2/24
r2-eth0 - 10.0.2.1/24
r2-eth1 - 10.0.13.1/24
r2-eth2 - 10.0.5.1/24
r3-eth0 - 10.0.12.1/24
r3-eth1 - 10.0.5.2/24
r4-eth0 - 10.0.11.1/24
r4-eth1 - 10.0.13.2/24

如您所见,r1和r2之间有两条相似的路径。我添加以下静态条目。

11

sudo ip route add 10.0.2.0/24 via 10.0.11.1

22

sudo ip route add 10.0.1.0/24 via 10.0.13.2

44

sudo ip route add 10.0.1.0/24 via 10.0.11.2
sudo ip route add 10.0.2.0/24 via 10.0.13.1

h1和h2之间的ping正常工作。现在,由于这些交换机是OVS(因此启用了OpenFlow),因此我在s1中安装了条目,以将目标IP映射到其他子网

例如,当在s1接收到这样的数据包时,IP 10.0.1.10将被映射到1.0.0.10,而IP 10.0.2.10将被映射到1.0.1.10,而目标IP将在s2被映射回原始。

(我检查了这些条目的确正确,并且按预期工作。此外,我仅添加了此条目以匹配ICMP数据包)。当h1发送ping答复时,将执行类似的过程。

伴随着这些,我在路由器中安装了静态路由来路由这些IP。

11

sudo ip route add 1.0.0.0/24 via 10.0.1.50
sudo ip route add 1.0.1.0/24 via 10.0.12.1

22

sudo ip route add 1.0.0.0/24 via 10.0.5.2
sudo ip route add 1.0.1.0/24 via 10.0.2.50

33

sudo ip route add 1.0.0.0/24 via 10.0.12.2
sudo ip route add 1.0.1.0/24 via 10.0.5.1

现在,如果我从h2 ping h1,则该数据包将从目标IP 10.0.1.10开始,该IP地址在s2映射到1.0.0.10,r2将其路由并发送到r3,r3将其路由并发送到r1。但是,即使在一个接口上接收到数据包并且在Linux路由表中具有匹配条目之后,r1也不会路由和转发数据包。

甚至ip route get输出应将数据包转发到的正确端口。也没有防火墙条目ip tables


一些其他信息:

  • 如果我更改了新添加的路由条目以使用的原始路径r1-r4-r2(即,我们使用映射的ip在该路径上进行路由),则其行为将与预期一致,而ping将按预期进行。

  • 或者,如果我将r1中的10.0.2.0/24和
    r2中的10.0.1.0/24的旧路由条目更改(现在理想情况下甚至不必与新数据包匹配,因为它们的目标IP在1.0.0中) 。* range或仅1.0.1。*)以r1-r3-r4与该映射IP数据包一起使用新路径,r2和r1之间的ping正常工作。

可能需要的详细信息:

最终的路由表如下:

11

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.11.1       0.0.0.0         UG    0      0        0 eth1
1.0.0.0         10.0.1.10       255.255.255.0   UG    0      0        0 eth0
1.0.1.0         10.0.12.1       255.255.255.0   UG    0      0        0 eth2
10.0.1.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.0.2.0        10.0.11.1       255.255.255.0   UG    0      0        0 eth1
10.0.11.0       0.0.0.0         255.255.255.0   U     1      0        0 eth1
10.0.12.0       0.0.0.0         255.255.255.0   U     1      0        0 eth2

22

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.13.2       0.0.0.0         UG    0      0        0 eth1
1.0.0.0         10.0.5.2        255.255.255.0   UG    0      0        0 eth1
1.0.1.0         10.0.2.50       255.255.255.0   UG    0      0        0 eth0
10.0.1.0        10.0.13.2       255.255.255.0   UG    0      0        0 eth1
10.0.2.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.0.5.0        0.0.0.0         255.255.255.0   U     1      0        0 eth2
10.0.13.0       0.0.0.0         255.255.255.0   U     1      0        0 eth1

33

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.5.1        0.0.0.0         UG    0      0        0 eth1
1.0.0.0         10.0.12.2       255.255.255.0   UG    0      0        0 eth0
1.0.1.0         10.0.5.1        255.255.255.0   UG    0      0        0 eth1
10.0.1.0        10.0.12.2       255.255.255.0   UG    0      0        0 eth0
10.0.2.0        10.0.5.1        255.255.255.0   U     1      0       0 eth1
10.0.5.0        0.0.0.0         255.255.255.0   U     1      0        0 eth1
10.0.12.0       0.0.0.0         255.255.255.0   U     1      0        0 eth0

44

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth4
1.0.0.0         10.0.11.2       255.255.255.0   UG    0      0        0 eth0
1.0.1.0         10.0.13.1       255.255.255.0   UG    0      0        0 eth1
10.0.1.0        10.0.11.2       255.255.255.0   UG    0      0        0 eth0
10.0.2.0        10.0.13.1       255.255.255.0   UG    0      0        0 eth1
10.0.11.0       0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.0.13.0       0.0.0.0         255.255.255.0   U     1      0        0 eth1
192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth4

注意:192.168.0。*是连接到外部Internet的子网。

您认为是什么问题?我完全困惑于这个问题。

Deven Bansod:

Linux路由的行为符合预期。

反向路径过滤器的标志,
/proc/sys/net/ipv4/conf/<interfacename>/rp_filter默认情况下已打开(通过将值设置为1)。

反向路径过滤器是Linux内核的一项安全功能。一个常见的例子是逃避到Internet上的私有IP空间。如果您的接口的路由为195.96.96.0/24,则不要期望来自212.64.94.1的数据包到达该接口。因此,如果将该标志设置为1,内核将丢弃此类数据包。

更正式地说,

反向路径过滤是Linux内核采用的一种机制,用于检查接收到的数据包的源IP地址是否可路由。

因此,换句话说,当启用了反向路径筛选的计算机接收到数据包时,该计算机将首先检查接收到的数据包的源是否可以通过其进入的接口到达。

  • 如果可以通过它所到达的接口进行路由,则计算机将接受该数据包。
  • 如果无法通过它来的接口进行路由,则计算机将丢弃该数据包。

最新的内核还提供了一个值为2的选项。在接受流量方面,该选项更为宽松。

如果接收到的数据包的源地址可通过计算机上的任何接口路由,则计算机将接受该数据包。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章