今天就跟大家聊聊有关怎么进行Linux IPsec的分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
创新互联公司长期为1000多家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为乐都企业提供专业的成都网站设计、成都网站建设,乐都网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。这里主要讲述通过复盘排查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
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的时候并不会考虑对端的子网掩码。
综上,就是本次排查IPSec故障的所有步骤。
看完上述内容,你们对怎么进行Linux IPsec的分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联-成都网站建设公司行业资讯频道,感谢大家的支持。