由于业务需要，我们在海外的某些节点上搭建了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的时候并不会考虑对端的子网掩码。