怎么进行Linux IPsec的分析

今天就跟大家聊聊有关怎么进行Linux IPsec的分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。这里主要讲述通过复盘排查IPSec故障的整体过程，揭示分析故障的方法，以及通过该故障学习相关知识。由于业务需要，我们在海外的某些节点上搭建了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 ik开发云主机域名elifetime=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.hhttps://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.c中有一个函数是get_ipsec_spi ,他的作用为生成唯一的SPI号，然后我们一下它是如何生成SPI号的：根据以上，我们就能发现，生成SPI的时候并不会考虑对端的子网掩码。综上，就是本次排查IPSec故障的所有步骤。看完上述内容，你们对怎么进行Linux IPsec的分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注开发云行业资讯频道，感谢大家的支持。

相关推荐: 抢占式实例的最高出价和抢占式实例当前市场价格的关系是什么

小编给大家分享一下抢占式实例的最高出价和抢占式实例当前市场价格的关系是什么，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 本篇文章给大家带来的内容是关于抢占式实例的最高出价和抢占式实…