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

IPLC

當GRE遇上IPSec后,安全性終于有了保障

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

[導讀]: 回顧GRE配置 BJ_FW身后有一個服務器,CS_FW與CD_R后面的client需要訪問這個服務器,希望不把服務器暴露在公網上面,能實現的那就只有GRE與IPSec了,但是GRE沒有安全性保障,IPSec有安全性,...

回顧GRE配置

當GRE遇上IPSec后,安全性終于有了保障

BJ_FW身后有一個服務器,CS_FW與CD_R后面的client需要訪問這個服務器,希望不把服務器暴露在公網上面,能實現的那就只有GRE與IPSec了,但是GRE沒有安全性保障,IPSec有安全性,那能不能把GRE與IPSec結合起來一起使用呢?下面先回顧下GRE的配置,把各個點之前打通,然后在這個基礎上面嘗試下用IPSec部署,看看有什么樣的效果。

配置要點

  • 圖里面BJ與CS是防火墻,而CD是一臺路由器,配置方面沒什么區別

  • BJ與CS需要考慮安全策略的放行,這個可以參考下29篇(這里為了簡化策略全放)

  • 各自可以通過靜態或者動態路由來完成內網之間的互通。

  • 基礎接口對接配置這里就不在詳細講解了。

1、internet基礎配置

#

interfaceGigabitEthernet0/0/0

 ip address 202.100.1.254 255.255.255.0

#

interfaceGigabitEthernet0/0/1

 ip address 61.128.1.254 255.255.255.0

#

interfaceGigabitEthernet0/0/2

 ip address 103.15.1.254 255.255.255.0

#

2、BJ_FW的基礎配置

#

interfaceGigabitEthernet1/0/0

 undo shutdown

 ip address 202.100.1.1 255.255.255.0

#

interfaceGigabitEthernet1/0/1

 undo shutdown

 ip address 192.168.10.254 255.255.255.0

#

firewall zone trust

 add interface GigabitEthernet1/0/1

#

firewall zone untrust

 add interface GigabitEthernet1/0/0

#

ip route-static 0.0.0.00.0.0.0 202.100.1.254

#

nat-policy

 rule name internet

  source-zone trust

  destination-zone untrust

  source-address 192.168.10.0 0.0.0.255

  action source-nat easy-ip

 

3、CS_FW的基礎配置

#

interfaceGigabitEthernet1/0/0

 undo shutdown

 ip address 61.128.1.1 255.255.255.0

#

interfaceGigabitEthernet1/0/1

 undo shutdown

 ip address 192.168.20.254 255.255.255.0

#

firewall zone trust

 add interface GigabitEthernet1/0/1

#

firewall zone untrust

 add interface GigabitEthernet1/0/0

#

ip route-static 0.0.0.00.0.0.0 61.128.1.254

#

nat-policy

 rule name internet

  source-zone trust

  destination-zone untrust

  source-address 192.168.20.0 0.0.0.255

  action source-nat easy-ip

 

4、CD_R的基礎配置

#

interfaceGigabitEthernet0/0/0

 ip address 103.15.1.1 255.255.255.0

#

interfaceGigabitEthernet0/0/1

 ip address 192.168.30.254 255.255.255.0

#

ip route-static 0.0.0.00.0.0.0 103.15.1.254

#

acl number 3000 

 rule 5 permit ip source 192.168.30.0 0.0.0.255

#

interfaceGigabitEthernet0/0/0

 ip address 103.15.1.1 255.255.255.0

 nat outbound 3000

 

(至此除了安全策略沒展示,其余基礎配置都完成了,安全策略參考下29篇,這里暫時全放)

 

5、GRE相關配置

當GRE遇上IPSec后,安全性終于有了保障

總體下來BJ_FW創建了2個tunnel隧道,一個對接CS防火墻,一個對接CD路由器,然后加入了安全區域,CS防火墻這邊也創建了一個對接BJ防火墻,注意的是路由器這邊,路由器的tunnel接口是tunnel0/0/0,跟防火墻有點區別,其余的配置是一樣的,然后不需要加入安全區域。

當GRE遇上IPSec后,安全性終于有了保障

防火墻測試接口的連通性是沒任何問題了(這里為了簡化策略全放)

 

6、局域網之間互通

隧道已經通了 ,互通的話很簡單,可以通過靜態路由,或者是跑動態路由,這里簡單點來跑個靜態路由。

[BJ_FW]ip route-static 192.168.20.0 24 Tunnel 0

[BJ_FW]ip route-static 192.168.30.0 24 Tunnel 1

[CS_FW]ip route-static 192.168.10.0 24 Tunnel 0

[CD_R]ip route-static 192.168.10.0 24 Tunnel 0/0/0

7、實際測試

在測試之前記得檢測客戶端的地址是否都設置了,并且服務器開啟了80服務

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

訪問沒問題,GRE打通是沒任何問題了,現在主要的是如何把IPSec融入進來。

GRE Over IPSec

當GRE遇上IPSec后,安全性終于有了保障

上面GRE已經連通了,但是缺乏安全性,這個時候IPSec出現了,IPSec不單單可以自己建立隧道,還可以兼容GRE等協議,為他們提供保護,這種方式稱為 GRE over IPSec,就是數據報文先通過GRE封裝,然后在進行IPSec封裝。為什么有這樣的技術出現呢?第一個是可以兼容更多的協議來保護這些不支持安全加密的(比如GRE、L2TP等),第二個是IPSec本身它是不支持組播的,假設我們的站點之間想跑OSPF協議,如果單純的IPSec則無法實現,有了GRE的幫忙,那么組播就能夠輕松穿越了,所以GRE over IPSec會更加的靈活。

GRE與IPSec是如何封裝的?

GRE與IPSec結合,這兩種協議都是需要封裝的,那么在IPSec里面有兩種封裝方式,一個是隧道、一個是傳輸模式,那么在GRE over IPSec中應該選擇哪種呢?這就需要來了解下數據包的結構了。

當GRE遇上IPSec后,安全性終于有了保障

在GRE OVER IPSec里面,傳輸模式跟隧道模式都能來保護私網的數據安全,但是仔細看其實可以發現隧道模式比傳輸模式多了一個IPSec的頭部,這是加重了數據包的長度,會容易導致分片,所以在實際中比較推薦使用傳輸模式。(這個是GRE over IPSec,包括后面要講解的L2TP over IPSec都會采用傳輸模式),因為GRE產生新的頭部已經能夠保證數據包穿越互聯網了,而且里面的內容被ESP進行保護加密了,達到了最終的需求。

GRE over IPSec配置

GRE上面已經配置完畢了,這里來加入IPSec進來,看看IPSec這塊有什么不一樣的。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

配置里面幾個不一樣的地方,這里說明下

(1)ACL,平時的IPSec匹配的是雙方的局域網之間的流量,但是這個是GRE over IPSec,IPSec保護GRE,而GRE里面包含了實際的數據,最終可以看到ACL匹配的各自公網地址的GRE流量。

(2)IKE提議與IPSec安全提議:會發現比之前的有點不一樣,之前都是防火墻對接,所以可以用默認參數,但是有了路由器就不一樣了,因為路由器的版本不一樣,支持的算法強度不一樣,很多沒法支持最新的算法,所以要改成一致,否則會出現建立不起來的情況。

當GRE遇上IPSec后,安全性終于有了保障

(3)BJ_FW這邊由于是同時跟CS與CD建立,所以需要兩個IPSec policy策略,來各自匹配,但是也可以簡化成一個。(視頻會單獨演示下)

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

問題出現了,CS_FW的建立成功了,但是CD_R卻失敗了,這里說下,并不是配置有問題,而是模擬器路由器與防火墻對接IPSec有這個問題,博主特意用debug看了下報錯,提示是共享密鑰不一致,我反復確認過,也重新輸入過,確定是一致的。

當GRE遇上IPSec后,安全性終于有了保障

為了嚴謹性,我本想用真機AR系列路由器橋接到網絡里面跟防火墻對接,結果發現橋接不起來,只好放棄了。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

直連網關都不通,這臺不通的只能用防火墻來代替了。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

當替換這套臺路由器后,用防火墻就建立起來了。

當GRE遇上IPSec后,安全性終于有了保障

BJ_FW這邊有兩對IKE的SA,一對是來自于CS的,一對來至于CD。

當GRE遇上IPSec后,安全性終于有了保障

兩個IPSec SA里面有點特別就是在FLOW里面后面有個47,47表示協議號,就是GRE協議,說明保護的就是GRE,而且我們這里用的是隧道模式,并沒有用傳輸模式,建立是可以建立的,但是會多出來20個字節。

當GRE遇上IPSec后,安全性終于有了保障當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

抓包也可以看到,IPSec新頭部后,就是ESP,然后里面的內容都被加密了,所以看不到,那么改成傳輸模式看看。

ipsec proposal 1

 encapsulation-mode transport

(3個點都改成傳輸模式,然后要執行resetike sa    reset ipsec sa,重新建立)

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

重新建立后就變成傳輸模式了,這種會更加優化。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

抓包看,用傳輸模式效果比隧道模式少了一個新的IPSec頭部,而GRE新IP頭部跟IPSec新IP頭部生成的內容其實是一樣的,所以在GRE over IPSec下面比較推薦用傳輸模式。(注意是標準的GRE over IPSec使用傳輸模式,在后面的案例里面會講解利用GRE衍生出來的特殊方案,就不一定可以用傳輸了)

如果跑動態路由協議OSPF會發生什么事?

去掉靜態路由,清空IKE與IPSec SA信息。

BJ防火墻操作

undo ip route-static 192.168.20.0 255.255.255.0 Tunnel0

undo ip route-static 192.168.30.0 255.255.255.0 Tunnel1

#

reset ike sa

reset ipse sa

#

ospf 1 router-id10.1.1.1

 area 0.0.0.0

  network 10.1.1.1 0.0.0.0

  network 10.1.1.5 0.0.0.0

  network 192.168.10.0 0.0.0.255

CS防火墻操作

undo ip route-static 192.168.10.0 255.255.255.0 Tunnel0

#

reset ike sa

reset ipse sa

#

ospf 1 router-id10.1.1.2

 area 0.0.0.0

  network 10.1.1.2 0.0.0.0

  network 192.168.20.0 0.0.0.255

 

CD防火墻操作

undo ip route-static 192.168.10.0 255.255.255.0 Tunnel0

#

reset ike sa

reset ipse sa

#

ospf 1router-id 10.1.1.6

 area 0.0.0.0

  network 10.1.1.6 0.0.0.0

  network 192.168.30.0 0.0.0.255

當GRE遇上IPSec后,安全性終于有了保障

會發現OSPF自動就建立起來了

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

IKE與IPSec SA也都有了,并沒有實際實際業務流量去觸發IPSec建立,那它為什么能夠自動的建立起來呢?

就是OSPF的功勞,OSPF里面宣告了tunnel口以及業務口的網段,那么會定期的去發送OSPF hello包,tunnel口的流量就會被發送出去,從而觸發IPSec建立,建立成功后,那么OSPF的鄰居也能夠正常的建立起來,這個也是在項目中用的多的一種方式,希望IPSec能夠自動化的去建立,而不是斷開后需要依靠業務流量來觸發建立。(華為設備是可以自動觸發建立的,這個后面會講解,這里說的其實是一種思路,像思科、華三的設備目前還不支持自動建立。)

當GRE遇上IPSec后,安全性終于有了保障

BJ防火墻這邊能收到2個網段的路由。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

動態路由協議雖然很方便,但是帶來了一個問題,它把各自分支的路由也學到了,相當于CS與CD之間也可以互通了。

當GRE遇上IPSec后,安全性終于有了保障

當GRE遇上IPSec后,安全性終于有了保障

兩邊互訪沒任何問題。

這就分情況來決定了

  • 如果分支之間不需要互訪,建議用靜態路由,如果要運行動態路由協議,建議多進程,這樣可以區分開。

  • 如果分支之間需要互訪,用動態路由協議是最方便的,簡化配置量。

分支之間是如何通信的?

分支之間通信測試過了,但是它們之間通信是如何通的呢?分支之間并沒有建立IPSec鏈接,其實從路由就可以看出來了,CS去往10.0跟30.0網段都是走的tunnel 10.1.1.1 BJ這邊,CD去往10.0跟20.0也是走的tunnel 10.1.1.5 BJ這邊,所以分支之間通信是通過BJ這邊中轉的,而并不是說CS與CD直接就互通了。

當GRE遇上IPSec后,安全性終于有了保障

這就帶來了一個問題了,在實際項目中,確實有分支之間需要互通的場景,但是如果分支比較多,業務流量都需要經過總部中轉,對總部的設備壓力會相對較大,而且也吃總部的寬帶資源,所以實際中要考慮的方面會多些,如果真的有很多分支需要互訪,就要從總部的設備性能、帶寬等方面權衡是否能夠支撐起來。)

GRE over IPSec總結

  • 實際配置就是GRE+IPSec的配置,ACL與封裝模式這里有點區別注意下

  • GRE over IPSec標準情況下,雙方之間都是需要公網地址建立的,而且建議使用傳輸模式

  • 注意分片問題,建議把GRE的tunnel隧道MTU減少在1380~1400之間,盡量減少分片

  • 如果分支之間不需要互訪,又跑動態路由協議,建議使用多個進程進行區分

  • 分支少的場景可以直接使用靜態路由協議

  • GRE over IPSec 只要tunnel隧道不在NAT范圍內,比如案例里面在GRE區域,則不需要做NONAT策略。

  • 以上就是當GRE遇上IPSec后,安全性終于有了保障的介紹,Vecloud為國內外用戶供給包括全球主機托管、主機租用、云專線接入等方面的專業服務,資源覆蓋全球。歡迎咨詢。

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

標題:當GRE遇上IPSec后,安全性終于有了保障

TAG標簽: IPSEC VPN

地址:http://www.indiamait.com/zhishibaike/304.html

常見問題