ping通過linux路由表無法正常工作[OR]這是怎么預料到的？

Question

簡而言之：

Ping over r1-r4-r2路徑使用10.0.1.*或10.0.2.* IP地址工作，但如果我們使用1.0.0.*或1.0.1.*更改r1-r3-r2的路徑，則會失敗1.0.1.* IP完全相同的數據包的地址（除了數據包的src和dst IP字段從10.*變為1.* ，反之亦然，分別在s1和s2 ）。 為什么？

---

問題詳情：

我有一個小拓撲如下

 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之間有兩條相似的路徑。 我添加以下靜態條目。

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。*范圍或僅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進入每個路由器（見下文）。 通常您不需要為連接的子網添加路由（IE在該子網中的該路由器上有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的默認路由。