17-VPN
本章節下載: 17-VPN (947.43 KB)
VPN的支持情況與設備型號相關,請參見“特性差異列表”的“特性差異情況”部分的介紹。
在實施IPSec(IP Security)的過程中,可以使用IKE(Internet Key Exchange,互聯網密鑰交換)協議來建立SA,該協議建立在由ISAKMP(Internet Security Association and Key Management Protocol,互聯網安全聯盟和密鑰管理協議)定義的框架上。IKE為IPSec提供了自動協商交換密鑰、建立SA的服務,能夠簡化IPSec的使用和管理,大大簡化IPSec的配置和維護工作。
IKE不是在網絡上直接傳輸密鑰,而是通過一係列數據的交換,最終計算出雙方共享的密鑰,並且即使第三者截獲了雙方用於計算密鑰的所有交換數據,也不足以計算出真正的密鑰。
若無特殊說明,本文中的IKE均指第1版本的IKE協議。
IKE具有一套自保護機製,可以在不安全的網絡上安全地認證身份、分發密鑰、建立IPSec SA。
· 身份認證:身份認證確認通信雙方的身份。支持兩種認證方法:預共享密鑰(pre-shared-key)認證和基於PKI的數字簽名(rsa-signature)認證。
· 身份保護:身份數據在密鑰產生之後加密傳送,實現了對身份數據的保護。
DH(Diffie-Hellman,交換及密鑰分發)算法是一種公共密鑰算法。通信雙方在不傳輸密鑰的情況下通過交換一些數據,計算出共享的密鑰。即使第三者(如黑客)截獲了雙方用於計算密鑰的所有交換數據,由於其複雜度很高,也不足以計算出真正的密鑰。所以,DH交換技術可以保證雙方能夠安全地獲得公有信息。
PFS(Perfect Forward Secrecy,完善的前向安全性)特性是一種安全特性,指一個密鑰被破解,並不影響其他密鑰的安全性,因為這些密鑰間沒有派生關係。對於IPSec,是通過在IKE階段2協商中增加一次密鑰交換來實現的。PFS特性是由DH算法保障的。
IKE使用了兩個階段為IPSec進行密鑰協商並建立SA:
(1) 第一階段,通信各方彼此間建立了一個已通過身份認證和安全保護的通道,即建立一個ISAKMP SA。第一階段有主模式(Main Mode)和野蠻模式(Aggressive Mode)兩種IKE交換方法。
(2) 第二階段,用在第一階段建立的安全隧道為IPSec協商安全服務,即為IPSec協商具體的SA,建立用於最終的IP數據安全傳輸的IPSec SA。
如上圖所示,第一階段主模式的IKE協商過程中包含三對消息:
· 第一對叫SA交換,是協商確認有關安全策略的過程。
· 第二對消息叫密鑰交換,交換Diffie-Hellman公共值和輔助數據(如:隨機數),密鑰材料在這個階段產生。
· 最後一對消息是ID信息和認證數據交換,進行身份認證和對整個第一階段交換內容的認證。
野蠻模式交換與主模式交換的主要差別在於,野蠻模式不提供身份保護,隻交換3條消息。在對身份保護要求不高的場合,使用交換報文較少的野蠻模式可以提高協商的速度;在對身份保護要求較高的場合,則應該使用主模式。
· 因為有了IKE,IPSec很多參數(如:密鑰)都可以自動建立,降低了手工配置的複雜度。
· IKE協議中的DH交換過程,每次的計算和產生的結果都是不相關的。每次SA的建立都運行DH交換過程,保證了每個SA所使用的密鑰互不相關。
· IPSec使用AH或ESP報文頭中的序列號實現防重放。此序列號是一個32比特的值,此數溢出後,為實現防重放,SA需要重新建立,這個過程需要IKE協議的配合。
· 對安全通信的各方身份的認證和管理,將影響到IPSec的部署。IPSec的大規模使用,必須有CA(Certificate Authority,證書頒發機構)或其他集中管理身份數據的機構的參與。
· IKE提供端與端之間動態認證。
圖1-2 IPSec與IKE的關係圖
從上圖中我們可以看出IKE和IPSec的關係:
· IKE是UDP之上的一個應用層協議,是IPSec的信令協議。
· IKE為IPSec協商建立SA,並把建立的參數及生成的密鑰交給IPSec。
· IPSec使用IKE建立的SA對IP報文加密或認證處理。
與IKE相關的協議規範有:
· RFC2408:Internet Security Association and Key Management Protocol (ISAKMP)
· RFC2409:The Internet Key Exchange (IKE)
· RFC2412:The OAKLEY Key Determination Protocol
進行IKE配置之前,用戶需要確定以下幾個因素,以便配置過程的順利進行。
· 確定IKE交換過程中算法的強度,即確定安全保護的強度(包括身份認證方法、加密算法、認證算法、DH組):不同的算法的強度不同,算法強度越高,受保護數據越難被破解,但消耗的計算資源越多。一般來說,密鑰越長的算法強度越高。
· 確定通信雙方預先約定的預共享密鑰或所屬的PKI域。關於PKI的配置請參見“認證 > 證書管理”。
表1-1 IKE配置步驟
設置IKE本端名稱和NAT Keepalive報文時間間隔參數 |
||
當IKE對等體中需要指定IKE安全提議時必選 IKE安全提議定義了一套屬性數據來描述IKE協商怎樣進行安全通信。用戶可以創建多條不同優先級(由IKE安全提議號表示)的IKE安全提議 協商雙方必須至少有一條匹配的IKE提議才能協商成功。在進行IKE協商時,協商發起方會將自己的安全提議發送給對端,由對端進行匹配,協商響應方則從自己優先級最高(序號最小)的IKE安全提議開始,按照優先級順序與對端發送的安全提議進行匹配,直到找到一個匹配的安全提議來使用。匹配的IKE安全提議將被用來建立安全隧道 IKE安全提議的匹配原則是:協商雙方具有相同的加密算法、認證方法、認證算法和DH組;匹配的IKE安全提議的ISAKMP SA生存周期取兩端的最小值 缺省情況下,係統提供一條缺省的IKE安全提議,此缺省的IKE安全提議具有最低的優先級,具有缺省的參數如下: · DH組:Group1 · SA生存周期:86400秒 |
||
DPD(Dead Peer Detection,對等體存活檢測)用於IKE對等體存活狀態的檢測。啟用DPD功能後,當本端需要向對端發送IPSec報文時,若判斷當前距離最後一次收到對端IPSec報文已經超過觸發DPD的時間間隔,則觸發DPD查詢,本端主動向對端發送DPD請求報文,對IKE對等體是否存活進行檢測。如果本端在指定的等待DPD響應報文的時間內未收到對端發送的DPD響應報文,則重傳DPD請求,缺省重傳兩次之後,若仍然沒有收到對端的DPD響應報文,則刪除該IKE SA和對應的IPSec SA |
||
創建並配置IPSec IKE對等體的相關參數 若已存在的IPSec IKE對等體的配置發生了修改,則要分別在“VPN > IPSec > 安全聯盟”頁麵和“VPN > IKE > 安全聯盟”頁麵單擊<清空>按鈕,來刪除原有的IPSec SA與ISAKMP SA,否則會導致重新協商SA失敗 |
||
查看當前ISAKMP SA的概要信息 |
(1) 在導航欄中選擇“VPN > IKE”,默認進入IKE全局設置的頁麵,如下圖所示。
(2) 配置IKE全局參數,詳細配置如下表所示。
(3) 單擊<確定>按鈕完成操作。
表1-2 IKE全局參數的詳細配置
IKE本端名稱 |
當IKE協商的發起端使用FQDN (Fully Qualified Domain Name,完全合格域名)或者User FQDN類型的安全網關名稱進行協商時,本端需要設置此參數,發起端會發送自己的“IKE本端名稱”給對端來標識自己的身份,而對端使用“對端網關名稱”參數來認證發起端,故此時“對端網關名稱”應與發起端上的“IKE本端名稱”保持一致 缺省情況下,使用設備名作為IKE本端名稱 |
NAT Keepalive報文時間間隔 |
設置ISAKMP SA向對端發送NAT Keepalive報文的時間間隔 由於在NAT網關上的NAT映射會話有一定存活時間,因此一旦安全隧道建立後如果長時間沒有報文穿越,NAT會話表項會被刪除,這樣將導致在NAT外側的隧道無法繼續傳輸數據。為防止NAT表項老化,ISAKMP SA以一定的時間間隔向對端發送NAT Keepalive報文,以維持NAT會話的存活 |
(1) 在導航欄中選擇“VPN > IKE”。
(2) 單擊“安全提議”頁簽,進入IKE安全提議的顯示頁麵,如下圖所示。
(3) 單擊<新建>按鈕,進入新建IKE安全提議的配置頁麵,如下圖所示。
圖1-5 新建IKE安全提議
(4) 配置IKE安全提議的參數,詳細配置如下表所示。
(5) 單擊<確定>按鈕完成操作。
表1-3 新建IKE安全提議的詳細配置
IKE安全提議號 |
設置IKE安全提議的序號 該序號同時表示該IKE安全提議的優先級,數值越小,優先級越高,即在進行IKE協商的時候,會從序號最小的IKE安全提議進行匹配 |
設置IKE安全提議所采用的認證方法 · Preshared Key:采用預共享密鑰的認證方法 · RSA Signature:采用RSA數字簽名的認證方法 |
|
設置IKE安全提議所采用的認證算法 · SHA1:采用HMAC-SHA1認證算法 · MD5:采用HMAC-MD5認證算法 |
|
設置IKE安全提議所采用的加密算法 · DES-CBC:采用CBC模式的DES算法,采用56 bits的密鑰進行加密 · 3DES-CBC:采用CBC模式的3DES算法,采用168 bits的密鑰進行加密 · AES-128:采用CBC模式的AES算法,采用128 bits的密鑰進行加密 · AES-192:采用CBC模式的AES算法,采用192 bits的密鑰進行加密 · AES-256:采用CBC模式的AES算法,采用256 bits的密鑰進行加密 |
|
DH組 |
設置IKE階段1密鑰協商時所采用的DH密鑰交換參數 · Group1:采用768-bit的Diffie-Hellman組 · Group2:采用1024-bit的Diffie-Hellman組 · Group5:采用1536-bit的Diffie-Hellman組 · Group14:采用2048-bit的Diffie-Hellman組 |
SA生存周期 |
設置IKE安全提議的ISAKMP SA生存周期 在設定的生存周期超時前,會提前協商另一個SA來替換舊的SA。在新的SA還沒有協商完之前,依然使用舊的SA;在新的SA建立後,將立即使用新的SA,而舊的SA在生存周期超時後,被自動清除 如果SA生存周期超時,ISAKMP SA將自動更新。因為IKE協商需要進行DH計算,在低端設備上需要經過較長的時間,為使ISAKMP SA的更新不影響安全通信,建議設置SA生存周期大於10分鍾 |
(1) 在導航欄中選擇“VPN > IKE”。
(2) 單擊“DPD”頁簽,進入DPD的顯示頁麵,如下圖所示。
(3) 單擊<新建>按鈕,進入新建IKE DPD的配置頁麵,如下圖所示。
(4) 配置IKE DPD的參數,詳細配置如下表所示。
(5) 單擊<確定>按鈕完成操作。
表1-4 新建IKE DPD的詳細配置
DPD名稱 |
設置IKE DPD的名稱 |
觸發DPD時間間隔 |
設置經過多長時間沒有從對端收到IPSec報文,則觸發DPD |
等待DPD響應報文的時間 |
設置經過多長時間沒有收到DPD響應報文,則重傳DPD報 |
(1) 在導航欄中選擇“VPN > IKE”。
(2) 單擊“對等體”頁簽,進入IKE對等體的顯示頁麵,如下圖所示。
(3) 單擊<新建>按鈕,進入新建IKE對等體的配置頁麵,如下圖所示。
圖1-9 新建IKE對等體
(4) 配置IKE對等體的參數,詳細配置如下表所示。
(5) 單擊<確定>按鈕完成操作。
表1-5 新建IKE對等體的詳細配置
設置IKE對等體的名稱 |
|
設置IKE第一階段的協商模式為Main或Aggressive · 當安全隧道一端的IP地址為自動獲取時,必須將協商模式配置為“Aggressive”。這種情況下,隻要建立安全聯盟時使用的用戶名和密碼正確,就可以建立安全聯盟 · IKE對等體中配置的協商模式表示本端作為發起方時所使用的協商模式,響應方將自動適配發起方的協商模式 |
|
本端ID類型 |
設置IKE第一階段的協商過程中使用的本端ID的類型 · IP地址:表示選擇IP地址作為IKE協商過程中使用的ID · FQDN:表示選擇FQDN(Fully Qualified Domain Name,完全合格域名)類型的名稱作為IKE協商過程中使用的ID。此時,為保證IKE協商成功,建議IKE本端名稱配置為不攜帶@字符的字符串,例如foo.bar.com · User FQDN:表示選擇User FQDN類型的名稱作為IKE協商過程中使用的ID。此時,為保證IKE協商成功,建議IKE本端名稱配置為攜帶@字符的字符串,例如[email protected] 當協商模式為“Main”時,隻能使用IP地址類型的身份進行IKE協商,建立安全聯盟 |
本端IP地址 |
設置IKE協商時的本端安全網關的IP地址 缺省情況下,本端IP地址使用應用安全策略的接口的主地址。隻有當用戶需要指定特殊的本端安全網關地址時才需要設置此配置項 一般情況下本端IP地址不需要配置,隻有當用戶需要指定特殊的本端安全網關地址時(如指定loopback接口地址)才需要配置。而發起方的對端安全網關名稱或對端安全網關IP地址需要配置,它們用於發起方在協商過程中尋找對端 |
設置IPSec隧道對端安全網關的地址,可以是IP地址或主機名 · IP地址:對端網關的IP地址可以是一個IP地址,也可以是一個IP地址範圍。若本端為IKE協商的發起端,則此配置項所配的IP地址必須唯一,且與響應端的“本端IP地址”保持一致;若本端為IKE協商的響應端,則此配置項所配的IP地址必須包含發起端的“本端IP地址” · 主機名:對端網關的主機名是IPSec對端在網絡中的唯一標識,可被DNS服務器解析為IP地址。采用主機名方式時,本端可以作為IKE協商的發起端 |
|
設置IKE協商時,對端的安全網關名稱 當IKE協商的發起端配置了本端ID類型為“FQDN”或“User FQDN”時,發起端會發送自己的IKE本端名稱給對端來標識自己的身份,而對端使用對端網關名稱來認證發起端,故此時對端網關名稱應與發起端上的IKE本端名稱保持一致 |
|
根據IKE安全提議中設置的認證方法選擇二者中的一個配置 · 若認證方法設置為“Preshared Key”,則這裏選擇“預共享密鑰”,即設置IKE協商采用預共享密鑰認證時所使用的預共享密鑰,輸入的密鑰和確認密鑰必須一致 · 若認證方法”置為“RSA Signature”,則這裏選擇“PKI域”,即設置IKE協商采用數字簽名認證時,證書所屬的PKI域。可選的PKI域在“VPN > 證書管理”中配置 |
|
PKI域 |
|
啟用DPD功能 |
設置為IKE對等體應用一個IKE DPD |
啟用NAT穿越 |
設置IPSec/IKE的NAT穿越功能 在IPSec/IKE組建的VPN隧道中,若存在NAT安全網關設備,則必須配置IPSec/IKE的NAT穿越功能 為了節省IP地址空間,ISP經常會在公網中加入NAT網關,以便於將私有IP地址分配給用戶。此時可能會導致IPSec/IKE隧道的兩端一端為公網地址,另一端為私網地址。所以,必須在私網側啟用NAT穿越,保證隧道能夠正常協商建立 |
(1) 在導航欄中選擇“VPN > IKE”。
(2) 單擊“安全聯盟”頁簽,進入ISAKMP SA概要信息的顯示頁麵,如下圖所示。
單擊頁麵上的<清空>按鈕,可以刪除當前所有的ISAKMP SA。需要注意的是,當清除本地的IPSec SA時,如果相應的ISAKMP SA還存在,將在此ISAKMP SA的保護下,向對端發送刪除消息,通知對方清除相應的IPSec SA;否則,無法通知對端清除相應的IPSec SA。
IKE安全聯盟列表的詳細說明如下表所示。
表1-6 IKE安全聯盟列表的詳細說明
顯示ISAKMP SA的標識符 |
|
對端IP地址 |
|
· RD(READY):表示此安全聯盟已建立成功 · ST(STAYALIVE):表示此端是隧道協商發起方 · RL(REPLACED):表示此隧道已經被新的隧道代替,一段時間後將被刪除 · FD(FADING):表示此隧道已發生過一次軟超時,目前還在使用,在硬超時發生時,會刪除此隧道 · TO(TIMEOUT):表示此安全聯盟在上次Keepalive超時發生後還沒有收到Keepalive報文,如果在下次Keepalive超時發生時仍沒有收到Keepalive報文,此安全聯盟將被刪除 IKE通過Keepalive報文維護ISAKMP SA的鏈路狀態。一般在對端配置了等待Keepalive報文的超時時間後,必須在本端配置此Keepalive報文發送時間間隔。當對端在配置的超時時間內未收到此Keepalive報文時,如果該ISAKMP SA帶有TIMEOUT標記,則刪除該ISAKMP SA以及由其協商的IPSec SA;否則,將其標記為TIMEOUT |
|
· 在AC 1和AC 2之間建立一個安全隧道,對Host 1所在的子網(10.1.1.0/24)與Host 2所在的子網(10.1.2.0/24)之間的數據流進行安全保護。
· 在AC 1上配置一條IKE提議,其提議號為10,使用的認證算法為MD5。AC 2使用缺省的IKE提議。
圖1-11 IKE配置組網圖
(1) 配置各接口的IP地址和所屬安全域。(略)
(2) 配置ACL 3101,定義由子網10.1.1.0/24去子網10.1.2.0/24的數據流。
步驟1:在導航欄中選擇“QoS > ACL IPv4”。
步驟2:單擊“新建”頁簽。
步驟3:如下圖所示,輸入訪問控製列表ID為“3101”,選擇匹配規則為“用戶配置”。
步驟4:單擊<應用>按鈕完成操作。
步驟5:單擊“高級配置”頁簽。
步驟6:進行如下配置,如下圖所示。
· 訪問控製列表選擇“3101”。
· 選中“源IP地址”前的複選框,輸入源IP地址為“10.1.1.0”,輸入源地址通配符為“0.0.0.255”。
· 選中“目的IP地址”前的複選框,輸入目的IP地址為“10.1.2.0”,輸入目的地址通配符為“0.0.0.255”。
步驟7:單擊<新建>按鈕完成操作。
圖1-13 配置允許由子網10.1.1.0/24去子網10.1.2.0/24數據流的規則
(3) 配置IKE對等體peer。
步驟1:在導航欄中選擇“VPN > IKE”,單擊“對等體”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置,如下圖所示。
· 輸入對等體名稱為“peer”。
· 選擇協商模式為“Main”。
· 輸入對端網關IP地址為“2.2.2.2”。
· 選中“預共享密鑰”前的單選按鈕,輸入密鑰為“abcde”,並在確認密鑰中再次輸入該密鑰。
步驟4:單擊<確定>按鈕完成操作。
圖1-14 配置IKE對等體
(4) 創建一條IKE安全提議10。
步驟1:在導航欄中選擇“VPN > IKE”,單擊“安全提議”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置,如下圖所示。
· 輸入IKE安全提議號為“10”。
· 選擇認證算法為“MD5”。
· 輸入SA生存周期為“5000”秒。
步驟4:單擊<確定>按鈕完成操作。
圖1-15 創建一條IKE安全提議10
(5) 配置名為tran1的IPSec安全提議。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽。
步驟2:單擊<新建>按鈕,進入安全提議配置向導頁麵。
步驟3:單擊“定製方式”。
步驟4:進行如下配置,如下圖所示。
· 輸入安全提議名稱為“tran1”。
· 選擇報文封裝模式為“Tunnel”。
· 選擇安全協議為“ESP”。
· 選擇ESP認證算法為“SHA1”。
· 選擇ESP加密算法為“DES”。
步驟5:單擊<確定>按鈕完成操作。
圖1-16 配置名為tran1的IPSec安全提議
(6) 配置名為map1的IPSec安全策略。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“策略”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置,如下圖所示。
· 輸入策略名稱為“map1”。
· 選擇IKE對等體為“peer”。
· 選中名為“tran1”的IPSec安全提議,單擊“<<”按鈕。
· 輸入ACL為“3101”。
步驟4:單擊<確定>按鈕完成操作。
圖1-17 配置IPSec安全策略
(7) 在接口Vlan-interface1上應用IPSec安全策略map1。
步驟1:在導航欄中選擇“VPN > IPSec ”,默認進入“ 應用”頁簽的頁麵。
步驟2:單擊接口“Vlan-interface1”對應的圖標。
步驟3:如下圖所示,選擇策略名稱為“map1”。
步驟4:單擊<確定>按鈕完成操作。
圖1-18 在接口Vlan-interface1上應用IPSec安全策略
(8) 配置到Host 2的靜態路由。
步驟1:在導航欄中選擇“網絡 > IPv4路由”。
步驟2:單擊“創建”頁簽。
步驟3:進行如下配置,如下圖所示。
· 輸入目的IP地址為“10.1.2.0”。
· 輸入下一跳為“2.2.2.2”。
步驟4:單擊<確定>按鈕完成操作。
圖1-19 配置到Host 2的靜態路由
(1) 配置各接口的IP地址和所屬安全域。(略)
(2) 配置ACL 3101,定義由子網10.1.2.0/24去子網10.1.1.0/24的數據流。
步驟1:在導航欄中選擇“QoS > ACL IPv4”。
步驟2:單擊“新建”頁簽。
步驟3:輸入訪問控製列表ID為“3101”,選擇匹配規則為“用戶配置”。
步驟4:單擊<應用>按鈕完成操作。
步驟5:單擊“高級配置”頁簽。
步驟6:進行如下配置。
· 選中“源IP地址”前的複選框,輸入源IP地址為“10.1.2.0”,輸入源地址通配符為“0.0.0.255”。
· 選中“目的IP地址”前的複選框,輸入目的IP地址為“10.1.1.0”,輸入目的地址通配符為“0.0.0.255”。
步驟7:單擊<新建>按鈕完成操作。
(3) 配置IKE對等體。
步驟1:在導航欄中選擇“VPN > IKE”,單擊“對等體”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置。
· 輸入對等體名稱為“peer”。
· 選擇協商模式為“Main”。
· 輸入對端網關IP地址為“1.1.1.1”。
· 選中“預共享密鑰”前的單選按鈕,輸入密鑰為“abcde”,並在確認密鑰中再次輸入該密鑰。
步驟4:單擊<確定>按鈕完成操作。
(4) 配置名為tran1的IPSec安全提議。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽。
步驟2:單擊<新建>按鈕,進入安全提議配置向導頁麵。
步驟3:單擊“定製方式”。
步驟4:進行如下配置。
· 輸入安全提議名稱為“tran1”。
· 選擇報文封裝模式為“Tunnel”。
· 選擇安全協議為“ESP”。
· 選擇ESP認證算法為“SHA1”。
· 選擇ESP加密算法為“DES”。
步驟5:單擊<確定>按鈕完成操作。
(5) 配置名為map1的IPSec安全策略。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“策略”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置。
· 輸入策略名稱為“map1”。
· 選擇IKE對等體為“peer”。
· 選中名為“tran1”的IPSec安全提議,單擊“<<”按鈕。
· 輸入ACL為“3101”。
步驟4:單擊<確定>按鈕完成操作。
(6) 在接口Vlan-interface1上應用IPSec安全策略map1。
步驟1:在導航欄中選擇“VPN > IPSec”,默認進入“應用”頁簽的頁麵。
步驟2:單擊接口“Vlan-interface1”對應的圖標。
步驟3:選擇策略名稱為“map1”。
步驟4:單擊<確定>按鈕完成操作。
(7) 配置到Host 1的靜態路由。
步驟1:在導航欄中選擇“網絡> IPv4路由”。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置。
· 輸入目的IP地址為“10.1.1.0”。
· 輸入下一跳為“1.1.1.1”。
步驟4:單擊<確定>按鈕完成操作。
以上配置完成後,AC 1和 AC 2之間如果有子網10.1.1.0/24與子網10.1.2.0/24之間的報文通過,將觸發IKE協商。由於AC 1上配置了IKE提議10,其中使用的認證算法為MD5,但AC 2上使用的是缺省的IKE提議,默認的認證算法為SHA。因此,在進行IKE提議匹配的時候,從優先級最高的提議開始匹配,因為AC 2上沒有和AC 1上提議10相匹配的IKE提議,所以雙方能夠匹配的隻有缺省的IKE提議。另外,在進行IKE提議匹配的時候,SA生存周期是不用進行匹配的,它由IKE協商雙方決定。
IPSec(IP Security,IP安全)是IETF製定的三層隧道加密協議,它為Internet上傳輸的數據提供了高質量的、可互操作的、基於密碼學的安全保證,是一種傳統的實現三層VPN(Virtual Private Network,虛擬專用網絡)的安全技術。特定的通信方之間通過建立IPSec隧道來傳輸用戶的私有數據,並在IP層提供了以下安全服務:
· 數據機密性(Confidentiality):IPSec發送方在通過網絡傳輸包前對包進行加密。
· 數據完整性(Data Integrity):IPSec接收方對發送方發送來的包進行認證,以確保數據在傳輸過程中沒有被篡改。
· 數據來源認證(Data Authentication):IPSec在接收端可以認證發送IPSec報文的發送端是否合法。
· 防重放(Anti-Replay):IPSec接收方可檢測並拒絕接收過時或重複的報文。
IPSec具有以下優點:
· 支持IKE(Internet Key Exchange,互聯網密鑰交換),可實現密鑰的自動協商功能,減少了密鑰協商的開銷。可以通過IKE建立和維護SA(Security Association,安全聯盟)的服務,簡化了IPSec的使用和管理。
· 所有使用IP協議進行數據傳輸的應用係統和服務都可以使用IPSec,而不必對這些應用係統和服務本身做任何修改。
· 對數據的加密是以數據包為單位的,而不是以整個數據流為單位,這不僅靈活而且有助於進一步提高IP數據包的安全性,可以有效防範網絡攻擊。
IPSec協議不是一個單獨的協議,它給出了應用於IP層上網絡數據安全的一整套體係結構,包括網絡認證協議AH(Authentication Header,認證頭)、ESP(Encapsulating Security Payload,封裝安全載荷)、IKE和用於網絡認證及加密的一些算法等。其中,AH協議和ESP協議用於提供安全服務,IKE協議用於密鑰交換。關於IKE的詳細介紹請參見“1 IKE”。
IPSec提供了兩種安全機製:認證和加密。認證機製使IP通信的數據接收方能夠確認數據發送方的真實身份以及數據在傳輸過程中是否遭篡改。加密機製通過對數據進行加密運算來保證數據的機密性,以防數據在傳輸過程中被竊聽。
AH協議和ESP協議的功能及工作原理如下:
· AH協議(IP協議號為51)定義了認證的應用方法,提供數據源認證、數據完整性校驗和防報文重放功能,它能保護通信免受篡改,但不能防止竊聽,適合用於傳輸非機密數據。AH的工作原理是在每一個數據包上添加一個身份驗證報文頭,此報文頭插在標準IP包頭後麵,對數據提供完整性保護。可選擇的認證算法有MD5(Message Digest)、SHA-1(Secure Hash Algorithm)等。
· ESP協議(IP協議號為50)定義了加密和可選認證的應用方法,提供加密、數據源認證、數據完整性校驗和防報文重放功能。ESP的工作原理是在每一個數據包的標準IP包頭後麵添加一個ESP報文頭,並在數據包後麵追加一個ESP尾。與AH協議不同的是,ESP將需要保護的用戶數據進行加密後再封裝到IP包中,以保證數據的機密性。常見的加密算法有DES、3DES、AES等。同時,作為可選項,用戶可以選擇MD5、SHA-1算法保證報文的完整性和真實性。
在實際進行IP通信時,可以根據實際安全需求同時使用這兩種協議或選擇使用其中的一種。AH和ESP都可以提供認證服務,不過,AH提供的認證服務要強於ESP。同時使用AH和ESP時,設備支持的AH和ESP聯合使用的方式為:先對報文進行ESP封裝,再對報文進行AH封裝,封裝之後的報文從內到外依次是原始IP報文、ESP頭、AH頭和外部IP頭。
IPSec在兩個端點之間提供安全通信,端點被稱為IPSec對等體。
SA是IPSec的基礎,也是IPSec的本質。SA是通信對等體間對某些要素的約定,例如,使用哪種協議(AH、ESP還是兩者結合使用)、協議的封裝模式(傳輸模式和隧道模式)、加密算法(DES、3DES和AES)、特定流中保護數據的共享密鑰以及密鑰的生存周期等。建立SA的方式有手工配置和IKE自動協商兩種。
SA是單向的,在兩個對等體之間的雙向通信,最少需要兩個SA來分別對兩個方向的數據流進行安全保護。同時,如果兩個對等體希望同時使用AH和ESP來進行安全通信,則每個對等體都會針對每一種協議來構建一個獨立的SA。
SA由一個三元組來唯一標識,這個三元組包括SPI(Security Parameter Index,安全參數索引)、目的IP地址、安全協議號(AH或ESP)。
SPI是用於唯一標識SA的一個32比特數值,它在AH和ESP頭中傳輸。在手工配置SA時,需要手工指定SPI的取值。使用IKE協商產生SA時,SPI將隨機生成。
通過IKE協商建立的SA具有生存周期,手工方式建立的SA永不老化。IKE協商建立的SA的生存周期有兩種定義方式:
· 基於時間的生存周期,定義了一個SA從建立到失效的時間。
· 基於流量的生存周期,定義了一個SA允許處理的最大流量。
生存周期到達指定的時間或指定的流量,SA就會失效。SA失效前,IKE將為IPSec協商建立新的SA。這樣,在舊的SA失效前新的SA就已經準備好。在新的SA開始協商而沒有協商好之前,繼續使用舊的SA保護通信。在新的SA協商好之後,則立即采用新的SA保護通信。
IPSec有如下兩種工作模式:
· 隧道(Tunnel)模式:用戶的整個IP數據包被用來計算AH或ESP頭,AH或ESP頭以及ESP加密的用戶數據被封裝在一個新的IP數據包中。通常,隧道模式應用在兩個安全網關之間的通訊。
· 傳輸(Transport)模式:隻是傳輸層數據被用來計算AH或ESP頭,AH或ESP頭以及ESP加密的用戶數據被放置在原IP包頭後麵。通常,傳輸模式應用在兩台主機之間的通訊,或一台主機和一個安全網關之間的通訊。
不同的安全協議在Tunnel和Transport模式下的數據封裝形式如下圖所示。
認證算法的實現主要是通過雜湊函數。雜湊函數是一種能夠接受任意長的消息輸入,並產生固定長度輸出的算法,該輸出稱為消息摘要。IPSec對等體計算摘要,如果兩個摘要是相同的,則表示報文是完整未經篡改的。IPSec使用兩種認證算法:
· MD5:MD5通過輸入任意長度的消息,產生128bit的消息摘要。
· SHA-1:SHA-1通過輸入長度小於2的64次方bit的消息,產生160bit的消息摘要。
MD5算法的計算速度比SHA-1算法快,而SHA-1算法的安全強度比MD5算法高。
加密算法實現主要通過對稱密鑰係統,它使用相同的密鑰對數據進行加密和解密。目前設備的IPSec實現三種加密算法:
· DES(Data Encryption Standard):使用56bit的密鑰對一個64bit的明文塊進行加密。
· 3DES(Triple DES):使用三個56bit的DES密鑰(共168bit密鑰)對明文進行加密。
· AES(Advanced Encryption Standard):使用128bit、192bit或256bit密鑰長度的AES算法對明文進行加密。
這三個加密算法的安全性由高到低依次是:AES、3DES、DES。安全性高的加密算法實現機製複雜,運算速度慢。對於普通的安全要求,DES算法就可以滿足需要。
· 手工方式:配置比較複雜,創建SA所需的全部信息都必須手工配置,而且不支持一些高級特性(例如定時更新密鑰),但優點是可以不依賴IKE而單獨實現IPSec功能。
· IKE自動協商方式:配置相對比較簡單,隻需要配置好IKE協商安全策略的信息,由IKE自動協商來創建和維護SA。
當與之進行通信的對等體設備數量較少時,或是在小型靜態環境中,手工配置SA是可行的。對於中、大型的動態網絡環境中,推薦使用IKE協商建立SA。
Web界麵目前隻支持配置IKE自動協商方式。
安全隧道是建立在本端和對端之間可以互通的一個通道,它由一對或多對SA組成。
如下圖所示,某企業在企業分支與企業總部之間的所有流量通過IPSec進行保護,當企業分支眾多時,企業總部網關需要配置大量靜態路由,將總部發往分支的數據引到應用IPSec策略的接口上來,另外,當企業分支內部網絡規劃發生變化時,同時需要調整總部網關上的靜態路由,工作量巨大且容易出現配置錯誤。
反向路由注入功能的出現,可以很好得解決這些問題。反向路由注入簡稱RRI(Reverse Route Injection),是一種自動添加到達IPSec VPN私網或IPSec隧道網關靜態路由的機製,可實現為受IPSec保護的流量自動添加靜態路由的功能。
如上IPSec VPN組網中,在總部網關設備Device A上配置RRI功能後,Device A上將自動添加一條到達分支所在私網網段192.168.2.0/24的路由,等價於在其上手工配置目的IP/掩碼為192.168.2.0/24、下一跳為2.2.2.2的靜態路由。
通過RRI創建的路由表項可以在路由表中查詢到,其目的地址為受保護的對端網絡,下一跳地址為IPSec隧道對端地址或指定的地址,它使得發往對端的流量將被強製通過IPSec加密後轉發。
RRI創建的靜態路由和手工配置的靜態路由一樣,可以向內網設備進行廣播,允許內網設備選擇合適的路由對IPSec VPN流量進行轉發。該功能在企業總部有多台網關設備的組網應用中,如進行負載均衡、雙機熱備的情況下,甚至是IPSec VPN流量通過默認網關無法到達對端網關設備的時候,都能及時生成新的路由來轉發IPSec VPN流量,因此非常有用。
在MPLS L3VPN組網環境中,配置了RRI的IPSec VPN網關設備能夠依據應用IPSec策略的接口所綁定的VPN實例,在相應VPN實例的IP路由表中添加靜態路由。
在大規模組網中,這種自動添加靜態路由的機製可以簡化用戶配置,減少在企業總部網關上配置靜態路由的工作量,並且可以根據IPSec SA的創建和刪除進行靜態路由的動態增加和刪除,大大增強VPN網絡的可擴展性。
本特性的支持情況與設備的型號有關,請參見“特性差異列表”的“特性差異情況”部分的介紹。
IPSec雙機熱備功能利用雙機熱備機製實現了兩台設備之間IPSec業務數據的熱備份。互為熱備份的兩台設備(通常為企業中心網關設備)加入同一個備份組,形成一台虛擬設備,對端設備(通常為企業分支網關設備)通過該虛擬設備的虛擬IP地址與其通信。當主設備出現故障時,利用VRRP機製將IPSec業務流量切換到備份設備上繼續進行IPSec處理和轉發,整個流量切換過程對於遠端設備而言完全透明,不需要遠端設備添加任何額外的配置。流量切換後也不需要進行IPSec重協商,避免了因IPSec重協商導致的IPSec流量長時間中斷。
IPSec雙機熱備功能隻能采用VRRP標準協議模式,即同一時間僅由其中一台設備(主設備)處理以及轉發所有的IPSec流量,並負責將產生的IPSec業務數據同步給另外一台設備(備份設備),而另外一台設備不處理任何IPSec流量。當主設備出現故障時,才由備份設備接替主設備處理業務並轉發IPSec流量。
圖2-3 IPSec雙機熱備組網圖
如上圖所示,設備A與設備B通過備份鏈路組成雙機熱備係統,其中設備A通過VRRP機製被選舉為主設備。當設備A正常工作時,它與遠端的設備C之間建立IPSec隧道,並通過備份鏈路將IPSec業務數據同步到設備B上,實現IPSec業務數據在兩台設備上的共享。被同步的IPSec業務數據包括IKE SA、IPSec SA、SA防重放序號和防重放窗口、SA字節生命周期、DPD報文序號等。此時,在設備A上協商生成的IKE SA和IPSec SA均稱為主用IKE SA和主用IPSec SA。在設備B上,接收到備份信息生成的IKE SA和IPSec SA被稱為備份IKE SA和備份IPSec SA。當設備A發生故障後,由VRRP機製實現業務流量的切換,由於設備B上保存了設備A上同步過來的IPSec業務數據,因此設備B可立即替代設備A繼續處理IPSec業務,減少了因流量中斷而帶來的損失。
與IPSec相關的協議規範有:
· RFC2401:Security Architecture for the Internet Protocol
· RFC2402:IP Authentication Header
· RFC2406:IP Encapsulating Security Payload
· RFC4552:Authentication/Confidentiality for OSPFv3
· RFC4301:Security Architecture for the Internet Protocol
· RFC4302:IP Authentication Header
· RFC4303:IP Encapsulating Security Payload (ESP)
通過Web可以配置基於ACL(Access Control List,訪問控製列表)建立IPSec安全隧道,即由ACL來指定要保護的數據流範圍,通過配置安全策略並將安全策略綁定在實際的物理接口上來完成IPSec的配置。這種方式可以利用ACL的豐富配置功能,結合實際的組網環境靈活製定IPSec安全策略。
基於ACL建立IPsec安全隧道的基本配置思路如下:
(1) 通過配置ACL,用於匹配需要保護的數據流。
(2) 通過配置IPsec安全提議,指定報文封裝模式、安全協議、認證算法和加密算法。
(3) 通過配置IPsec安全策略,將要保護的數據流和IPsec安全提議進行關聯(即定義對何種數據流實施何種保護),並指定SA的協商方式、對等體IP地址(即保護路徑的起/終點)、所需要的密鑰和SA的生存周期等。
(4) 最後在設備接口上應用IPsec安全策略即可完成IPSec隧道的配置。
表2-1 IPSec配置步驟
ACL是用來實現流識別功能的。網絡設備為了過濾報文,需要配置一係列的匹配條件對報文進行分類,當設備的端口接收到報文後,即根據當前端口上應用的ACL規則對報文進行分析、識別之後,根據預先設定的策略對報文進行不同的處理 |
||
安全提議用於保存IPSec需要使用的特定安全協議、加密/認證算法以及封裝模式,為IPSec協商SA提供各種安全參數 若已存在的IPSec安全提議的配置發生了修改,則對已協商成功的SA,新修改的安全提議並不起作用,即SA仍然使用原來的IPSec安全提議,隻有新協商的SA將使用新的IPSec安全提議 |
||
名稱相同 的所有安全策略模板稱為一個安全策略模板組。其中,序號越小的安全策略模板,優先級越高。在配置安全策略時,可以直接引用安全策略模板組來創建安全策略 |
||
Web界麵采用IKE方式來配置安全策略,在配置時可以直接設置策略中的參數,也可以通過引用已創建的安全策略模板組來配置 名稱相同的所有安全策略稱為一個安全策略組。其中,序號越小的安全策略,優先級越高 不能用應用安全策略模板的安全策略來發起安全聯盟的協商,但可以響應協商。在協商過程中進行策略匹配時,策略模板中定義的參數必須相符,而策略模板中沒有定義的參數由發起方來決定,響應方接受發起方的建議 |
||
查看所有IPSec安全聯盟的概要信息,通過查看顯示信息驗證配置效果 |
||
查看IPSec處理報文的統計信息,通過查看IPSec的運行情況驗證配置效果 |
· ACL的配置請參見“QoS > ACL IPv4”和“QoS > ACL IPv6”。
· 若在接口上同時使能IPSec和QoS,同一個IPsec安全聯盟的數據流如果被QoS分類進入不同隊列,會導致部分報文發送亂序。由於IPSec具有防重放功能,IPSec入方向上對於防重放窗口之外的報文會進行丟棄,從而導致丟包現象。因此當IPSec與QoS結合使用時,必須保證IPSec分類與QoS分類規則配置保持一致。IPSec的分類規則完全由引用的ACL規則確定,QoS分類規則的配置請參考“QoS”。
IPSec通過配置ACL來定義需要過濾的數據流。在IPSec的應用中,操作為“允許”的ACL規則表示與之匹配的流量需要被IPSec保護,而操作為“禁止”的ACL規則表示與之匹配的那些流量不需要保護。一個ACL中可以配置多條規則,首個與數據流匹配上的規則決定了對該數據流的處理方式,如果該規則為“允許”,則該規則就定義了需要建立SA來保護的數據流量的範圍。
在IPSec策略中定義的ACL既可用於過濾接口入方向數據流,也可用於過濾接口出方向數據流。
· 設備出入方向的數據流都使用IPSec策略中定義的ACL規則來做匹配依據。具體是,出方向的數據流正向匹配ACL規則,入方向的數據流反向匹配ACL規則。例如,對於應用於IPSec策略中的某ACL規則:規則的具體配置如下圖所示,設備使用其正向過濾出方向上從1.1.1.0/24網段到2.2.2.0/24網段的數據流,反向過濾入方向上從2.2.2.0/24網段到1.1.1.0/24網段的數據流。
圖2-4 應用於IPSec策略中的某ACL規則
· 在出方向上,與ACL的“允許”規則匹配的報文將被IPSec保護,未匹配上任何規則或與“禁止”規則匹配上的報文將不被IPSec保護。
· 在入方向上,與ACL的“允許”規則匹配上的IPSec報文將被接收並處理,與ACL的“允許”規則匹配上的普通IP報文將被丟棄。
· 僅對確實需要IPSec保護的數據流配置“允許”規則,否則,一旦指定範圍上入方向收到的某流量是未被IPSec保護的,那麼該流量就會被丟棄,這會造成一些本不需要IPSec處理的流量丟失,影響正常的業務流傳輸。
· 合理使用“拒絕”規則,尤其是在一個安全策略下有多條優先級不同的子安全策略時,避免本應該與優先級較低的子安全策略的AC“允許”規則匹配而被IPSec保護的出方向報文,因為先與優先級較高的子安全策略的ACL“拒絕”規則匹配上,而在接收端被當作未被IPSec保護的報文丟棄。
“拒絕”規則的錯誤配置示例:(以下配置信息僅截取了ACL的相關內容,其它步驟省略)
Device A連接的1.1.2.0/24網段到Device B連接的3.3.3.0/24網段之間的報文,在應用了IPSec策略test的出接口上,優先與順序號為1的安全策略進行匹配,並匹配上了ACL 3000的rule 1 deny ip,因此Device A認為它不需要IPSec保護,到達Device B後將被丟棄。
Device A上的配置如圖2-5、圖2-6和圖2-7所示。
圖2-5 Device A上的ACL 3000配置
圖2-6 Device A上的ACL 3001配置
圖2-7 Device A上的IPSec安全策略配置
圖2-8 Device B上的ACL 3001配置
圖2-9 Device B上的IPSec安全策略配置
為保證SA的成功建立,建議將IPSec對等體上的訪問控製列表鏡像配置,即保證兩端要保護的數據流範圍是鏡像的。例如,下圖中Device A和Device B上的ACL配置都是完全鏡像對稱的,因此用於保護主機Host A與主機Host C之間、子網Network 1與子網Network 2之間流量的SA均可成功建立。
若IPSec對等體上的訪問控製列表配置非鏡像,那麼隻有一種情況下,SA的協商是可以建立的。這種情況就是,一端的訪問控製列表規則定義的範圍是另外一端的子集。如下圖所示,Device A上的訪問控製列表允許的範圍(Host A->Host C)是Device B上訪問控製列表(Network 2->Network 1)的子集。
但需要注意的是,在這種ACL配置下,並不是任何一端發起的SA協商都可以成功,僅當保護範圍小(細粒度)的一端向保護範圍大(粗粒度)的一端發起的協商才能成功,反之則協商失敗。這是因為,協商響應方要求協商發起方發送過來的數據必須在響應方可以接受的範圍之內。其結果就是,從細粒度一端向粗粒度一端發起的協商是可以成功的,例如Host A->Host C;從粗粒度一方向細粒度一方發起的協商是不能成功的,例如Host C->Host B、Host D->Host A等。
· 標準方式:一條隧道保護一條數據流。ACL中的每一個規則對應的數據流都會由一條單獨創建的隧道來保護。
· 聚合方式:一條隧道保護ACL中定義的所有數據流。ACL中的所有規則對應的數據流隻會由一條創建的隧道來保護。該方式僅在IKE協商安全策略的情況下可配。
Web網管提供了兩種IPSec安全提議的配置方式:
· 套件方式:用戶可以直接在設備提供的加密套件中選擇一種,方便用戶的操作。
(1) 在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽,進入IPSec安全提議的顯示頁麵,如下圖所示。
(2) 單擊<新建>按鈕,進入IPSec安全提議的配置向導頁麵,如下圖所示。
圖2-13 IPSec安全提議配置向導
圖2-14 新建IPSec安全提議(套件方式)
(4) 輸入要新建的IPSec安全提議的名稱。
(5) 選擇安全提議采用的報文封裝、安全協議及對應的認證/加密算法的套件。可選的加密套件有以下幾種,其中“Tunnel”表示報文封裝模式為隧道模式,其餘參數的含義將在下麵分別進行介紹:
· Tunnel-ESP-DES-MD5:采用ESP協議,ESP加密算法為DES,ESP認證算法為MD5。
· Tunnel-ESP-3DES-MD5:采用ESP協議,ESP加密算法為3DES,ESP認證算法為MD5。
· Tunnel-AH-MD5-ESP-DES:先用ESP協議對報文進行保護,再用AH協議進行保護,AH認證算法為MD5,ESP加密算法為DES,不進行ESP認證。
· Tunnel-AH-MD5-ESP-3DES:先用ESP協議對報文進行保護,再用AH協議進行保護,AH認證算法為MD5,ESP加密算法為3DES,不進行ESP認證。
(6) 單擊<確定>按鈕完成操作。
(1) 在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽,進入IPSec安全提議的顯示頁麵,如圖2-12所示。
(2) 單擊<新建>按鈕,進入IPSec安全提議的配置向導頁麵,如圖2-13所示。
圖2-15 新建IPSec安全提議(定製方式)
(4) 配置IPSec安全提議的參數,詳細配置如下表所示。
(5) 單擊<確定>按鈕完成操作。
表2-2 新建IPSec安全提議的詳細配置
設置要新建的IPSec安全提議的名稱 |
|
設置安全協議對IP報文的封裝模式 · Tunnel:表示采用隧道模式 · Transport:表示采用傳輸模式 |
|
· AH:表示采用AH協議 · ESP:表示采用ESP協議 · AH-ESP:表示先用ESP協議對報文進行保護,再用AH協議進行保護 |
|
AH認證算法 |
當安全協議選擇AH或AH-ESP時,設置AH協議采用的認證算法 可選的認證算法有MD5和SHA1(表示SHA-1算法) |
ESP認證算法 |
當安全協議選擇ESP或AH-ESP時,設置ESP協議采用的認證算法 可選的認證算法有MD5和SHA1(表示SHA-1算法),選擇空表示不進行ESP認證 ESP認證算法和ESP加密算法不能同時設置為空 |
ESP加密算法 |
當安全協議選擇ESP或AH-ESP時,設置ESP協議采用的加密算法 · DES:表示采用DES算法,采用56bits的密鑰進行加密 · 3DES:表示采用3DES算法,采用168bits的密鑰進行加密 · AES128:表示采用AES算法,采用128bits的密鑰進行加密 · AES192:表示采用AES算法,采用192bits的密鑰進行加密 · AES256:表示采用AES算法,采用256bits的密鑰進行加密 · 選擇空表示不進行ESP加密 · 對於保密及安全性要求非常高的地方,采用3DES算法可以滿足需要,但3DES加密速度比較慢;對於普通的安全要求,DES算法就可以滿足需要 · ESP認證算法和ESP加密算法不能同時設置為空 |
(1) 在導航欄中選擇“VPN > IPSec”,單擊“模板配置”頁簽,進入安全策略模板的顯示頁麵,如下圖所示。
(2) 單擊<新建>按鈕,進入新建安全策略模板的配置頁麵,如下圖所示。
(4) 單擊<確定>按鈕完成操作。
IKE對等體 |
設置安全策略模板所引用的IKE對等體名稱 可選的IKE對等體需先在“VPN > IKE > 對等體”中創建 |
|
IPSec安全提議 |
設置安全策略模板所引用的IPSec安全提議名稱,最多可以引用6個 IKE協商將在安全隧道的兩端搜索能夠完全匹配的IPSec安全提議,如果找不到,則SA不能建立,需要被保護的報文將被丟棄 |
|
設置使用此安全策略發起協商時是否使用PFS(Perfect Forward Secrecy,完善的前向安全性)特性,並指定采用的Diffie-Hellman組: · DH Group1:表示采用768-bit Diffie-Hellman組 · DH Group2:表示采用1024-bit Diffie-Hellman組 · DH Group5:表示采用1536-bit Diffie-Hellman組 · DH Group14:表示采用2048-bit Diffie-Hellman組 · DH Group14、DH Group5、DH Group2、DH Group1的安全性和需要的計算時間依次遞減 · IPSec在使用配置了PFS的安全策略發起一個協商時,在階段2的協商中進行一次附加的密鑰交換以提高通訊的安全性 · 本端和對端指定的Diffie-Hellman組必須一致,否則協商會失敗 |
||
指定的ACL必須已經存在,且至少要包含一條規則 可支持保護VPN實例間的數據流 |
||
SA生存周期 |
設置安全策略的SA生存周期,可以選擇基於時間和基於流量 IKE為IPSec協商建立安全聯盟時,采用本地配置的生存周期和對端提議的生存周期中較小的一個 |
|
設置開啟或關閉反向路由注入功能,啟用反向路由注入時可以配置下一跳和優先級 啟用反向路由注入功能後,可以隨IPSec SA的建立自動生成到達IPSec VPN私網或隧道網關的靜態路由,減少手工靜態路由的配置 · 本端設備啟用反向路由注入後,可以不配置到對端的路由。此時,隻能由對端發起SA協商。協商成功後,本端會生成到達對端私網的靜態路由 · 反向路由注入功能動態生成的靜態路由隨IPSec SA的創建而創建,隨IPSec SA的刪除而刪除 · 反向路由注入生成的靜態路由可以在“網絡管理 > 路由管理 > 路由信息”中查看 |
||
不指定此項時,使用本端在IPSec SA協商過程中學習到的隧道的對端地址作為下一跳 |
||
(1) 在導航欄中選擇“VPN > IPSec”,單擊“策略”頁簽,進入安全策略的顯示頁麵,如下圖所示。
(2) 單擊<新建>按鈕,進入新建安全策略的配置頁麵,如下圖所示。
(4) 單擊<確定>按鈕完成操作。
IKE對等體 |
設置安全策略所引用的IKE對等體名稱 可選的IKE對等體需先在“VPN > IKE > 對等體”中創建 |
||
IPSec安全提議 |
設置安全策略所引用的IPSec安全提議名稱,最多可以引用6個 IKE協商將在安全隧道的兩端搜索能夠完全匹配的IPSec安全提議,如果找不到,則SA不能建立,需要被保護的報文將被丟棄 |
||
設置使用此安全策略發起協商時是否使用PFS(Perfect Forward Secrecy,完善的前向安全性)特性,並指定采用的Diffie-Hellman組: · DH Group1:表示采用768-bit Diffie-Hellman組 · DH Group2:表示采用1024-bit Diffie-Hellman組 · DH Group5:表示采用1536-bit Diffie-Hellman組 · DH Group14:表示采用2048-bit Diffie-Hellman組 · DH Group14、DH Group5、DH Group2、DH Group1的安全性和需要的計算時間依次遞減 · IPSec在使用配置了PFS的安全策略發起一個協商時,在階段2的協商中進行一次附加的密鑰交換以提高通訊的安全性 · 本端和對端指定的Diffie-Hellman組必須一致,否則協商會失敗 |
|||
指定的ACL必須已經存在,且至少要包含一條規則 可支持保護VPN實例間的數據流 |
|||
SA生存周期 |
設置安全策略的SA生存周期,可以選擇基於時間和基於流量 IKE為IPSec協商建立安全聯盟時,采用本地配置的生存周期和對端提議的生存周期中較小的一個 |
||
設置開啟或關閉反向路由注入功能,啟用反向路由注入時可以配置下一跳和優先級 啟用反向路由注入功能後,可以隨IPSec SA的建立自動生成到達IPSec VPN私網或隧道網關的靜態路由,減少手工靜態路由的配置 · 本端設備啟用反向路由注入後,可以不配置到對端的路由。此時,隻能由對端發起SA協商。協商成功後,本端會生成到達對端私網的靜態路由 · 反向路由注入功能動態生成的靜態路由隨IPSec SA的創建而創建,隨IPSec SA的刪除而刪除 · 反向路由注入生成的靜態路由可以在“網絡管理 > 路由管理 > 路由信息”中查看 |
|||
不指定此項時,使用本端在IPSec SA協商過程中學習到的隧道的對端地址作為下一跳 |
|||
(1) 在導航欄中選擇“VPN > IPSec”,默認進入“應用”頁簽的顯示頁麵,如下圖所示。
(2) 單擊要應用安全策略組的接口對應的操作列中的圖標,進入如下圖所示的頁麵。
圖2-21 IPSec應用設置
(4) 單擊<確定>按鈕完成操作。
在導航欄中選擇“VPN > IPSec”,單擊“ 安全聯盟”頁簽,進入IPSec安全聯盟概要信息的顯示頁麵,如下圖所示。
IPSec安全聯盟列表的詳細說明如下表所示。
表2-5 IPSec安全聯盟列表的詳細說明
源IP地址 |
顯示IPSec安全聯盟本端的IP地址 |
目的IP地址 |
顯示IPSec安全聯盟對端的IP地址 |
顯示IPSec安全聯盟的安全參數索引 |
|
顯示IPSec采用的安全協議 |
|
在導航欄中選擇“VPN > IPSec”,單擊“報文統計”頁簽,進入報文統計信息的顯示頁麵,如下圖所示。
企業分支通過IPsec VPN接入企業總部,有如下具體需求:
· 在總部網關AC 1和分支網關AC 2之間建立一個安全隧道,對總部網絡10.1.1.0/24與分支網絡10.1.2.0/24之間的數據流進行安全保護。
· 安全協議采用ESP協議,認證算法采用SHA-1,加密算法采用DES。
· 在AC 1上開啟反向路由注入功能,實現總部到分支的靜態路由隨IPSec SA的建立而動態生成,並指定下一跳地址為2.2.2.2。
圖2-24 IPSec配置組網圖
(1) 配置各接口的IP地址和所屬安全域。(略)
(2) 配置ACL 3101,定義由子網10.1.1.0/24去子網10.1.2.0/24的數據流。
步驟1:在導航欄中選擇“QoS > ACL IPv4”。
步驟2:單擊“新建”頁簽。
步驟3:如下圖所示,輸入訪問控製列表ID為“3101”,選擇匹配規則為“用戶配置”。
步驟4:單擊<應用>按鈕完成操作。
步驟5:單擊“高級配置”頁簽。
步驟6:進行如下配置,如下圖所示。
· 訪問控製列表選擇“3101”。
· 選中“源IP地址”前的複選框,輸入源IP地址為“10.1.1.0”,輸入源地址通配符為“0.0.0.255”。
· 選中“目的IP地址”前的複選框,輸入目的IP地址為“10.1.2.0”,輸入目的地址通配符為“0.0.0.255”。
步驟7:單擊<新建>按鈕完成操作。
圖2-26 配置允許由子網10.1.1.0/24去子網10.1.2.0/24數據流的規則
(3) 配置名為tran1的IPSec安全提議,報文封裝形式采用Tunnel模式,安全協議采用ESP協議,認證算法采用SHA-1,加密算法采用DES。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽。
步驟2:單擊<新建>按鈕,進入安全提議配置向導頁麵。
步驟3:單擊“定製方式”。
步驟4:進行如下配置,如下圖所示。
· 輸入安全提議名稱為“tran1”。
· 選擇報文封裝模式為“Tunnel”。
· 選擇安全協議為“ESP”。
· 選擇ESP認證算法為“SHA1”。
· 選擇ESP加密算法為“DES”。
步驟5:單擊<確定>按鈕完成操作。
圖2-27 配置名為tran1的IPSec安全提議
(4) 配置名為peer的IKE對等體。
步驟1:在導航欄中選擇“VPN > IKE”,單擊“對等體”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置,如下圖所示。
· 輸入對等體名稱為“peer”。
· 選擇協商模式為“Main”。
· 輸入對端網關IP地址為“2.2.3.1”。
· 選中“預共享密鑰”前的單選按鈕,輸入密鑰為“abcde”,並在確認密鑰中再次輸入該密鑰。
步驟4:單擊<確定>按鈕完成操作。
圖2-28 配置IKE對等體
(5) 配置名為map1的IPSec安全策略。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“策略”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置,如下圖所示。
· 輸入策略名稱為“map1”。
· 選擇IKE對等體為“peer”。
· 選中名為“tran1”的IPSec安全提議,單擊“<<”按鈕。
· 輸入ACL為“3101”。
步驟4:單擊<確定>按鈕完成操作。
圖2-29 配置IPSec安全策略
(6) 在接口Vlan-interface1上應用IPSec安全策略map1。
步驟1:在導航欄中選擇“VPN > IPSec”,默認進入“應用”頁簽的頁麵。
步驟2:單擊接口“Vlan-interface1”對應的圖標。
步驟3:如下圖所示,選擇策略名稱為“map1”。
步驟4:單擊<確定>按鈕完成操作。
圖2-30 在接口Vlan-interface1上應用IPSec安全策略
(1) 配置各接口的IP地址和所屬安全域。(略)
(2) 配置ACL 3101,定義由子網10.1.2.0/24去子網10.1.1.0/24的數據流。
步驟1:在導航欄中選擇“QoS > ACL IPv4”。
步驟2:單擊“新建”頁簽。
步驟3:輸入訪問控製列表ID為“3101”,選擇匹配規則為“用戶配置”。
步驟4:單擊<應用>按鈕完成操作。
步驟6:單擊“高級配置”頁簽。
步驟7:進行如下配置。
· 訪問控製列表選擇“3101”。
· 選中“源IP地址”前的複選框,輸入源IP地址為“10.1.2.0”,輸入源地址通配符為“0.0.0.255”。
· 選中“目的IP地址”前的複選框,輸入目的IP地址為“10.1.1.0”,輸入目的地址通配符為“0.0.0.255”。
步驟8:單擊<新建>按鈕完成操作。
(3) 配置到Host 1的靜態路由。
步驟1:在導航欄中選擇“網絡 > IPv4路由”。
步驟2:單擊“創建”頁簽。
步驟3:進行如下配置。
· 輸入目的IP地址為“10.1.1.0”。
· 選擇出接口為“Vlan-interface1”。
步驟4:單擊<確定>按鈕完成操作。
(4) 配置名為tran1的IPSec安全提議,報文封裝形式采用Tunnel模式,安全協議采用ESP協議,認證算法采用SHA-1,加密算法采用DES。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“安全提議”頁簽。
步驟2:單擊<新建>按鈕,進入安全提議配置向導頁麵。
步驟3:單擊“定製方式”。
步驟4:進行如下配置。
· 輸入安全提議名稱為“tran1”。
· 選擇報文封裝模式為“Tunnel”。
· 選擇安全協議為“ESP”。
· 選擇ESP認證算法為“SHA1”。
· 選擇ESP加密算法為“DES”。
步驟5:單擊<確定>按鈕完成操作。
(5) 配置名為peer的IKE對等體。
步驟1:在導航欄中選擇“VPN > IKE”,單擊“對等體”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置。
· 輸入對等體名稱為“peer”。
· 選擇協商模式為“Main”。
· 輸入對端網關IP地址為“2.2.2.1”。
· 選中“預共享密鑰”前的單選按鈕,輸入密鑰為“abcde”,並在確認密鑰中再次輸入該密鑰。
步驟4:單擊<確定>按鈕完成操作。
(6) 配置名為map1的IPSec安全策略。
步驟1:在導航欄中選擇“VPN > IPSec”,單擊“策略”頁簽。
步驟2:單擊<新建>按鈕。
步驟3:進行如下配置。
· 輸入策略名稱為“map1”。
· 選擇IKE對等體為“peer”。
· 選中名為“tran1”的IPSec安全提議,單擊“<<”按鈕。
· 輸入ACL為“3101”。
步驟4:單擊<確定>按鈕完成操作。
(7) 在接口Vlan-interface1上應用IPSec安全策略map1。
步驟1:在導航欄中選擇“VPN > IPSec”,默認進入“應用”頁簽的頁麵。
步驟2:單擊接口“Vlan-interface1”對應的圖標。
步驟3:選擇策略名稱為“map1”。
步驟4:單擊<確定>按鈕完成操作。
完成上述配置後,AC 1和AC 2之間如果有子網10.1.1.0/24與子網10.1.2.0/24之間的報文通過,將觸發IKE進行協商建立SA。IKE協商成功並創建了SA後,子網10.1.1.0/24與子網10.1.2.0/24之間的數據流將被加密傳輸,AC 1上同時生成靜態路由表項,所有經過AC 1發送到子網10.1.2.0/24的數據流均指向下一跳2.2.2.2。
配置IPSec時需要注意如下事項:
(1) 通常情況下,由於IKE協議采用UDP的500端口進行通信,IPSec的AH和ESP協議分別使用51或50號協議來工作,因此為保障IKE和IPSec的正常運行,需要確保應用了IKE和IPSec配置的接口上沒有禁止掉屬於以上端口和協議的流量。
(2) 若在接口上同時使能IPSec和QoS,同一個IPSec安全聯盟的數據流如果被QoS分類進入不同隊列,會導致部分報文發送亂序。由於IPSec具有防重放功能,IPSec入方向上對於防重放窗口之外的報文會進行丟棄,從而導致丟包現象。因此當IPSec與QoS結合使用時,必須保證IPSec分類與QoS分類規則配置保持一致。IPSec的分類規則完全由引用的ACL規則確定。
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!