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

回顧GRE配置

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相關配置

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

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

 

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

GRE over IPSec配置

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

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

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

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

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

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

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

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

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

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

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

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

ipsec proposal 1

 encapsulation-mode transport

（3個點都改成傳輸模式，然后要執行resetike sa    reset ipsec sa，重新建立）

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

抓包看，用傳輸模式效果比隧道模式少了一個新的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

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

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

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

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

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

兩邊互訪沒任何問題。

這就分情況來決定了

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

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

分支之間是如何通信的？

分支之間通信測試過了，但是它們之間通信是如何通的呢？分支之間并沒有建立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 over IPSec總結

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

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

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

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

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

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

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