站點間IPSec VPN網絡技術深度解析
【IPSec VPN】本文首先通過梳理IPSec VPN中各技術的用途及之間的關聯關系幫助大家理解技術原理,其次為大家介紹IPSec VPN的一些高級功能,最后為大家分享典型實踐場景和故障排查方法。
本文作者:田思楊
銳捷網絡技術服務部互聯網服務中心
前言
在上一篇《VPN技術淺談之如何部署遠程辦公網絡》中,作者為大家分享了端到站點VPN技術,該技術主要使用在遠程辦公人員和企業網絡互通場景,而站點到站點VPN技術常用于總部與分支之間的網絡互通,通過利用組織已有的互聯網出口,使用VPN技術虛擬出一條“專線”,將企業的分支機構和總部連接起來,組成一個大的局域網。站點到站點VPN主要包括IPSec VPN、L2TP VPN、L2TP over IPSec VPN、GRE VPN、GRE over IPSec VPN、SSL VPN等。IPSec VPN技術因其具有安全性高、成本低、部署靈活、擴展性好等優點,已成為企業站點間VPN部署的第一技術選擇。
IPSec VPN不是一個單獨的協議,而是由一組協議組成,因其包含的技術多、技術間關聯關系多,很多朋友無法把IPSec VPN技術理解透。本文首先通過梳理IPSec VPN中各技術的用途及之間的關聯關系幫助大家理解技術原理,其次為大家介紹IPSec VPN的一些高級功能,最后為大家分享典型實踐場景和故障排查方法。希望本文能夠幫助各位讀者把IPSec VPN技術學透、用明白,耐心讀完這篇文章相信你會有不一樣的收獲。
銳捷支持IPSec VPN的設備有很多種,不同設備對各IPSec VPN技術的支持情況略有差異,本文以銳捷網關設備為例給大家講解,如讀者使用其他設備歡迎聯系銳捷工程師或到銳捷官網查詢,感謝。

圖1:常見企業VPN接入拓撲模型
IPSec VPN基礎參數
IPSec中通信雙方建立的連接叫做安全關聯(IPSec SA),雙方通過參數協商完成IPSec SA建立后,通過IPSec SA傳輸加密的數據報文進行通信。所以兩個對等體間要想通過IPSec VPN通信,首先要建立IPSec SA。在進行IPSec SA建立時對等體間要進行IPSec SA參數協商,兩端參數相同時才會建立成功。

圖2:IPSec VPN基礎參數
IPSec SA生成方式
手動指定生成IPSec SA
對等體通過手動指定IPSec SA協商參數生成IPSec SA,IPSec SA建立后沒有生存周期限制,永不過期,除非手工刪除,因此存在安全隱患。一般推薦在對等體數量較少且無法通過IKE協商建立IPSec SA場景下使用。
IKE協商生成IPSec SA
IKE用于動態建立并實時維護IPSec SA。IKE通過兩個階段來建立IPSec SA,第一階段首先要協商建立IKE SA,第二階段通過IKE SA協商建立IPSec SA。
IKE協商生成IPSec SA比手動指定生成IPSec SA存在以下優勢:
- 適用場景豐富:手動指定方式必須對等體兩端都有固定的公網IP地址,如一端對等體公網IP地址不固定必須使用IKE協商方式;
- 降低配置復雜度:手動指定方式需要手動配置SPI、密鑰等信息,在對等體較多的場景配置量較大而不便于維護,IKE協商方式會通過IKE SA來生成和維護這些信息,降低配置復雜度及維護成本;
- 提高安全性:手動指定方式建立的IPSec SA密鑰是靜態的,建立后永不過期,IKE協商方式會通過IKE SA生成密鑰,并且生命周期到期后進行老化重新生成,提高了安全性。
小提示:IKE協議目前有兩個版本IKEv1與IKEv2,IKEv1目前較為常用,IKEv2與IKEv1配置思路相同,但協商過程與IKEv1有所區別,本文不進行講解,本文中出現的IKE協議均代表IKEv1。
IKE SA協商模式
在IKE第一階段有兩種協商模式可協商建立IKE SA,主模式或者野蠻模式。主模式使用6個報文完成IKE SA建立,而野蠻模式使用3個報文完成IKE SA建立,與主模式相比野蠻模式減少交互報文數量從而加快了協商速度,但因對身份信息和認證信息采用明文交互,沒有加密保護,因此不安全,作者不推薦使用。
野蠻模式早期設計主要為解決一端對等體公網IP地址不固定或沒有公網IP地址的場景下主模式無法協商建立的問題,目前該問題可以通過“動態隧道”的方法更好地解決,所以推薦使用主模式。野蠻模式僅在銳捷設備與非銳捷設備建立IPSec使用主模式無法建立成功下使用,其他場景下不推薦使用。
小提示:主模式和野蠻模式報文交互詳細流程參考本文《IKE報文交互知識點回顧》小節。
IKE SA加密方式
IKE SA使用對稱加密算法對數據進行加密和解密,保證數據的安全性。常用的對稱加密算法有DES、3DES、AES等,這三個加密算法的安全性由高到低依次是:AES、3DES、DES,安全性高的加密算法實現機制復雜,運算速度慢。

圖3:IKE SA常用的對稱加密算法
IKE SA驗證方式
IKE SA使用驗證算法對報文完整性及來源合法性進行驗證,常用的驗證方式有MD5-HMAC、SHA1-HMAC等,是HASH算法和HMAC兩種技術的結合。
HASH算法實現對報文進行完整性校驗,常見的HASH算法有MD5、SHA1等,MD5算法的計算速度比SHA1算法快,而SHA1算法的安全強度比MD5算法高。

圖4:IKE SA常用的HASH算法
HMAC(Hash-based Message Authentication Code)是一種基于HASH算法和密鑰進行消息認證的方法,實現對報文來源的合法性進行驗證,可以與任何HASH算法捆綁使用。
IKE SA密鑰生成方式
DH(Diffie-Hellman)是一種非對稱密鑰算法,雙方可通過僅交換一些數據,即可計算出雙方的密鑰,并且第三方捕獲了其中的數據也無法計算得出密鑰。DH產生的密鑰用于數據報文加密及HMAC計算中。對等體兩端DH組長度需指定為相同,常用的DH組長度有768bit(DH1)、1024bit(DH2)、1536bit(DH5)。
IKE SA認證方式
在IKE對等體之間在進行身份認證時支持通過預共享密鑰認證和數字證書認證兩種方式來確認對方身份的合法性。預共享密鑰認證配置比較簡單,是目前比較常用的認證方式。數字證書認證相對復雜但安全性較高,對安全性有較高要求的場景建議使用數字證書認證。
IKE SA身份標識
在IKE SA協商中對等體雙方需要使用相同類型的身份標識,常用的身份標識類型有4種,IP地址、FQDN、USER-FQDN、證書DN。數字證書認證通常采用證書DN作為本地身份標識。預共享密鑰認證默認采用IP地址作為本地身份標識,通常使用采用IP地址作為本地身份標識即可,若遇到以下兩種場景推薦手動修改使用FQDN或USER-FQDN:
- 如果對等體的IP地址為域名形式,則必須使用FQDN或USER-FQDN;
- 對等體較多的場景下,建議采用FQDN或USER-FQDN,便于區分每個對等體對應是哪個分支。
小提示:身份標識類型與協商模式無關,任何身份標識在主模式或野蠻模式下均可使用,比如主模式使用FQDN作為身份標識或野蠻模式使用IP作為身份標識都可正常完成IKE SA協商,只要對等體兩端使用相同類型身份標識即可。
IKE SA生命周期
由于IPSec SA協商是建立在IKE SA基礎上的,因此為節省協商IPSec SA的時間,一般IKE SA生命周期(60秒到86400秒,缺省86400秒)比IPSec SA生命周期設置的長。當在進行IKE SA協商時,兩端對等體設置的IKE SA生命周期不同不會造成IKE SA協商失敗,而使用發送方設置的IKE SA生命周期。
IPSec SA安全協議
AH和ESP是IPSec的兩種安全協議,用于實現IPSec在身份認證和數據加密的安全機制。
- AH協議(Authentication Header,協議號51),主要提供數據完整性確認、數據來源確認、防重放等安全特性。AH通常使用MD5-HMAC、SHA-HMAC等驗證算法實現數據完整性;
- ESP協議(Encapsulating Security Payload,協議號50),主要提供數據完整性確認、數據加密、數據來源確認、防重放等安全特性。ESP通常使用DES、3DES、AES等加密算法實現數據加密,使用MD5-HMAC、SHA-HMAC等驗證算法實現數據完整性。ESP協議相比AH協議多了支持數據加密、支持NAT穿越(NAT-T)這兩大優勢,是目前IPSec VPN較為常用的安全協議。
IPSec SA封裝模式
封裝模式用于指定安全協議的封裝位置,有傳輸模式和隧道模式兩種:
傳輸(Transport)模式下,AH頭或ESP頭插入IP頭和傳輸層協議之間,不改變原始報文頭,IPSec隧道的源和目的地址就是最終通信雙方的源和目的地址,所以只能保護兩個IPSec對等體之間相互通信。一般常用在使用GRE over IPSec或L2TP over IPSec協議的場景中,使用IPSec隧道保護GRE或L2TP對等體;
隧道(Tunnel)模式下,AH頭或ESP頭插在原始IP頭之前,并且新生成一個IP頭放在ESP頭或AH頭之前,所以可以保護兩個IPSec對等體背后兩個網絡之間進行通信。一般常用在站點間網絡互通的場景,是較常用的封裝模式。

圖5:AH協議兩種封裝模式下報文封裝

圖6:ESP協議兩種封裝模式下報文封裝
IPSec SA加密方式
IPSec SA支持使用的加密方式與IKE SA相同,參考本文《IKE SA加密方式》小節。
IPSec SA驗證方式
IPSec SA支持使用的驗證方式與IKE SA相同,參考本文《IKE SA驗證方式》小節。
IPSec SA生命周期
為了確保安全,IPSec SA將在經過一定時間(0或者120秒到86400秒,缺省3600秒)或達到一定通信量(0或2560KB到536870912KB,缺省4608000KB)之后超時,重新協商,并使用新的密鑰。新IPSec SA在生命周期超時前30秒,或經由這條隧道的數據通信量距生命周期還有256KB時開始進行協商(根據哪個先發生)。
當在進行IPSec SA協商時,兩端對等體設置的IPSec SA生命周期不同不會造成IPSec SA協商失敗,而使用發起方設置的IPSec SA生命周期。
IPSec VPN高級功能

圖7:IPSec VPN高級功能
IPSec隧道自動建立(Set Autoup)
在默認情況下IPSec VPN配置完后,IPSec隧道是由數據流量觸發后再協商建立的。配置IPSec隧道自動建立(Set Autoup)功能后,不管是否有數據流量觸發,只要完成IPSec VPN配置后,設備會自行觸發IPSec隧道建立。
IPSec鏈路探測(DPD/Track)
DPD探測
在默認情況下兩端設備建立IPSec隧道后,當一端設備出現問題后另一端是無感知的,另一端設備會繼續通過IPSec隧道發送數據給故障設備導致數據通信中斷。此時需要等待IPSec隧道超時后故障IPSec隧道才會中斷(IPSec隧道默認超時時間為一小時)。
DPD探測是通過發送IKE報文確認對端設備IKE SA狀態是否正常的一種探測機制,當探測到對端IKE狀態異常時,會清除對應的IKE SA和IPSec SA。
DPD探測有兩種工作模式:
- 按需探測模式(On-demand),在超過配置的探測時間且當有數據報文發送時,設備會發送DPD消息探測對端設備是否正常,當發送5次DPD信息都沒有收到對端設備回包會認為對端IKE SA狀態異常;
- 周期探測模式(Periodic),設備會根據配置的探測時間周期性主動發送 DPD 消息探測對端設備是否正常,當發送5次DPD信息都沒有收到對端設備回包會認為對端IKE SA狀態異常。
綜上按需探測模式比周期探測模式會發送更少的DPD信息只在數據報文發送前檢測,節約設備資源及網絡帶寬資源,但探測到對端設備故障的時間會比周期探測模式長,讀者根據自身業務需求使用合適模式進行DPD探測即可。
Track探測
DPD探測通過交互IKE報文可以探測到對端設備IKE SA狀態是否正常,對于IKE SA狀態正常而IPSec SA異常的情況DPD探測就無能為力了,這種情況同樣會導致IPSec業務中斷。Track探測通過定期發送ICMP或UDP報文探測IPSec實際業務是否正常,當Track探測到IPSec業務不通時會清除對應的IPSec SA進行重新協商。一般建議同時配置DPD探測和Track探測。
NAT穿越(NAT-T)
設備默認開啟NAT穿越(NAT-T)功能,用于解決當建立IPSec VPN的兩臺設備間存在NAT設備ESP報文無法通過的問題。ESP報頭封裝在IP層之上IP協議號50所以無法通過NAT設備, NAT-T通過在ESP報文之上封裝4500端口的UDP報頭解決該問題。

圖8:NAT-T在ESP報文之上封裝4500端口的UDP報頭
在IKE協商的第一階段(主模式第1、2個報文、野蠻模式第1個報文)支持NAT-T的設備在發送IKE報文中會攜帶一個檢測NAT-T能力的Vendor ID的載荷,當兩端設備都攜帶這個字段就會進行NAT-T協商。當檢測雙方都支持NAT-T隨后(主模式第3、4個報文、野蠻模式第2個報文)會攜帶一個NAT-D的載荷,NAT-D載荷中包含自己IP地址和端口的HASH值,對端設備收到這個值后會與收到的實際IP地址和端口的Hash值做對比,如果相同說明中間未經過NAT設備,否則說明中間經過NAT設備。如果NAT-T檢測到中間經過NAT設備,設備會在下一個報文(主模式第5、6報文、野蠻模式第3個報文)開始插入一個4500端口的UDP報頭,至此NAT-T工作結束。
動態隧道(Crypto Dynamic-map)
一般情況下,兩端設備都有公網IP地址,配置時兩端使用靜態隧道的方式相互指定對端公網IP地址進行IPSec隧道建立。實際中也會遇到一端有公網IP地址而另一端沒有固定公網IP地址或者沒有公網IP地址的情況,這種情況兩端都使用靜態隧道的方式就無法建立IPSec隧道。使用動態隧道配置時無需指定對端IP地址、身份、感興趣流等,有公網IP地址的一端使用動態隧道可解決另一端沒有固定公網IP地址或者沒有公網IP地址的問題。此外,如果本端需要建立大量IPSec VPN的對等體也可以使動態隧道,減少配置量。
反向路由注入(RRI)
在完成IPSec配置后我們要配置去往對端網段的靜態路由,如果感興趣流網段較多人為手動配置及維護這些路由有些不便。開啟反向路由注入功能,當IPSec隧道建立完成后會自動產生相應的靜態路由(目的地址是對端感興趣流地址,下一跳是對端公網IP地址)注入到路由表中,當IPSec隧道斷開后對應的路由也會消失。反向路由會結合IPSec隧道的建立信息自動生成對端網段路由,這樣便能動態地完成路由的添加與刪除,避免大量人為配置。此外,在設備存在多出口場景,還可以通過反向路由注入進行多出口上IPSec隧道的切換。
使用動態路由協議(GRE over IPSec/L2TP over IPSec)
在IPSec網絡中只能通過靜態路由配置到對端網段的路由,IPSec對等體之間無法使用動態路由協議進行路由學習,反向路由注入可以一定程度上解決感興趣流網段較多、靜態路由維護成本高的問題,如果希望使用動態路由協議進一步降低路由維護成本,可以使用GRE over IPSec VPN或者L2TP over IPSec VPN,使用GRE或者L2TP建立VPN隧道,然后再使用IPSec隧道保護這個VPN隧道,此時既保證了數據安全又可在VPN隧道兩端使用動態路由協議。
IPSec VPN典型場景
單總部單分支場景
場景Ⅰ



圖9:IPSec VPN典型場景Ⅰ配置表
場景Ⅱ



圖10:IPSec VPN典型場景Ⅱ配置表
場景Ⅲ



圖11:IPSec VPN典型場景Ⅲ配置表
場景Ⅳ



圖12:IPSec VPN典型場景Ⅳ配置表
場景Ⅴ



圖13:IPSec VPN典型場景Ⅴ配置表
場景Ⅵ



圖14:IPSec VPN典型場景Ⅵ配置表
多總部多分支場景
場景Ⅶ



圖15:IPSec VPN典型場景Ⅶ配置圖
場景Ⅷ



圖16:IPSec VPN典型場景Ⅷ配置表
在多總部多分支場景下,除以上兩種單出口情況外,多出口的情況也較為常見。部署時將以上兩種多總部多分支場景與單總部單分支場景下多出口的情況結合使用即可,本章不在贅述。
IPSec VPN故障排查
IPSec VPN使用時難免會遇到隧道建立失敗的情況。一般IPSec VPN故障可分為三類:IKE SA建立失敗;IPSec SA建立失敗;IPSec SA建立成功但數據不通。在遇到IPSec VPN故障時讀者可查看發起方和接收方狀態并對比如下IPSec對等體狀態解析圖確認屬于哪類故障,然后根據每類故障常見原因進行排查。
![]()
圖17:查看IPSec對等體狀態

18:IPSec對等體狀態解析
IKE報文交互知識點回顧
在分析每類故障常見發生原因前,作者首先帶大家回顧下IKE報文交互情況,只有知道了每個報文在交互什么內容,在遇到IPSec建立停留在某一階段時,我們才知道排查的方向。IKE通過兩個階段來建立IPSec SA,第一階段采用主模式或者野蠻模式建立IKE SA,第二階段采用快速模式建立IPSec SA。
IKE第一階段(主模式):
- 第1-2個報文攜帶IKE策略,進行IKE策略協商,IKE策略包含:加密算法、HASH算法、DH組、驗證方式、IKE SA生命周期,
- 第3-4個報文攜帶DH算法需要的材料,進行DH算法計算生成密鑰,
- 第5-6個報文攜帶身份信息及認證信息,進行對等體間的認證,完成IKE SA建立。需要注意的是從第5個報文開始有兩處變化,第一點是報文開始被加密保護,第二點是如果存在NAT穿越的情況UDP端口號將從500變為4500

圖19:主模式報文交互流程及對等體狀態
IKE第一階段(野蠻模式):
- 第1個報文發送方發送IKE策略、DH算法需要的材料、身份信息,IKE策略包含:加密算法、HASH算法、DH組、驗證方式、IKE SA生命周期;
- 第2個報文接收方回應匹配的IKE策略,發送DH算法需要的材料、身份信息、認證信息;
- 第3個報文發送方發送認證信息完成認證,完成IKE SA建立。如果存在NAT穿越的情況從該報文開始UDP端口號從500變為4500。

圖20:野蠻模式報文交互流程及對等體狀態
IKE第二階段:
- 第1個報文發送方發送IPSec轉換集、感興趣流,進行IPSec參數協商,IPSec轉換集包含:封裝模式、安全協議、加密算法、HASH算法、IPSec SA生命周期。另外如果開啟PFS還會攜帶DH算法需要的材料,進行DH算法計算生成新的密鑰;
- 第2個報文接收方回應匹配的IPSec策略、感興趣流及DH算法需要的材料(如果開啟PFS);
- 第3個報文發送方進行結果確認,雙方完成IPSec SA建立。
小提示:PFS(Perfect Forward Secrecy)是一種安全機制,默認情況下IPSec SA會直接使用IKE SA通過DH算法生成的密鑰,開啟PFS機制后,IPSec SA在協商時會在額外進行一次DH密鑰交換算法,使IPSec SA使用的密鑰與IKE SA使用的密鑰不同,提高安全性。
IKE SA建立失敗故障原因分析

圖21:IKE第一階段IKE SA建立失敗原因
IPSec SA建立失敗故障原因分析

圖22:IKE第二階段IPSec SA建立失敗原因
IPSec SA建立成功但數據不通故障原因分析

圖23:IPSec SA建立成功但數據不通原因
寫在最后
本文結合理論與實踐對IPSec VPN技術的基礎參數、高級功能、典型實踐場景及故障排查方法進行了深入解析。除了IPSec VPN技術外L2TP over IPSec VPN、GRE over IPSec VPN等VPN技術也在一些企業站點間使用,讀者可結合本文思路自行進行研究。
相關推薦:
相關標簽:
點贊
更多技術博文
-
解密DeepSeek-V3推理網絡:MoE架構如何重構低時延、高吞吐需求?DeepSeek-V3發布推動分布式推理網絡架構升級,MoE模型引入大規模專家并行通信,推理流量特征顯著變化,Decode階段對網絡時度敏感。網絡需保障低時延與高吞吐,通過端網協同負載均衡與擁塞控制技術優化性能。高效運維實現故障快速定位與業務高可用,單軌雙平面與Shuffle多平面組網方案在低成本下滿足高性能推理需求,為大規模MoE模型部署提供核心網絡支撐。
-
#交換機
-
-
高密場景無線網絡新解法:銳捷Wi-Fi 7 AP 與 龍伯透鏡天線正式成團銳捷網絡在中國國際大學生創新大賽(2025)總決賽推出旗艦Wi-Fi 7無線AP RG-AP9520-RDX及龍伯透鏡天線組合,針對高密場景實現零卡頓、低時延和高并發網絡體驗。該方案通過多檔賦形天線和智能無線技術,有效解決干擾與覆蓋問題,適用于場館、辦公等高密度環境,提供穩定可靠的無線網絡解決方案。
-
#無線網
-
#Wi-Fi 7
-
#無線
-
#放裝式AP
-
-
打造“一云多用”的算力服務平臺:銳捷高職教一朵云2.0解決方案發布銳捷高職教一朵云2.0解決方案幫助學校構建統一云桌面算力平臺,支持教學、實訓、科研和AI等全場景應用,實現一云多用。通過資源池化和智能調度,提升資源利用效率,降低運維成本,覆蓋公共機房、專業實訓、教師辦公及AI教學等多場景需求,助力教育信息化從分散走向融合,推動規模化與個性化培養結合。
-
#云桌面
-
#高職教
-
-
醫院無線升級必看:“全院零漫游”六大謎題全解析銳捷網絡的全院零漫游方案是新一代醫療無線解決方案,專為智慧醫院設計,通過零漫游主機和天線入室技術實現全院覆蓋和移動零漫游體驗。方案支持業務擴展全適配,優化運維管理,確保內外網物理隔離安全,并便捷部署物聯網應用,幫助醫院提升網絡性能,支持舊設備利舊升級,降低成本。
-
#醫療
-
#醫院網絡
-
#無線
-