IPSEC 004 ---- 模板海纳百川，不定对端有容乃大

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 隧道的组网图如下所示。本图中分舵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和总舵访问分舵1，source必须包括分舵2和总舵，destination为分舵1。本例中不指定source，表明source可以为分舵2也可以为总舵或其他IP地址段。 rule10允许分舵1和总舵访问分舵2，source必须包括分舵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为分舵1，destination为分舵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//通过设备名称进行身份认证时本地认证类型需配置为FQDN或USER-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地址。怎么办，强叔？强叔之所以为强叔，就是因为真的强大，敬请关注下期的强叔侃墙。