今天就跟大家聊聊有關(guān)怎么進(jìn)行Linux IPsec的分析,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
創(chuàng)新互聯(lián)公司長期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對不同對象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺,與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為樂都企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè),樂都網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。這里主要講述通過復(fù)盤排查IPSec故障的整體過程,揭示分析故障的方法,以及通過該故障學(xué)習(xí)相關(guān)知識。
由于業(yè)務(wù)需要,我們在海外的某些節(jié)點(diǎn)上搭建了VPN,方便海外節(jié)點(diǎn)之間的數(shù)據(jù)交互,某天我們在兩個新節(jié)點(diǎn)之間搭建了一條新的VPN,上線之后Ping、traceroute測試無異常,觀察已經(jīng)有流量通過,監(jiān)控指標(biāo)等一切正常。但是過了半個小時(shí)后,業(yè)務(wù)反饋兩個新節(jié)點(diǎn)之間網(wǎng)絡(luò)不通,發(fā)現(xiàn)問題后緊急上線回退了配置。然后事后線下回測,發(fā)現(xiàn)通過重啟IPsec 進(jìn)程,能重現(xiàn)時(shí)通時(shí)不通的現(xiàn)象。
接下來重現(xiàn)復(fù)盤一下當(dāng)時(shí)的配置和場景,以及解釋該問題的根因。
環(huán)境簡述如上所示,A/B兩個節(jié)點(diǎn)通過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é)點(diǎn)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
異常表現(xiàn)與原因異常的表象為節(jié)點(diǎn)A的后端服務(wù)集群無法與節(jié)點(diǎn)B后端的服務(wù)正常通信,但是查看IPSec服務(wù)的狀態(tài)時(shí),IPSec的狀態(tài)是正常的,甚至能抓包看到數(shù)據(jù)在IPSec Tunnel中通信,但是當(dāng)節(jié)點(diǎn)A與B通信異常的時(shí)候,IPSec Server不正常向后端轉(zhuǎn)發(fā)加密的數(shù)據(jù)包。然后查看/proc/net/xfrm_stat文件發(fā)現(xiàn)有一個XfrmInTmplMismatch錯誤計(jì)數(shù)一直處于上升狀態(tài),經(jīng)查這個報(bào)錯的原因?yàn)镹o matching template for states不匹配。簡述就是IPSec的SA與SP不相匹配,然后在通過ip xfrm monitor 命令發(fā)現(xiàn)節(jié)點(diǎn)A與B之間通信的SPI不一致。
圖1
圖2
首先看圖2,請求發(fā)起時(shí)走的Tunnel的SPI為0x198e7538,屬于reqid 16385號 Tunnel,回包時(shí)走的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.因?yàn)橹挥幸粭l路了:))
根因分析解決方案已經(jīng)有了,但是做人總得深入了解一下,為啥當(dāng)有兩條IPSec Tunnel時(shí),路由會發(fā)生錯誤。由于上述看到是因?yàn)閬砘芈窂讲煌瑢?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的時(shí)候并不會考慮對端的子網(wǎng)掩碼。
綜上,就是本次排查IPSec故障的所有步驟。
看完上述內(nèi)容,你們對怎么進(jìn)行Linux IPsec的分析有進(jìn)一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道,感謝大家的支持。