IPSEC場景應用分析

司 蕾

蘇州高博軟件技術職業學院，江蘇蘇州 215163

IPSEC場景應用分析

司 蕾

蘇州高博軟件技術職業學院，江蘇蘇州 215163

本文提出一種在多IPSEC隧道場景下查詢SA的方法，并且與常見的方法進行效率對比，供技術感興趣者和相關領域者參考。

IPSEC；加密 ；IPSEC SA

隨著IP技術的普及，特別是在移動通信，銀行系統等對安全要求比較高的領域，IPSEC加密技術成為運營商或者廠家的首選。IPSEC技術包含IKE協議、加密和認證技術等，這些相關技術基本上都是標準組織在協議或者草案已經定義好的，但是實際在各種應用場景下還是會出現很多可擴展性的技術，以適應各種IPSEC應用場景。

1 IPSEC應用的網絡結構分類

“Internet 協議安全性 (IPSec)”是一種開放標準的框架結構，通過使用加密的安全服務以確保在 Internet 協議 (IP) 網絡上進行保密而安全的通訊。IPSEC技術常見的網絡部署場景一般有對稱型網絡和不對稱型網絡兩種。

對稱型網絡一般適用于企業的分部之間或者企業與企業之間，在互聯網絡上兩臺安全網關協商IPSEC隧道，用于加密所有流經的機密數據；不對稱型網絡一般適用于遠端接入，例如經常在外的企業人員需要訪問企業內部的網絡，可以隨時在網絡上向安全網關發起ISPEC隧道協商，協商加密隧道后，訪問企業內部網絡。兩種網絡結構，最大的不同點在于對稱型網絡中兩側的客戶端不需要具有IPSEC功能，而不對稱型網絡中要求接入側的客戶端具有IPSEC功能。本文主要講解不對稱型網絡在IPSEC應用中的各種技術點的分析。

2 實際網絡部署帶來的問題

2.1 IPSEC的隧道模式

隧道模式，顧名思能義是雙層IP地址的應用類型，即外層IP地址用于路由轉發，內層IP報文是真正的用戶數據報文。如下圖所示，當客戶端需要發出加密數據時：

第一步，首先生成需要加密的數據，其中Inner IP是指客戶端的內部邏輯IP，用于與對端客戶端交互的IP（注：對端客戶端在企業內部，不需要具有IPSEC功能）；

第二步，使用外部IP地址進行封裝，同時加上ESP頭對第一步生成的數據進行加密

第三步，網絡對加密數據報文進行轉發，其中轉發的依據是外部IP目的地址是安全網關；

第四步，安全網關收到數據后，對報文“剔除”外層IP頭以及ESP頭，對加密數據進行解密后恢復原始數據；

第五步，網絡原始數據報文進行轉發，轉發的依據是內層IP目的地址是企業內部的各個客戶端。

對于安全網關來說，需要接入成千上萬的IPSEC客戶端，如何來區分各個IPSEC客戶端呢，使用各自的加密和認證算法進行加密和解密呢？

2.2 為什么要區分IPSEC客戶端

每一個客戶端接入安全網關都需要協商以下參數才能建立IPSEC隧道：

1）加密和認證算法，例如3DES，ASE128以及認證算法MD5，SHA1等；

2）需要加解密的數據流，也就是IPSEC ACl，源IP目的IP；

3）加密密鑰和認證密鑰，每一個IPSEC的隧道密鑰必然不同。

以上數據的合集在IPSEC技術框架中的術語叫IPSEC SA()，即IPSEC安全聯盟，每一個IPSEC SA代表需要加密的那份數據需要的參數。如果安全網關無法區分客戶端，下行數據流就無法正確發到客戶端或者加解密失敗。

2.3 基于ACL查詢的IPSEC場景

IKE協議交互分為兩個階段，第一階段為IKE SA的建立，第二階段為IPSEC SA的建立.IPSEC SA建立在IKE SA的基礎上，IPSEC SA主要目的是建立后續業務數據需要加密的密鑰以及哪些數據需要加密.如下圖所示，TSi(Traffic Selector Initiator)和TSr為Traffic Selector Responser，發起者的流量范圍與接收者的流量范圍兩者相與，便可以獲取需要加密的數據acl.

例如上述IPSEC客戶端之間的IPSEC協商時，TS為必選參數。

TSi為192.168.1.0/24-192.168.2.0/27

TSr為192.168.1.0/27-192.168.2.0/24

那么最終協商的traffic selector為192.168.1.0/27-192.168.2.0/27

根據IKE協議交互我們得知，IKE協商時traffic selector是一個非常重要的參數，如果客戶端與安全網關不一致時，隧道是無法協商成功的，我們一般稱traffic selector為IPSEC ACL。

根據以上分析得知,當安全網關收到需要加密的數據時，可以根據內層的數據自動匹配IPSEC ACL選擇IPSEC SA，也就是匹配到不同的客戶端。如上圖所示。

2.4 基于路由方式的IPSEC場景

基于ACL查詢的IPSEC場景適合于內層IP地址網段能比較容易區分，也就是每一個IPSEC對等體的流量范圍不一致時。當內層網段無法區分每一個客戶端，并且ACL只能使用相同的ACL時，如下圖所示，所有的IPSEC客戶端的內層IP都有3個網段，無法進行歸類，只能使用0.0.0.0/0通配符網段。

在該場景下安全網關不能再通過協商的ACL來進行SA查詢了，因為所有客戶端協商的ACL源地址網段都是0.0.0.0/0通配符。為了能正確匹配所有客戶端，安全網關需要為每一個客戶端配置內層IP網段的路由（即需要加密的數據流的網段），并且每一條路由與IPSEC隧道標示進行關聯，這樣就可以通過路由正確匹配IPSEC SA了。假設安全網關接入兩個客戶端，在安全網關上需要做如下部署：

1）IPSEC客戶端1的IPSEC隧道記錄為tunnel1

IPSEC客戶端2的IPSEC隧道記錄為tunnel2。

2）ip route 192.168.1.1/29 tunnel1；

ip route 172.16.1.1/29 tunnel1；

ip route 10.192.1.1/29 tunnel1；

ip route 192.168.2.1/29 tunnel2；

ip route 172.16.2.1/29 tunnel2；

ip route 10.192.2.1/29 tunnel2。

3 結論

基于筆者的經驗，對以上兩種IPSEC SA的查詢方式作了比較，提供給使用者以及相關技術開發者參考。

[1]Harkins，D.and D.Carrel，"The Internet Key Exchange(IKE)"，RFC 2409，1998，11.

[2]D.Maughan，and J.Turner“Internet Security Association and Key Management Protocol (ISAKMP)”，RFC 2408，1998，11.

TP39

A

1674-6708（2010）30-0222-02