IPSec在實施中經驗分享

1、IKE安全提議策略

在實際中IKE的安全提議，雙方都要求一致的，那么在華為防火墻里面怎么部署比較好呢

IKEporposal 其實是有默認的策略的，并且可以發現比如認證算法、加密算法包含了多個參數，這樣的好處就是

一個porposal就可以包含更多匹配的可能性，減少配置量。

ike proposal default

 encryption-algorithm aes-256 aes-192 aes-1283des des

 dh group14 group5 group2 group1 group20group18 group16 group15

 authentication-algorithm sha2-512 sha2-384sha2-256 sha1 md5

 authentication-method pre-share

這樣的一個策略就可以全部匹配了，實際中比較推薦這樣做。

USG2000跟5000的默認安全策略

支持的算法也不算強

華為AR路由器早期版本支持的

思科早期版本跟新版本也都不一樣，包括華三的，說了這么多，總結下來就是如果在華為下一代防火墻充當一個重要的HUB點（中心），那么可以把一個安全提議支持很多算法，這樣呢，在不管對端是什么設備、版本不一致的情況下，安全策略都能夠去盡可能的匹配上，減少實施時候的配置量，還一個好處就是后期維護會更加方便，否則策略一多，要去查看配置會更加費勁，當然也有那種要求嚴格的甲方需求，一個peer只用一個安全提議，那么這個時候就建議用名字命名，能夠讓自己看起來更容易區分的。

總結下來：IKE的安全提議在支持一個提議容納多種算法的則直接容納多個（目前華為下一代防火墻可以，包括思科的路由器默認內置了很多常用的，其他廠商都是多多少少都需要修改的）

2、IKE peer

在peer里面注意的地方比較多

默認情況下，華為下一代防火墻是V1V2版本都啟用的，如果現網中使用的V1，而配置里面V1、2都開的話，防火墻發起是以V2發起的，所以通常會輸入undo version 2（響應可以支持V1/2）

協商模式，下一代防火墻支持自動模式exchange-mode     auto，它主動發起的時候使用主模式，被動接受的時候則主模式跟野蠻模式都支持，比較適合于在用模板方式的時候，用auto是最好的。

SA超時時間：這個是策略里面唯一不需要匹配的，會以雙方最小的值為標準進行統一，在實際中建議一樣。

默認情況下本端的ID是以IP來進行驗證的，有時候特別在野蠻模式下，可能需要用到別名等方式，可以進行修改。local-id-type     fqdn  |      local-id     USG

NAT穿越，在下一代防火墻中NAT穿越默認是開啟的，但是在其他設備里面建議查看ike peer的屬性是否開啟，否則造成穿越NAT失敗的情況。（可以不管它開沒開啟，手動執行一次）

預共享密鑰：這個兩邊一直即可，注意輸入后會進行加密，所以最好做一份記錄，以后用的少。

3、IPSec安全提議

對于IPSec的安全提議是沒有內置的，但是呢，創建后其實是有內置的參數的。

創建一個ipsec proposal 1

會發現默認是有內置參數的，每個版本不一樣可能內置的參數是不一樣，所以跟IKE 安全提議一樣，盡可能的一個策略去迎合。

ipsec proposal 1

 esp authentication-algorithm sha2-512 sha2-384sha2-256 sha1 md5

 esp encryption-algorithm aes-256 aes-192aes-128 3des des

4、ACL（受保護流量）

ACL沒什么特別注意的，在實際中盡量使用精確、明細的匹配方式來做，這樣在后期新加跟維護的時候會更加方便，并雙方是互為鏡像的方式。如果總部與分支的網段比較多，又是基于ACL的方式匹配的話，可以配置地址組，然后在ACL里面可以直接匹配地址組來簡化ACL的條目。

5、IPSec策略（模板）

IPSec策略中之前都是按標準講解的，有些細節的地方沒有說明，這里提及下。

由于一個設備下面可以起很多IPSec策略，那么這個時候策略一多，在查看的時候就會非常不方便，推薦使用alias別名的功能，可以為這個策略起一個名字，支持中文，非常方便。

tunnel local：這個通常情況下用不到，如果說一個外網有多個IP的情況下，這個時候如果建立想單獨使用一個空閑的地址作為協商，那么就需要通過該命令指定了。

觸發方式：之前的講解中都是以流量觸發講解的，就是當實際業務流量訪問，IPSec才能夠建立，但是華為是支持自動建立方式的，不用業務觸發，也能自動建立。sa     trigger-mode  auto（默認為流量觸發）

respond-only     enable：該功能是禁止本端主動發起IPSec建立，平時用不上，在排錯的時候有一定幫助，可以定位故障。

在實際部署中一個接口只能調用一個IPSec策略，可能會存在策略方式以及模板方式共存，那么這個時候，模板方式的ID建議在最后，比如ID 1000，策略方式的ID在前面，這樣在實施的時候減少故障率。

6、接口調用

接口調用的話注意一個策略只能調用一個IPSec安全策略，并且如果要刪除某一個IPSecpolicy 的某個ID并且有對應的IKE SA與IPSEC SA信息的時候，需要先去掉接口調用才能刪除，否則會提示刪除不了。

如果IPSec建立過程中，一端出現故障或者設備重啟后發現隧道建立不起來了怎么辦？      

正常情況下192.168.10.1訪問20.2通過IPSec訪問沒任何問題，但是這個時候突然CS_FW那邊跳閘了，導致設備重啟，這個時候就會出現一個問題。

造成BJ這邊有IKE與IPSec sa信息，而CS那邊由于重啟了沒有了這些信息，那么這個時候數據訪問就會出現問題。

因為在BJ_FW這邊它是有IKE與IPSec Sa的，能夠直接用SA信息進行加密數據出去，但是到了CS那邊，由于重啟的原因，SA信息丟失，無法直接加解密，則直接丟棄了。

解決這個問題，實際有三種辦法

keepalive與heartbeat：這兩種方式用的少，原因是（1）周期性的發送會消耗CPU （2）每個廠家的標準不一樣，存在兼容性問題，無法對接，在實際中用的很少。

DPD：非常靈活，支持周期性發送與按需性發送，而且兼容性好，所以在實際中建議采用DPD的方式。

按需型：本端需要向對端發送IPSec數據業務時，如果當前距離最后一次收到對端的IPSec報文的時長已超過DPD空閑時間，則觸發DPD檢測，本端主動向對端發送DPD請求報文。

周期型：如果當前距離最后一次收到對端的IPSec報文或DPD請求報文的時長已超過DPD空閑時間，則本端主動向對端發送DPD請求報文。

主動向對端發送DPD請求報文后，若在DPD報文重傳間隔內沒有收到對端的DPD回應報文，則向對端重傳DPD請求報文，根據重傳次數進行重傳之后，若仍然沒有收到對端的DPD回應報文，則認為對端離線，刪除該IKE      SA和對應的IPSec SA。

DPD的配置

基于IKE 進程單獨配置，這樣只用于單個進程

ikepeer  cs

dpd type on-demand

全局配置，會應用于全部IKE peer

ike dpd type on-demand

（這里注意DPD配置后，建議清空SA信息，然后重新建立隧道，在模擬一次故障，否則會出現不生效的情況。）

這個時候在去訪問業務端，由于這里我們采用的是按需的方式，那么DPD會觸發檢測，會發送請求報文，請求報文會發送3次，如果對方依舊沒有相應，則會清空IKE與IPSec SA信息。

這個時候在去訪問就正常了，因為兩邊會重新開始建立。

DPD使用建議

建議基于ike peer進程來創建，因為在實際中可能每個peer之間的鏈路環境不一樣，可以根據不同環境選擇按需還是周期（如果是hub環境，hub這邊建議選擇周期。）

建議兩邊都開啟，因為在實際中任何一邊都有可能發生故障。

配合自動建立效果更佳。

如果一邊有動態公網地址，一邊沒有，能否建立IPSec呢？

如果一邊有動態公網地址，是可以建立的，需要在動態地址那邊關聯動態域名（比如3322或者花生殼等），然后做模板方式，最關鍵的就是沒有公網地址端的配置。

ike peer  1

remote-addresshost-name  ccieh3c.com  （可以直接指定實際申請的DDNS域名）

注意的是設備本身要開啟DNS解析，否則解析不到當前域名所在的IP地址導致訪問失敗。（一般DHCP或者撥號的都會自動下發DNS的，可以通過display  dns server查看，也可以手動dns server設置DNS服務器地址。）

IPSec模板實際中部署（提高對接率，減少故障）

在下一代防火墻中，有這樣的一個功能，配合模板方式特別好使，這個是35篇的內容，CD_FW與CS_FW都是動態或者是私網地址，BJ_FW是以模板的時候配置的，在實際環境中，分支這邊可能由于設備型號不一致、版本、廠商等情況導致支持的安全參數不一樣，那么這個時候統一就有點困難，BJ_FW這邊需要建立多個安全提議去匹配，有這樣一個功能“協議兼容”。

ikepeer BJ

ikenegotiate compatible

該功能啟用后，對方發送過來的IKE安全提議以及IPSec的安全提議，如果本地沒有相對于的匹配，直接以對方發送過來的參數進行響應，這種方式在實際中部署可以大大提高連接的成功率，但是有一定的風險，可能對方是低安全策略，造成風險的可能。（適合分支設備廠商比較雜的情況，建議可以做做實驗，把CS_FW與CD_FW的IKE與IPSec的加密算法與安全算法全部改掉，跟BJ_FW不匹配，然后測試下是否能夠建立起來隧道。）

實戰案例題（1）：如果防火墻上面部署了策略路由、NAT server，對IPsec有什么影響嗎？

實戰案例題（2）：如果外網有多條線路，這個時候IPSec怎么部署好？

實戰案例題（3）：如果防火墻單獨作為一個IPSec server，應該如何融入到網絡

視頻補充（4）：WEB端配置講解

IPSec實際注意的地方

IPSec在實際中除了對接上面注意的地方，除了上面說安全提議策略以外，在實際中還需要考到線路問題。

盡量雙方在部署的時候選擇同一個運營商的，比如固定專線那邊是電信、那邊其他點用電信是最好的

不同運營商之間建立IPSec隧道，延遲跟穩定性不如同一個運營商，這個在部署  的時候告知客戶

如果分支之間需要互訪，但分支又沒有動態公網地址，那只能通過總部之間中轉。

如果分支采用的貓撥號（貓是路由模式），有可能會導致IPSec隧道建立不起來的情況，建議改成橋接模式

總部與分支，以及其他分支之間的網段是不能重疊的，就是不能有相同的，否則建立不起來的情況。

以上就是IPSec在實施中經驗分享的介紹，Vecloud為國內外用戶供給包括全球主機托管、主機租用、云專線接入等方面的專業服務，資源覆蓋全球。歡迎咨詢。