專業提供企業網絡專線 、MPLS VPN、SD-WAN、IPLC、IPLC、海外IDC、云專線等技術方案。
咨詢熱線:400-028-9798

IPLC

IPSec在實施中經驗分享

發布時間:2021-07-13 10:13:21來源:網絡之路博客作者:網絡之路作者一天閱讀:

[導讀]: 1、IKE安全提議策略 在實際中IKE的安全提議,雙方都要求一致的,那么在華為防火墻里面怎么部署比較好呢 IKEporposal 其實是有默認的策略的,并且可以發現比如認證算法、加密算法包含...
1、IKE安全提議策略

IPSec在實施中經驗分享

在實際中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

IPSec在實施中經驗分享

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

IPSec在實施中經驗分享

USG2000跟5000的默認安全策略

IPSec在實施中經驗分享

支持的算法也不算強

IPSec在實施中經驗分享

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

IPSec在實施中經驗分享

IPSec在實施中經驗分享

思科早期版本跟新版本也都不一樣,包括華三的,說了這么多,總結下來就是如果在華為下一代防火墻充當一個重要的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

IPSec在實施中經驗分享

會發現默認是有內置參數的,每個版本不一樣可能內置的參數是不一樣,所以跟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建立過程中,一端出現故障或者設備重啟后發現隧道建立不起來了怎么辦?      

IPSec在實施中經驗分享

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

IPSec在實施中經驗分享

IPSec在實施中經驗分享

IPSec在實施中經驗分享

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

IPSec在實施中經驗分享

因為在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信息,然后重新建立隧道,在模擬一次故障,否則會出現不生效的情況。)

IPSec在實施中經驗分享

IPSec在實施中經驗分享

IPSec在實施中經驗分享

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

IPSec在實施中經驗分享

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

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模板實際中部署(提高對接率,減少故障)

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為國內外用戶供給包括全球主機托管、主機租用、云專線接入等方面的專業服務,資源覆蓋全球。歡迎咨詢。

免責聲明:部分文章信息來源于網絡以及網友投稿,本網站只負責對文章進行整理、排版、編輯,是出于傳遞 更多信息之目的,并不意味著贊同其觀點或證實其內容的真實性,如本站文章和轉稿涉及版權等問題,請作者在及時聯系我們本站,我們會盡快處理。

標題:IPSec在實施中經驗分享

TAG標簽: IPSEC VPN

地址:http://www.indiamait.com/haiwaizhuanxian/307.html

常見問題