对于新发展的分舵，天地会使用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系列的最后一篇贴子，敬请期待。