ping通过linux路由表无法正常工作[OR]这是怎么预料到的？

Question

简而言之:

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

---

问题详情:

我有一个小拓扑如下

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

这s是OpenvSwitch实例,而rUbuntu 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之间有两条相似的路径.我添加以下静态条目.

R1

sudo ip route add 10.0.2.0/24 via 10.0.11.1

R2

sudo ip route add 10.0.1.0/24 via 10.0.13.2

R4

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.

R1

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

R2

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

R3

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开始,在s2映射到1.0.0.10,r2路由此并将其发送到r3,r3将其路由并发送到r1.但是r1,即使在一个接口上接收到数据包并且在Linux路由表中具有匹配条目之后也不会路由和转发数据包.

甚至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.*only)使用新路径r1-r3-r4和此映射IP数据包,r2和r1之间的ping工作正常.

可能需要的详细信息:

最终的路由表如下:

R1

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

R2

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

R3

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

R4

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的子网.

您认为这个问题是什么？我完全不知道看着这个问题.

Answer 1

Linux 路由的行为与预期一致。

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

反向路径过滤器是作为 Linux 内核的一项安全功能提供的。一个常见的例子是私有 IP 空间逃逸到互联网上。如果您有一个接口，其路由为 195.96.96.0/24，则您不希望来自 212.64.94.1 的数据包到达该接口。因此，如果该标志设置为 1，内核就会丢弃这样的数据包。

更正式地说，

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

换句话说，当启用反向路径过滤的机器收到数据包时，该机器将首先检查接收到的数据包的来源是否可以通过其传入的接口到达。

• 如果它可以通过它所到达的接口进行路由，那么机器将接受该数据包。
• 如果它无法通过它所到达的接口进行路由，那么机器将丢弃该数据包。

最新的内核又提供了一个选项值 2。该选项在接受流量方面稍微宽松一些。

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