對於新發展的分舵，天地會使用IPSec來保護分舵與總舵之間的通信。而對於一些很早就存在的分舵，它們已經通過GRE或L2TP方式接入總舵，如何在不改變原有接入方式的基礎上使這些分舵也可以使用IPSec與總舵安全通信呢？
好在IPSec兼容並濟胸襟寬廣，GRE和L2TP皆可納入到IPSec中。IPSec將GRE隧道和L2TP隧道視爲受保護對象，即報文先進行GRE或L2TP封裝，然後再進行IPSec封裝。這樣分舵和總舵之間的通信非但不用改動原有的接入方式，還可以受到IPSec的保護。這種方式相當於是兩種不同類型的隧道疊加，也叫做GRE over IPSec和L2TP over IPSec。
下面先來看一下在分舵通過GRE接入總舵的場景中，如何使用IPSec來保護GRE隧道。
分舵通過GRE over IPSec接入總舵
如下圖所示，總舵網關FWA和分舵網關FWB已經建立了GRE隧道，現需要在GRE隧道之外再封裝IPSec隧道，對總舵和分舵的通信進行加密保護。
前面我們介紹過，IPSec有兩種封裝模式：傳輸模式和隧道模式。IPSec對GRE隧道進行封裝時，這兩種模式的封裝效果也不盡相同。
l 傳輸模式
在傳輸模式中，AH頭或ESP頭被插入到新的IP頭與GRE頭之間：
傳輸模式不改變GRE封裝後的報文頭，IPSec隧道的源和目的地址就是GRE封裝後的源和目的地址。
l 隧道模式
在隧道模式中，AH頭或ESP頭被插到新的IP頭之前，另外再生成一個新的報文頭放到AH頭或ESP頭之前：
隧道模式使用新的IPSec報文頭來封裝經過GRE封裝後的消息，封裝後的消息共有三個報文頭：原始報文頭、GRE報文頭和IPSec報文頭，Internet上的設備根據最外層的IPSec報文頭來轉發該消息。
封裝GRE報文頭時，源和目的地址可以與IPSec報文頭中的源和目的地址相同，即使用公網地址來封裝；也可以使用私網地址封裝GRE報文頭，例如，創建Loopback接口並配置私網地址，然後在GRE中借用Loopback接口的地址來封裝。
在GRE over IPSec中，無論IPSec採用傳輸模式還是隧道模式，都可以保護兩個網絡之間通信的消息。這是因爲GRE已經進行了一次封裝，原始報文就可以是兩個網絡之間的報文。
注意：隧道模式與傳輸模式相比多增加了新的IPSec報文頭，導致報文長度更長，更容易導致分片。如果網絡環境要求報文不能分片，推薦使用傳輸模式。
下面以隧道模式下ESP封裝爲例，來對總舵和分舵之間的GRE隧道進行加密保護。首先給出總舵網關FWA和分舵網關FWB的關鍵配置。
|
關鍵配置 |
FWA |
FWB |
|
GRE配置 |
interface Tunnel1 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre source 1.1.1.1 //使用公網地址封裝 destination 3.3.3.3 //使用公網地址封裝
如果使用私網地址進行封裝，進行如下配置： interface LoopBack1 ip address 172.16.0.1 255.255.255.0 interface Tunnel1 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre source LoopBack 1 destination 172.16.0.2 //FWB的Loopback1接口地址 |
interface Tunnel1 ip address 10.1.1.2 255.255.255.0 tunnel-protocol gre source 3.3.3.3 //使用公網地址封裝 destination 1.1.1.1 //使用公網地址封裝
如果使用私網地址進行封裝，進行如下配置： interface LoopBack1 ip address 172.16.0.2 255.255.255.0 interface Tunnel1 ip address 10.1.1.2 255.255.255.0 tunnel-protocol gre source LoopBack 1 destination 172.16.0.1 //FWA的Loopback1接口地址 |
|
路由配置 |
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 //假設下一跳爲1.1.1.2 ip route-static 192.168.1.0 255.255.255.0 Tunnel1 |
ip route-static 0.0.0.0 0.0.0.0 3.3.3.1 //假設下一跳爲3.3.3.1 ip route-static 192.168.0.0 255.255.255.0 Tunnel1 |
|
ACL |
acl number 3000. rule 5 permit ip source 1.1.1.1 0 destination 3.3.3.3 0 //定義GRE封裝後的源地址和目的地址
如果使用私網地址進行封裝，此處的源地址應爲172.16.0.1，目的地址應爲172.16.0.2 |
acl number 3000 rule 5 permit ip source 3.3.3.3 0 destination 1.1.1.1 0 //定義GRE封裝後的源地址和目的地址
如果使用私網地址進行封裝，此處的源地址應爲172.16.0.2，目的地址應爲172.16.0.1 |
|
IKE安全提議 |
ike proposal 1 //使用默認參數 |
ike proposal 1 //使用默認參數 |
|
IKE對等體 |
ike peer fwb pre-shared-key tiandihui ike-proposal 1 remote-address 3.3.3.3 |
ike peer fwa pre-shared-key tiandihui ike-proposal 1 remote-address 1.1.1.1 |
|
IPSec安全提議 |
ipsec proposal 1 transform esp encapsulation-mode tunnel esp authentication-algorithm sha1 esp encryption-algorithm aes |
ipsec proposal 1 transform esp encapsulation-mode tunnel esp authentication-algorithm sha1 esp encryption-algorithm aes |
|
IPSec安全策略 |
ipsec policy policy1 1 isakmp security acl 3000 ike-peer fwb proposal 1 |
ipsec policy policy1 1 isakmp security acl 3000 ike-peer fwa proposal 1 |
|
應用IPSec安全策略 |
interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ipsec policy policy1 |
interface GigabitEthernet0/0/1 ip address 3.3.3.3 255.255.255.0 ipsec policy policy1 |
從上面的表格可以看出，配置GRE over IPSec時，與單獨配置GRE和IPSec沒有太大的區別。唯一需要注意的地方是，通過ACL定義需要保護的數據流時，不能再以總舵和分舵內部私網地址爲匹配條件，而是必須匹配經過GRE封裝後的報文，即定義報文的源地址爲GRE隧道的源地址，目的地址爲GRE隧道的目的地址。
配置完成後，在分舵中的PC可以ping通總舵的PC，在Internet上抓包只能看到加密後的信息，無法獲取到真實的ping消息：
在總舵的網關FWA上可以查看到如下會話信息，會話信息中包括了原始的ICMP報文、第一層封裝即GRE封裝、第二層封裝即IPSec封裝，其中GRE封裝和IPSec封裝使用了相同的源和目的地址。
[FWA] display firewall session table
Current Total Sessions : 4
udp VPN:public --> public 3.3.3.3:500-->1.1.1.1:500
esp VPN:public --> public 3.3.3.3:0-->1.1.1.1:0
gre VPN:public --> public 3.3.3.3:0-->1.1.1.1:0
icmp VPN:public --> public 192.168.1.2:2862-->192.168.0.2:2048
介紹完GRE over IPSec後，下面來看一下使用IPSec來保護L2TP隧道的情況。
分舵通過L2TP over IPSec接入總舵
在之前的L2TP系列貼子中我們介紹了L2TP有三種類型，分別是Client-Initiated VPN、NAS-Initiated VPN和LAC-Auto-Initiated VPN。其中Client-Initiated VPN屬於單獨的移動用戶遠程接入，我們將在下文中的遠程接入部分介紹。NAS-Initiated VPN和LAC-Auto-Initiated VPN都可以實現兩個網絡之間的通信，在這裏我們重點以NAS-Initiated VPN爲例來介紹。
如下圖所示，總舵網關FWA和分舵網關FWB已經建立了NAS-Initiated方式的L2TP隧道，現需要在L2TP隧道之外再封裝IPSec隧道，對總舵和分舵的通信進行加密保護。
IPSec對L2TP隧道進行封裝時，傳輸模式和隧道模式的封裝效果如下：
l 傳輸模式
在傳輸模式中，AH頭或ESP頭被插入到新的IP頭與UDP頭之間：
傳輸模式不改變L2TP封裝後的報文頭，IPSec隧道的源和目的地址就是L2TP封裝後的源和目的地址。
l 隧道模式
在隧道模式中，AH頭或ESP頭被插到新的IP頭之前，另外再生成一個新的報文頭放到AH頭或ESP頭之前：
隧道模式使用新的IPSec報文頭來封裝經過L2TP封裝後的消息，封裝後的消息共有三個報文頭：原始報文頭、L2TP報文頭和IPSec報文頭，Internet上的設備根據最外層的IPSec報文頭來轉發該消息。
在L2TP over IPSec中，由於L2TP已經進行了一次封裝，原始報文就是兩個網絡之間的報文，所以無論IPSec採用傳輸模式還是隧道模式，都可以保護兩個網絡之間通信的消息。
注意：隧道模式與傳輸模式相比多增加了新的IPSec報文頭，導致報文長度更長，更容易導致分片。如果網絡環境要求報文不能分片，推薦使用傳輸模式。
下面以隧道模式下ESP封裝爲例，來對總舵和分舵之間的L2TP隧道進行加密保護。首先給出總舵網關FWA和分舵網關FWB的關鍵配置。
|
關鍵配置 |
FWA（LNS） |
FWB（LAC） |
|
L2TP配置 |
l2tp enable interface Virtual-Template1 ppp authentication-mode chap ip address 10.1.1.1 255.255.255.0 remote address pool 0 l2tp-group 1 tunnel authentication tunnel password cipher Tiandihui123 allow l2tp virtual-template 1 remote lac tunnel name lns aaa local-user l2tpuser password cipher Password1 local-user l2tpuser service-type ppp ip pool 0 192.168.1.2 192.168.1.10 |
l2tp enable l2tp-group 1 tunnel authentication tunnel password cipher Tiandihui123 start l2tp ip 1.1.1.1 fullusername l2tpuser tunnel name lac |
|
路由配置 |
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 //假設下一跳爲1.1.1.2 |
ip route-static 0.0.0.0 0.0.0.0 3.3.3.1 //假設下一跳爲3.3.3.1 |
|
ACL |
acl number 3000 rule 5 permit ip source 1.1.1.1 0 destination 3.3.3.3 0 //定義L2TP封裝後的源地址和目的地址 |
acl number 3000 rule 5 permit ip source 3.3.3.3 0 destination 1.1.1.1 0 //定義L2TP封裝後的源地址和目的地址 |
|
IKE安全提議 |
ike proposal 1 //使用默認參數 |
ike proposal 1 //使用默認參數 |
|
IKE對等體 |
ike peer fwb pre-shared-key tiandihui ike-proposal 1 remote-address 3.3.3.3 |
ike peer fwa pre-shared-key tiandihui ike-proposal 1 remote-address 1.1.1.1 |
|
IPSec安全提議 |
ipsec proposal 1 transform esp encapsulation-mode tunnel esp authentication-algorithm sha1 esp encryption-algorithm aes |
ipsec proposal 1 transform esp encapsulation-mode tunnel esp authentication-algorithm sha1 esp encryption-algorithm aes |
|
IPSec安全策略 |
ipsec policy policy1 1 isakmp security acl 3000 ike-peer fwb proposal 1 |
ipsec policy policy1 1 isakmp security acl 3000 ike-peer fwa proposal 1 |
|
應用IPSec安全策略 |
interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ipsec policy policy1 |
interface GigabitEthernet0/0/1 ip address 3.3.3.3 255.255.255.0 ipsec policy policy1 |
同GRE over IPSec類似，在L2TP over IPSec中定義ACL時，不能再以總舵和分舵內部私網地址爲匹配條件，而是必須匹配經過L2TP封裝後的報文，即定義報文的源地址爲L2TP隧道的源地址，目的地址爲L2TP隧道的目的地址。
配置完成後，分舵中的PPPoE Client發起撥號訪問，分舵網關FWB和總舵網關FWA先進行IPSec協商，建立IPSec隧道，然後在IPSec隧道的保護下進行L2TP協商，建立L2TP隧道。同樣，在Internet上抓包也只能看到加密後的信息，無法獲取到L2TP隧道中傳輸的消息。
通過部署IPSec對GRE和L2TP隧道進行加密保護，天地會這些老舊的分舵又煥發了青春。接下來天地會又面臨新的問題：總舵的堂主經常會出差到各個分舵指導工作，而總舵中有一些緊急幫務需要他們及時處理。如果堂主恰巧在分舵中，就可以通過分舵接入總舵；但是如果堂主正在路途中，就只能通過Client-Initiated VPN方式的L2TP接入總舵，但是此時通信的安全性無法保證。而藉助於IPSec，就可以保證移動用戶遠程接入場景中的通信安全。
移動用戶使用L2TP over IPSec遠程接入總舵
在L2TP中，Client-Initiated VPN方式專門適用於移動用戶遠程接入的場景。在此基礎上，使用IPSec來對L2TP隧道進行加密保護，這也是一種L2TP over IPSec的應用。
如下圖所示，總舵網關FWA和分舵網關FWB已經建立了Client-Initiated VPN方式的L2TP隧道，現需要在L2TP隧道之外再封裝IPSec隧道，對總舵和分舵的通信進行加密保護。
堂主可以使用Windows系統自帶的客戶端來撥號，也可以使用第三方的撥號軟件（如華爲VPN Client軟件）來撥號。如果使用Windows系統自帶的客戶端來撥號，因爲其只支持傳輸模式，所以在總舵網關FWA上也只能配置傳輸模式的IPSec。IPSec對Client-Initiated VPN方式的L2TP隧道的封裝效果與上文介紹過的NAS-Initiated VPN方式相同，此處不再贅述。
下面以堂主使用Windows 7系統自帶的客戶端撥號接入總舵爲例，給出總舵網關FWA和L2TP Client的關鍵配置。
|
FWA（LNS） |
L2TP |
l2tp enable interface Virtual-Template1 ppp authentication-mode chap ip address 10.1.1.1 255.255.255.0 remote address pool 0 l2tp-group 1 //使用L2TP組1 undo tunnel authentication //關閉隧道驗證 allow l2tp virtual-template 1 //在L2TP組1中無需設置隧道對端名稱 aaa local-user l2tpuser password cipher Password1 local-user l2tpuser service-type ppp ip pool 0 192.168.1.2 192.168.1.10 |
|
ACL |
acl number 3000 rule 5 permit udp source-port eq 1701 //定義L2TP封裝後的源端口 |
|
|
IKE安全提議 |
ike proposal 1 encryption-algorithm 3des-cbc dh group2 |
|
|
IKE對等體 |
ike peer client pre-shared-key tiandihui ike-proposal 1 |
|
|
IPSec安全提議 |
ipsec proposal 1 transform esp encapsulation-mode transport //使用傳輸模式 esp authentication-algorithm sha1 esp encryption-algorithm 3des |
|
|
IPSec安全策略 |
ipsec policy-template tem1 1 security acl 3000 ike-peer client proposal 1 ipsec policy policy1 1 isakmp template tem1 |
|
|
應用IPSec安全策略 |
interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ipsec policy policy1 |
|
|
L2TP Client |
IPsec Policy Agent狀態：已啓動 用戶名：l2tpuser 密碼：Password1 ----------------------------------------- 目的地的主機名或IP地址：1.1.1.1 VPN類型：使用IPsec的第2層隧道協議(L2TP/IPSec) 身份驗證：CHAP ----------------------------------------- IKE加密算法：3DES IKE完整性算法：SHA1 DH組：中(2) ESP加密算法：3DES ESP完整性算法：SHA1 預共享密鑰：tiandihui 注意：此處只給出了Windows 7系統自帶的客戶端上默認的IPSec配置，如需調整這些IPSec參數，請在Windows 7系統的“控制面板—>系統和安全—>管理工具—>本地安全策略”中設置IP安全策略。 |
|
因爲堂主都是在Internet上動態接入，公網IP地址不確定，所以在總舵網關FWA上定義ACL時，以源端口1701來匹配經過L2TP封裝後的報文。此外，由於Windows系統自帶的客戶端不支持隧道驗證，所以還需要在總舵網關FWA上關閉L2TP的隧道驗證功能。
配置完成後，堂主就可以使用Windows 7系統自帶的客戶端隨時隨地接入總舵，在IPSec隧道的保護下處理緊急事務。而在Internet上抓包也只能看到加密後的信息，無法獲取到L2TP隧道中傳輸的消息。
雖然IPSec可以對Client-Initiated VPN方式的L2TP隧道加密，但是L2TP和IPSec一塊使用，配置起來較爲繁瑣。其實對於遠程接入的場景，還可以使用一種輕量級的VPN即SSL VPN來實現。部署SSL VPN後，堂主直接使用瀏覽器就可以接入到總舵，操作簡單效果直觀。關於SSL VPN的內容，我們將在IPSec系列技術貼完成後推出。
至此，IPSec的主要應用場景都介紹完畢。藉助IPSec，天地會解決了一個又一個的問題，終於搭建起來了涵蓋分舵接入、移動用戶遠程接入的加密通信網絡。網絡雖然搭建起來，但是還面臨穩定運行的問題，下一篇我們就來介紹IKE對等體檢測、主備鏈路、隧道化鏈路等提高可靠性的內容，這也將是IPSec系列的最後一篇貼子，敬請期待。