今天就跟大家聊聊有關(guān)怎么進(jìn)行Linux IPsec的分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
公司專注于為企業(yè)提供網(wǎng)站設(shè)計、做網(wǎng)站、微信公眾號開發(fā)、電子商務(wù)商城網(wǎng)站建設(shè)，小程序設(shè)計，軟件定制設(shè)計等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗，我們會仔細(xì)了解各客戶的需求而做出多方面的分析、設(shè)計、整合，為客戶設(shè)計出具風(fēng)格及創(chuàng)意性的商業(yè)解決方案，創(chuàng)新互聯(lián)建站更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。
這里主要講述通過復(fù)盤排查IPSec故障的整體過程，揭示分析故障的方法，以及通過該故障學(xué)習(xí)相關(guān)知識。
由于業(yè)務(wù)需要，我們在海外的某些節(jié)點上搭建了VPN，方便海外節(jié)點之間的數(shù)據(jù)交互，某天我們在兩個新節(jié)點之間搭建了一條新的VPN，上線之后Ping、traceroute測試無異常，觀察已經(jīng)有流量通過，監(jiān)控指標(biāo)等一切正常。但是過了半個小時后，業(yè)務(wù)反饋兩個新節(jié)點之間網(wǎng)絡(luò)不通，發(fā)現(xiàn)問題后緊急上線回退了配置。然后事后線下回測，發(fā)現(xiàn)通過重啟IPsec 進(jìn)程，能重現(xiàn)時通時不通的現(xiàn)象。
接下來重現(xiàn)復(fù)盤一下當(dāng)時的配置和場景，以及解釋該問題的根因。
如上所示，A/B兩個節(jié)點通過IPsec打通，A側(cè)的網(wǎng)段為10.0.0.0/24，B側(cè)的網(wǎng)段為10.0.1.0/24與10.0.2.0/24。A側(cè)將去往10.0.1.0/24與10.0.2.0/24網(wǎng)段的數(shù)據(jù)包丟向節(jié)點B的IPSec Server，反之亦然。
一側(cè)的配置如下：
conn Tunnel1
authby=secret
auto=start
left=%defaultroute
leftid=1.1.1.1(本側(cè)公網(wǎng)IP)
right=2.2.2.2(對側(cè)公網(wǎng)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
異常的表象為節(jié)點A的后端服務(wù)集群無法與節(jié)點B后端的服務(wù)正常通信，但是查看IPSec服務(wù)的狀態(tài)時，IPSec的狀態(tài)是正常的，甚至能抓包看到數(shù)據(jù)在IPSec Tunnel中通信，但是當(dāng)節(jié)點A與B通信異常的時候，IPSec Server不正常向后端轉(zhuǎn)發(fā)加密的數(shù)據(jù)包。然后查看/proc/net/xfrm_stat文件發(fā)現(xiàn)有一個XfrmInTmplMismatch錯誤計數(shù)一直處于上升狀態(tài)，經(jīng)查這個報錯的原因為No matching template for states不匹配。簡述就是IPSec的SA與SP不相匹配，然后在通過ip xfrm monitor 命令發(fā)現(xiàn)節(jié)點A與B之間通信的SPI不一致。
圖1
圖2
首先看圖2，請求發(fā)起時走的Tunnel的SPI為0x198e7538,屬于reqid 16385號 Tunnel，回包時走的Tunnel 的SPI為0x9ce44e77，屬于reqid 16389號Tunnel。由于兩條Tunnel的IKE不同，因此出現(xiàn)了XfrmInTmplMismatch上升的錯誤，解決方案很簡單，將配置文件中的leftsubnets={10.0.1.0/24,10.0.2.0/24}改為leftsubnet=0.0.0.0/0，這樣就能避免來回路徑不一致的問題（PS.因為只有一條路了:)）
解決方案已經(jīng)有了，但是做人總得深入了解一下，為啥當(dāng)有兩條IPSec Tunnel時，路由會發(fā)生錯誤。由于上述看到是因為來回路徑不同導(dǎo)致的問題，因此看源碼找一下SPI的生成規(guī)則：
https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.h
https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.c
中有一個函數(shù)是get_ipsec_spi ,他的作用為生成唯一的SPI號，然后我們一下它是如何生成SPI號的：
根據(jù)以上，我們就能發(fā)現(xiàn)，生成SPI的時候并不會考慮對端的子網(wǎng)掩碼。
綜上，就是本次排查IPSec故障的所有步驟。
看完上述內(nèi)容，你們對怎么進(jìn)行Linux IPsec的分析有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
重慶分公司
重慶分公司
