通过linux路由表的Ping不工作[或]这是怎么期望的？

Question

长篇大论的问题：

r1-r4-r2路径上的Ping使用10.0.1.*或10.0.2.* IP地址工作，但如果对完全相同的数据包使用1.0.0.*或1.0.1.* IP地址将路径更改为r1-r3-r2 (除了数据包的src字段和dst IP字段分别从10.*更改为1.*，反之亦然)，则失败。为什么？

详细问题：

我有一个小拓扑，如下所示

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

s是OpenvSwitch实例，r是Ubuntu16Linux机器。

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映射到不同的子网。

也就是说，IP 10.0.1.10将映射到1.0.0.10，而IP 10.0.2.10将映射到1.0.1.10，而目的地IP将被映射回s2的原始IP。

(我已核实这些项目确实是正确的，并如预期般运作。另外，我添加这个条目只是为了匹配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

现在，如果我从h1从h2开始，数据包以目标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.1.0/24在r2 (理想情况下甚至不需要被新数据包匹配，因为它们的目标IP在1.0.0.*范围或1.0.1.*仅)使用新路径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空间转义到Internet上。如果您的接口的路由为195.96.96.0/24，则不会期望212.64.94.1中的数据包到达那里。因此，如果标记设置为1，内核就会丢弃这样的数据包。

更正式一点，

反向路径过滤是Linux内核采用的一种机制，用于检查接收到的数据包的源IP地址是否可路由。 因此，换句话说，当启用反向路径过滤的机器接收到数据包时，机器将首先检查接收到的数据包的源是否可以通过它进入的接口到达。

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

最新的内核提供了一个更多的2的选项值，这个选项在接受流量方面稍微自由一些。

如果接收到的数据包的源地址可以通过机器上的任何接口进行路由，机器将接受该数据包。

Answer 2

要使其工作，请在所有机器上使用这个：

# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
>  echo 0 > $i 
> done

或在/etc/sysctl.conf中输入以下条目

net.ipv4.conf.all.rp_filter = 0

rp_filter将在三种模式下过滤数据包:0禁用，1严格和2松散。

示例

Client A - 192.168.2.10 - connected to router via eth0

Router
   eth0   - 192.168.2.150
    routes - 192.168.2.0/24
   eth1   - 10.42.43.1
    routes - 10.42.43.0/24

注意:没有默认路由

Client C - 10.42.43.50 - connected to router via eth1

在此设置下，路由器上的rp_filter设置为“松散模式”(2)，eth0上的数据包从1.2.3.4到10.42.43.50将被阻塞。

当路由器上的rp_filter设置为“严格模式”(1)时，来自源地址10.42.43.2的eth0上的数据包将被阻塞。

当设置为“禁用”(0)时，两个数据包都会通过。

Answer 3

首先，您的拓扑细节是不完整的，您缺少了r3和r4详细信息，但是可以推断它们。

我将尝试解释需要发生什么，而不是试图解决您的问题。但是，如果您只是使用OSPF这样的路由协议，它就会容易得多，这样您就不必手工操作了。

如果要访问每个正在路由的设备，则需要知道如何访问其他每个子网。因此，这意味着您可以添加默认路由(即匹配0.0.0.0/0的路由)，也可以在每个子网中输入相应的next-ip到每个路由器(见下文)。通常，您不需要为已连接的子网添加路由(在该子网中的那个路由器上有一个ip )。

R1路由

10.0.13.0/24 -> 10.0.11.1
10.0.5.0/24 -> 10.0.11.1
10.0.2.0/24 -> 10.0.11.1

R2路由

10.0.1.0/24 -> 10.0.13.2
10.0.12.0/24 -> 10.0.13.2
10.0.11.0/24 -> 10.0.13.2

R3路由

10.0.1.0/24 -> 10.0.12.2
10.0.11.0/24 -> 10.0.12.2
10.0.13.0/24 -> 10.0.5.1
10.0.2.0/24 -> 10.0.5.1

R4路由

10.0.1.0/24 -> 10.0.11.2
10.0.12.0/24 -> 10.0.11.2
10.0.2.0/24 -> 10.0.13.1
10.0.5.0/24 -> 10.0.13.1

对于设备H1、S1、H2和S2，它们应该有一个指向网关10.0.1.1和10.0.2.1的默认路由。