由于業務需要，我們在海外的某些節點上搭建了VPN，方便海外節點之間的數據交互，某天我們在兩個新節點之間搭建了一條新的VPN，上線之后Ping、traceroute測試無異常，觀察已經有流量通過，監控指標等一切正常。但是過了半個小時后，業務反饋兩個新節點之間網絡不通，發現問題后緊急上線回退了配置。然后事后線下回測，發現通過重啟IPsec 進程，能重現時通時不通的現象。

接下來重現復盤一下當時的配置和場景，以及解釋該問題的根因。

如上所示，A/B兩個節點通過IPsec打通，A側的網段為10.0.0.0/24，B側的網段為10.0.1.0/24與10.0.2.0/24。A側將去往10.0.1.0/24與10.0.2.0/24網段的數據包丟向節點B的IPSec Server，反之亦然。

一側的配置如下：

conn Tunnel1

    authby=secret

    auto=start

    left=%defaultroute

    leftid=1.1.1.1(本側公網IP)

    right=2.2.2.2(對側公網IP)

    type=tunnel

    ikelifetime=8h

    keylife=1h

    phase2alg=aes128-sha1;modp1024

    ike=aes128-sha1;modp1024

    auth=esp

    keyingtries=%forever

    keyexchange=ike

     leftsubnets={10.0.1.0/24,10.0.2.0/24}

     rightsubnet=10.0.0.0/24

     dpddelay=10

    dpdtimeout=30

    dpdaction=restart_by_peer

異常的表象為節點A的后端服務集群無法與節點B后端的服務正常通信，但是查看IPSec服務的狀態時，IPSec的狀態是正常的，甚至能抓包看到數據在IPSec Tunnel中通信，但是當節點A與B通信異常的時候，IPSec Server不正常向后端轉發加密的數據包。然后查看/proc/net/xfrm_stat文件發現有一個XfrmInTmplMismatch錯誤計數一直處于上升狀態，經查這個報錯的原因為No matching template for states不匹配。簡述就是IPSec的SA與SP不相匹配，然后在通過ip xfrm monitor 命令發現節點A與B之間通信的SPI不一致。

圖1

圖2

首先看圖2，請求發起時走的Tunnel的SPI為0x198e7538,屬于reqid 16385號 Tunnel，回包時走的Tunnel 的SPI為0x9ce44e77，屬于reqid 16389號Tunnel。由于兩條Tunnel的IKE不同，因此出現了XfrmInTmplMismatch上升的錯誤，解決方案很簡單，將配置文件中的leftsubnets={10.0.1.0/24,10.0.2.0/24}改為leftsubnet=0.0.0.0/0，這樣就能避免來回路徑不一致的問題（PS.因為只有一條路了:)）

解決方案已經有了，但是做人總得深入了解一下，為啥當有兩條IPSec Tunnel時，路由會發生錯誤。由于上述看到是因為來回路徑不同導致的問題，因此看源碼找一下SPI的生成規則：

https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.h

https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.c

中有一個函數是get_ipsec_spi ,他的作用為生成唯一的SPI號，然后我們一下它是如何生成SPI號的：

根據以上，我們就能發現，生成SPI的時候并不會考慮對端的子網掩碼。