【防火墙技术连载27】强叔侃墙 VPN篇 IPSec模板海纳百川,不定对端有容乃大

digest [复制链接]
发表于 : 2014-7-22 15:33:05 最新回复:2018-06-13 16:05:30
20763 21
强叔侃墙
强叔侃墙 官方号

IPSec模板海纳百川

自从天地会采用了IKE方式协商IPSec安全策略,IPSec配置和维护的工作量大减。然而之前天地会用过的手工方式IPSec安全策略或IKE方式IPSec安全策略都要求IPSec对端的IP固定。可是在公网IP几近枯竭的Internet上要拥有一个固定的公网IP谈何容易!天地会每次要申请一个固定公网IP地址都要大费周折。于是天地会提出疑问:配置IPSec VPN的通信双方必须使用固定的公网IP地址吗?
当然不是。下面强叔就给大家介绍一种新的IPSec安全策略:模板方式IPSec安全策略。

跟IKE方式IPSec安全策略一样,模板方式IPSec安全策略也要依靠IKE协商IPSec隧道。模板方式IPSec安全策略最大的改进就是不要求对端IP地址固定:可以严格指定对端IP地址(单个IP),可以宽泛指定对端IP地址(IP地址段)也可以干脆不指定对端IP(意味着对端IP可以是任意IP)。
模板方式IPSec安全策略就好像一员猛将,根本不把对端IP放在眼里,什么固定IP、动态地址、私网IP统统不在话下。只管放马过来,来多少都照单全收。正因为这种大将风范,模板方式IPSec安全策略特别适用于天地会总舵,用于响应众多分舵的协商请求。且分舵数量越多越明显:

  • 采用IKE方式IPSec策略。总舵需要配置N个IPSec策略,N个IKE对等体。N=分舵数量
  • 采用模板方式IPSec策略。总舵需要配置1个IPSec策略,一个IKE对等体。与N的取值无关。

总之,模板方式IPSec安全策略的两大优点令他在IPSec阵营中始终保持明星地位:

  • 对对端要求甚少,有固定IP或者没有无所谓
  •  配置简单,只要配置一个IKE Peer即可

但明星也是有缺点的,这个缺点也可以说是模板方式IPSec安全策略“不拘小节”的地方:模板方式IPSec安全策略只能响应对端发起的协商请求,不能主动发起协商。
至此强叔已经介绍了三种IPSec安全策略:手工方式IPSec安全策略、IKE方式IPSec安全策略、模板方式IPSec安全策略。这三种IPSec安全策略都可以配置在一个IPSec安全策略组中。所谓IPSec安全策略组就是一组名称相同的IPSec安全策略。在一个IPSec安全策略组中最多只能存在一个模板方式IPSec安全策略,且其序号必须最大,即优先级最小。否则接入请求被模板接收了,优先级低的IKE方式IPSec策略则无法施展。切记!

分舵接入IP变,模板接收只等闲

总舵跟分舵1和分舵2之间建立IPSec VPN的组网图如下所示。本图中分舵1和分舵2的出接口采用动态方式获取公网IP地址。要求在分舵1跟总舵、分舵2跟总舵之间建立IPSec隧道,分舵1跟分舵2之间也可以通过IPSec通信。
 

 

模板方式IPSec安全策略配置流程如下:


 

分舵2的配置与分舵1类似,请参考分舵1的配置。IKE安全提议和IPSec安全提议采用缺省配置(每个版本的缺省配置可能不同,请配置时注意)。

配置项

天地会总舵(采用模板方式IPSec策略)

天地会分舵1(采用IKE方式IPSec策略)

配置IKE安全提议

ike proposal 10

ike proposal 10

配置IKE对等体

ike peer a

 ike-proposal 10

pre-shared-key tiandihui1

//可以不配置remote-address,也可以通过remote-address指定IP地址段。

ike peer a

 ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1

ACL

acl number 3000

rule 5 permit ip destination 172.16.1.0 0.0.0.255

rule 10 permit ip destination 172.16.2.0 0.0.0.255

//配置一条ACL

rule5允许分舵2和总舵访问分舵1source必须包括分舵2和总舵,destination为分舵1。本例中不指定source,表明source可以为分舵2也可以为总舵或其他IP地址段。

rule10允许分舵1和总舵访问分舵2source必须包括分舵1和总舵,destination为分舵2。本例中不指定source,表明source可以为分舵1也可以为总舵或其他IP地址段。


acl number 3000

rule 5 permit ip source 172.16.1.0 0.0.0.255 //允许分舵1访问分舵2和总舵,source为分舵1destination为分舵2和总舵。本例中不指定destination,表明source可以为分舵2也可以为总舵或其他IP地址段。

IPSec安全提议

ipsec proposal a

ipsec proposal a

IPSec安全策略

ipsec policy-template tem1 1 //配置IPSec策略模板

 security acl 3000

 proposal a

 ike-peer a

ipsec policy policy1 12 isakmp template tem1//配置模板方式IPSec策略

ipsec policy policy1 1 isakmp

 security acl 3000

 proposal a

 ike-peer a

应用IPSec安全策略

interface GigabitEthernet0/0/1

ip address 1.1.1.1 255.255.255.0

ipsec policy policy1

interface GigabitEthernet0/0/1

ip address 2.2.2.2 255.255.255.0

ipsec policy policy1 auto-neg//配置auto-neg后,不需要流量触发就直接建立IPSec隧道

 

部署完成后进行验证:
1. 在总舵IPSec网关上可以查看到总舵跟分舵1和分舵2都正常建立了第一阶段和第二阶段安全联盟。
2. 分舵1、分舵2、总舵可以互相通信。
问题:若在接口上应用IPSec策略时不配置auto-neg参数,分舵1跟分舵2可以直接通信吗?
1. 在分舵1和分舵2的网关取消接口上应用的IPSec策略后,重新应用时不配置auto-neg参数。由分舵1的PC2 ping分舵2的PC3,无法ping通。
2. 查看分舵1上安全联盟的建立情况。
<FW_B> display ike sa
current ike sa number: 2
---------------------------------------------------------------------
conn-id    peer                    flag          phase vpn
---------------------------------------------------------------------
40022      1.1.1.1                RD|ST         v2:2  public
7           1.1.1.1                RD|ST         v2:1  public
分舵1跟总舵之间的安全联盟正常建立。
3. 查看分舵2上安全联盟的建立情况。
<FW_C> display ike sa
current sa Num :0
分舵2跟总部之间没有建立安全联盟。原因在于总部配置了模板方式IPSec安全策略,只能响应协商。所以分舵1到总舵的安全联盟正常创建了,而总舵到分舵2的安全联盟没法建立。在分舵1跟分舵2上应用IPSec安全策略时带上auto-neg参数后,IPSec安全联盟自动创建由于分舵1到总舵、总舵到分舵2之间的安全联盟都已创建好,所以分舵1跟分舵2可以通信。同样总舵可以ping通分舵。
模板方式IPSec安全策略与IKE方式IPSec安全策略都需要通过IKE来协商IPSec隧道。协商的过程一样,这里强叔就不多说了。本篇重点讲讲模板方式IPSec安全策略的“特色”之处。

模板神功露破绽,个性化接入化圆满(仅USG9000系列防火墙支持)

IPSec模板中只能引用一个IKE Peer。而一个IKE Peer中只能配置一个预共享密钥,因此所有与之对接的对端都必须配置相同的预共享密钥。于是问题来了,只要有一个IPSec网关的预共享密钥泄露,则所有其他网关的IPSec安全都受到威胁。
那么在总舵跟多个分舵对接的点到多点的组网中,分舵可以配置不同的预共享密钥吗?既然预共享密钥跟密钥生成和身份认证相关,只要把预共享密钥与设备身份挂钩就可以。预共享密钥认证方式下可以采用本地IP地址或设备名称进行身份认证。那通过IP地址来指定预共享密钥或通过设备名称来指定预共享密钥就可以为每个接入对端配置“个性化的预共享密钥”了。

  • 在总舵通过对端IP地址为每个分舵指定个性化预共享密钥

此方式适用于分舵出口IP地址固定的情况。将总舵在ike peer下面配置的remote-address和pre-shared-key删掉,改为在全局下为每个分舵配置remote-address和pre-shared-key就成,这样既保留模板的先进性,又巧妙规避了模板的局限性。

配置项

天地会总舵

天地会分舵(分舵2的配置跟分舵1类似)

配置IKE对等体

ike peer a

 local-id-type ip

ike-proposal 10


ike peer a

 local-id-type ip

ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1

配置个性化预共享密钥

ike remote-address 2.2.2.2 pre-shared-key tiandihui1

ike remote-address 2.2.3.2 pre-shared-key tiandihui2

-

 

  • 在总舵通过对端设备名称指定预共享密钥

当分舵出口没有固定IP地址时,可以通过设备名称来标识身份(ike local-name),此时总舵在全局下为每个分舵配置remote-id和pre-shared-key即可。

配置项

天地会总舵

天地会分舵1(分舵2的配置跟分舵1类似)

配置IKE对等体

ike peer a

 local-id-type ip

ike-proposal 10

ike peer a

 local-id-type fqdn//通过设备名称进行身份认证时本地认证类型需配置为FQDNUSER-FQDN

ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1


配置本地名称

-

ike local-name tdhfd1

配置个性化预共享密钥

ike remote-id tdhfd1 pre-shared-key tiandihui1

ike remote-id tdhfd1 pre-shared-key tiandihui2

-

说明:本地配置的“对端IP”或“对端ID”必须与对端网关上配置的“本地ID”一致。

IP变化不打紧,域名映射获真身

分舵用动态IP地址接入的情况,IKE方式IPSec安全策略是否真的束手无策呢?
强叔闭目打坐通过对数通知识的融会贯通、举一反三,也找到了一个可以帮助IKE方式IPSec安全策略解决问题的方法:对端IP地址不固定,当然也就无法配置remote-address,但总部可以通过其他方式间接获知IP地址,比如通过域名。即总部可以用指定remote-domain代替remote-address;分部配置DNS获得域名和IP地址之间的映射关系,开启DDNS保证映射关系能够实时更新。当然配置动态域名的方式也适用于模板方式IPSec策略。
说明:此处仅给出配置差异部分。

配置调整

总舵

分舵

IPSec配置

IKE Peer中配置有变化

ike peer a

 ike-proposal 10

pre-shared-key tiandihui1

remote-domain www.adcd.3322.org

无变化

新增配置


1、开启域名解析

dns resolve

dns server 200.1.1.1

2、配置DDNS策略//以下配置需联系DDNS服务提供商,并根据DDNS服务提供商的说明操作。

ddns policy abc

 ddns client www.adcd.3322.org

 ddns server www.3322.org

 ddns username abc123 password abc123

3、应用DDNS策略

ddns client enable

interface dialer 1

 ddns apply policy abc

 

此方案的局限在于动态接入方必须有固定域名,另外增加了DNS和DDNS的配置,有点小复杂,所以强叔至今的感受是“不得不用时才会使用”。
模板方式IPSec安全策略很强大吧?实际场景中,他并不是孤军作战的,只有模板方式IPSec安全策略和IKE方式IPSec安全策略联合作战才能全线告捷:

场景

总舵

分舵

总舵IP地址固定+分舵IP地址固定

IKE方式IPSec策略或模板方式IPSec策略

IKE方式IPSec策略


总舵IP地址固定+分舵IP地址动态获取

IKE方式IPSec策略(指定对端域名)或模板方式IPSec策略

IKE方式IPSec策略

总舵IP地址动态获取+分舵IP地址动态获取

IKE方式IPSec策略(指定对端域名)或模板方式IPSec策略

IKE方式IPSec策略(指定对端域名)

 

看似通过上面三大方案基本可以完美应对总舵-分舵IPSec VPN的各种场景了,但实际上是江湖之所以为江湖就是因为永远会有点风浪:分舵申请不到公网IP地址,只能配置私网IP地址。怎么办,强叔?强叔之所以为强叔,就是因为真的强大,敬请关注下期的强叔侃墙。

 

 

上一篇 VPN篇 IPSec携手IKE,珠联璧合显神威

下一篇 VPN篇 IPSec遭遇NAT处变不惊,见招拆招化险为夷

汇总贴

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
轻松玩转BGP
轻松玩转BGP  精英 发表于 2014-7-22 15:35:46 已赞(0) 赞(0)

等了一周多了!
  • x
  • 常规:

点评 回复

Kiwi
Kiwi  精英 发表于 2014-7-22 15:40:40 已赞(0) 赞(0)

强叔出品必属精品,支持一个!学习下先
  • x
  • 常规:

点评 回复

kmyd
kmyd  大师 发表于 2014-7-22 16:07:14 已赞(0) 赞(0)

太强大了,谢强叔!!
  • x
  • 常规:

点评 回复

mayeror
mayeror   发表于 2014-7-23 01:00:24 已赞(0) 赞(0)

USG5520S是否支持IPSec模板? 明天要用总部USG5520S去对接分公司的Cisco设备。


  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-23 14:50:17 已赞(0) 赞(0)

引用 5 楼

USG5520S是否支持IPSec模板? 明天要用总部USG5520S去对接分公司的Cisco设备。


mayeror 发表于 2014-07-23 01:00

支持配置模板方式IPSec安全策略。这是个老特性都支持的。进行对接的时候需要注意cisco设备跟我们的缺省参数是不是一致。
  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-23 15:51:33 已赞(0) 赞(0)

来支持强叔了。。。。呵呵。。。
  • x
  • 常规:

点评 回复

mayeror
mayeror   发表于 2014-7-23 20:26:29 已赞(0) 赞(0)

回复 6 楼

强叔,今天去搞清楚客户的现在网络情况:客户cisco 3900 上链一个数据中心是用的IPsec VPN, 下联各个分支目前是用DMVPN(mGRE)+EIGRP 。现在是要把C3900换下,他们申请了1个公网IP,目前USG5520S无法配置DSVPN,我目前想到的是GRE over IPsec+OSPF连接分支,给每个分支分别建tunnel,还有没有更好的解决方法,分支越多,建立起来越麻烦,还容易出错?

  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-7-24 18:13:11 已赞(0) 赞(0)

感谢分享!

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-25 09:19:07 已赞(0) 赞(0)

引用 8 楼

强叔,今天去搞清楚客户的现在网络情况:客户cisco 3900 上链一个数据中心是用的IPsec VPN, 下联各个分支目前是用DMVPN(mGRE)+EIGRP 。现在是要把C3900换下,他们申请了1个公网IP,目前USG5520S无法配置DSVPN,我目前想到的是GRE over IPsec+OSPF连接分支,给每个分支分别建tunnel,还有没有更好的解决方法,分支越多,建立起来越麻烦,还容易出错?

mayeror 发表于 2014-07-23 20:26

采用DSVPN后分支之间会建立隧道直接通信,而通过IKE方式或模板方式分支都要通过总部进行通信。这样总部压力比较大。采用模板方式,不会有分支越多越麻烦的问题。为什么要用GRE over IPSec呢,有组播、广播报文吗还是为了采用OSPF动态路由?

NGFW支持DSVPN,要不考虑用NGFW?

  • x
  • 常规:

点评 回复

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

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

登录参与交流分享

登录