【防火墙技术连载30】强叔侃墙 VPN篇 IPSec兼容并济吸纳百家,GRE和L2TP改头换面深藏不漏

digest [复制链接]
发表于 : 2014-8-20 11:39:17 最新回复:2019-06-03 22:28:20
14040 13
强叔侃墙
强叔侃墙 官方号

对于新发展的分舵,天地会使用IPSec来保护分舵与总舵之间的通信。而对于一些很早就存在的分舵,它们已经通过GREL2TP方式接入总舵,如何在不改变原有接入方式的基础上使这些分舵也可以使用IPSec与总舵安全通信呢?

好在IPSec兼容并济胸襟宽广,GREL2TP皆可纳入到IPSec中。IPSecGRE隧道和L2TP隧道视为受保护对象,即报文先进行GREL2TP封装,然后再进行IPSec封装。这样分舵和总舵之间的通信非但不用改动原有的接入方式,还可以受到IPSec的保护。这种方式相当于是两种不同类型的隧道叠加,也叫做GRE over IPSecL2TP over IPSec

下面先来看一下在分舵通过GRE接入总舵的场景中,如何使用IPSec来保护GRE隧道。

分舵通过GRE over IPSec接入总舵

如下图所示,总舵网关FWA和分舵网关FWB已经建立了GRE隧道,现需要在GRE隧道之外再封装IPSec隧道,对总舵和分舵的通信进行加密保护。


 

 

前面我们介绍过,IPSec有两种封装模式:传输模式和隧道模式。IPSecGRE隧道进行封装时,这两种模式的封装效果也不尽相同。

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  //FWBLoopback1接口地址

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  //FWALoopback1接口地址

路由配置

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时,与单独配置GREIPSec没有太大的区别。唯一需要注意的地方是,通过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 VPNNAS-Initiated VPNLAC-Auto-Initiated VPN。其中Client-Initiated VPN属于单独的移动用户远程接入,我们将在下文中的远程接入部分介绍。NAS-Initiated VPNLAC-Auto-Initiated VPN都可以实现两个网络之间的通信,在这里我们重点以NAS-Initiated VPN为例来介绍。

如下图所示,总舵网关FWA和分舵网关FWB已经建立了NAS-Initiated方式的L2TP隧道,现需要在L2TP隧道之外再封装IPSec隧道,对总舵和分舵的通信进行加密保护。


 

 

IPSecL2TP隧道进行封装时,传输模式和隧道模式的封装效果如下:

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的关键配置。

关键配置

FWALNS

FWBLAC

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隧道中传输的消息。

通过部署IPSecGREL2TP隧道进行加密保护,天地会这些老旧的分舵又焕发了青春。接下来天地会又面临新的问题:总舵的堂主经常会出差到各个分舵指导工作,而总舵中有一些紧急帮务需要他们及时处理。如果堂主恰巧在分舵中,就可以通过分舵接入总舵;但是如果堂主正在路途中,就只能通过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上也只能配置传输模式的IPSecIPSecClient-Initiated VPN方式的L2TP隧道的封装效果与上文介绍过的NAS-Initiated VPN方式相同,此处不再赘述。

下面以堂主使用Windows 7系统自带的客户端拨号接入总舵为例,给出总舵网关FWAL2TP Client的关键配置。

FWALNS

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  //使用L2TP1

 undo tunnel authentication  //关闭隧道验证

 allow l2tp virtual-template 1  //L2TP1中无需设置隧道对端名称

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隧道加密,但是L2TPIPSec一块使用,配置起来较为繁琐。其实对于远程接入的场景,还可以使用一种轻量级的VPNSSL VPN来实现。部署SSL VPN后,堂主直接使用浏览器就可以接入到总舵,操作简单效果直观。关于SSL VPN的内容,我们将在IPSec系列技术贴完成后推出。

至此,IPSec的主要应用场景都介绍完毕。借助IPSec,天地会解决了一个又一个的问题,终于搭建起来了涵盖分舵接入、移动用户远程接入的加密通信网络。网络虽然搭建起来,但是还面临稳定运行的问题,下一篇我们就来介绍IKE对等体检测、主备链路、隧道化链路等提高可靠性的内容,这也将是IPSec系列的最后一篇贴子,敬请期待。

 

 

上一篇 VPN篇 IPSec引入数字证书,身份认证简单便捷

下一篇 VPN篇 对等体检测洞察先机,双链路备份有备无患

汇总贴

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
DoubleDong
DoubleDong   发表于 2014-9-13 23:21:43 已赞(0) 赞(0)

这个必须要顶一下!
  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-8-20 12:04:34 已赞(0) 赞(0)

顶强叔。。。。。
  • x
  • 常规:

点评 回复

xiaoshuaijiayou
xiaoshuaijiayou   发表于 2014-8-20 16:34:47 已赞(0) 赞(0)

谢谢强叔分享的资料
  • x
  • 常规:

点评 回复

kmyd
kmyd  大师 发表于 2014-8-20 16:48:42 已赞(0) 赞(0)

谢谢强叔!
  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-8-21 21:21:34 已赞(0) 赞(0)

感谢分享!
  • x
  • 常规:

点评 回复

周中斌
周中斌   发表于 2014-9-28 16:22:06 已赞(0) 赞(0)

上次在在线学习视频中,好像还看到有ipsec over gre这样的技术,这与gre over ipsec的原理有多少差异?期待出一个专题学习一下。

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-10-16 16:00:51 已赞(0) 赞(0)

Quote 7 #

上次在在线学习视频中,好像还看到有ipsec over gre这样的技术,这与gre over ipsec的原理有多少差异?期待出一个专题学习一下。

zhouzhongbin_2014 Post On 2014-09-28 16:22

IPSec over GRE是先进行IPSec封装再进行GRE封装;而GRE over IPSec是先进行GRE封装再进行IPSec封装。目前防火墙不支持IPSec over GRE。

  • x
  • 常规:

点评 回复

saiyaren
saiyaren   发表于 2015-1-11 18:31:35 已赞(0) 赞(0)

强叔,GRE OVER IPSEC,tunnel口运行OSPF协议,发现OSPF邻居full了,但是两端PC互ping不通,这是不是模拟器的问题,模拟器能做通GRE OVER IPSEC吗?

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2015-1-12 21:01:33 已赞(0) 赞(0)

回复 11 楼

我这边用eNSP模拟器验证是可以的,Tunnel接口和外网接口上跑的ospf属于两个不同的进程。你再检查一下配置,或者贴出配置来看一下。
  • x
  • 常规:

点评 回复

12
返回列表
发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录