本文通過覆盤排查ipsec故障的整體過程，揭示分析故障的方法，以及通過該故障學習相關知識。被拋棄的tcp_recycle
由於業務需要，我們在海外的某些節點上搭建了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=
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=改為leftsubnet=0.0.0.0/0，這樣就能避免來回路徑不一致的問題（ps.因為只有一條路了:)）
解決方案已經有了，但是做人總得深入了解一下，為啥當有兩條ipsec tunnel時，路由會發生錯誤。由於上述看到是因為來回路徑不同導致的問題，因此看原始碼找一下spi的生成規則：
中有乙個函式是get_ipsec_spi ,他的作用為生成唯一的spi號，然後我們一下它是如何生成spi號的：
根據以上，我們就能發現，生成spi的時候並不會考慮對端的子網掩碼。
綜上，就是本次排查ipsec故障的所有步驟。
GIT更新離奇失敗
這幾天一直下著雨，清明前後的天氣總是少不了雨。想起年前疫情初期的天氣，似乎頗有幾分相似。然而下雨天大概率會有一些離奇的事情發生。今天和往常一樣，做好了系統更新前的一切準備，同時也通知了使用者系統停止的時間。時間到了，我lu起袖子，開幹！非常熟練地登入到系統中，熟練地停止 發布訊息 備份 校驗，各種熟...
離奇的夢境與生活
我這人是乙個無神論者，不相信神鬼之說，也不太相信那些很玄的事情。不過近日做了兩個夢，讓我感覺有點怪怪的。其一 朋友來我的中學找我玩，中午我去買飯時，一轉身的功夫，朋友不見了。我找遍了整個校園也沒有找到朋友。情急之下，自己被驚醒了。早上趕緊給那朋友打了個 問問，這才確定朋友沒有失蹤。呵呵！自己那顆懸著...
新鮮新奇事物 喜歡 熟悉 新奇
在我們對乙個新鮮事物比較熟悉時，就是平時看多了，這叫 多看效應 這個效應就是看的多了就喜歡了。比如，我們在國外意外的場合，看到自己熟悉的事物，你才會特別喜歡它 或者你碰到了我們同民族的同胞，肯定會很激動。用我們的話來說就是 他鄉遇故知 工業設計大師洛伊發現，人喜歡新奇的東西，但如果東西過於新奇，就會...