IPSec在实施中经验分享

1、IKE安全提议策略

在实际中IKE的安全提议，双方都要求一致的，那么在华为防火墙里面怎么部署比较好呢

IKEporposal 其实是有默认的策略的，并且可以发现比如认证算法、加密算法包含了多个参数，这样的好处就是

一个porposal就可以包含更多匹配的可能性，减少配置量。

ike proposal default

 encryption-algorithm aes-256 aes-192 aes-1283des des

 dh group14 group5 group2 group1 group20group18 group16 group15

 authentication-algorithm sha2-512 sha2-384sha2-256 sha1 md5

 authentication-method pre-share

这样的一个策略就可以全部匹配了，实际中比较推荐这样做。

USG2000跟5000的默认安全策略

支持的算法也不算强

华为AR路由器早期版本支持的

思科早期版本跟新版本也都不一样，包括华三的，说了这么多，总结下来就是如果在华为下一代防火墙充当一个重要的HUB点（中心），那么可以把一个安全提议支持很多算法，这样呢，在不管对端是什么设备、版本不一致的情况下，安全策略都能够去尽可能的匹配上，减少实施时候的配置量，还一个好处就是后期维护会更加方便，否则策略一多，要去查看配置会更加费劲，当然也有那种要求严格的甲方需求，一个peer只用一个安全提议，那么这个时候就建议用名字命名，能够让自己看起来更容易区分的。

总结下来：IKE的安全提议在支持一个提议容纳多种算法的则直接容纳多个（目前华为下一代防火墙可以，包括思科的路由器默认内置了很多常用的，其他厂商都是多多少少都需要修改的）

2、IKE peer

在peer里面注意的地方比较多

默认情况下，华为下一代防火墙是V1V2版本都启用的，如果现网中使用的V1，而配置里面V1、2都开的话，防火墙发起是以V2发起的，所以通常会输入undo version 2（响应可以支持V1/2）

协商模式，下一代防火墙支持自动模式exchange-mode     auto，它主动发起的时候使用主模式，被动接受的时候则主模式跟野蛮模式都支持，比较适合于在用模板方式的时候，用auto是最好的。

SA超时时间：这个是策略里面唯一不需要匹配的，会以双方最小的值为标准进行统一，在实际中建议一样。

默认情况下本端的ID是以IP来进行验证的，有时候特别在野蛮模式下，可能需要用到别名等方式，可以进行修改。local-id-type     fqdn  |      local-id     USG

NAT穿越，在下一代防火墙中NAT穿越默认是开启的，但是在其他设备里面建议查看ike peer的属性是否开启，否则造成穿越NAT失败的情况。（可以不管它开没开启，手动执行一次）

预共享密钥：这个两边一直即可，注意输入后会进行加密，所以最好做一份记录，以后用的少。

3、IPSec安全提议

对于IPSec的安全提议是没有内置的，但是呢，创建后其实是有内置的参数的。

创建一个ipsec proposal 1

会发现默认是有内置参数的，每个版本不一样可能内置的参数是不一样，所以跟IKE 安全提议一样，尽可能的一个策略去迎合。

ipsec proposal 1

 esp authentication-algorithm sha2-512 sha2-384sha2-256 sha1 md5

 esp encryption-algorithm aes-256 aes-192aes-128 3des des

4、ACL（受保护流量）

ACL没什么特别注意的，在实际中尽量使用精确、明细的匹配方式来做，这样在后期新加跟维护的时候会更加方便，并双方是互为镜像的方式。如果总部与分支的网段比较多，又是基于ACL的方式匹配的话，可以配置地址组，然后在ACL里面可以直接匹配地址组来简化ACL的条目。

5、IPSec策略（模板）

IPSec策略中之前都是按标准讲解的，有些细节的地方没有说明，这里提及下。

由于一个设备下面可以起很多IPSec策略，那么这个时候策略一多，在查看的时候就会非常不方便，推荐使用alias别名的功能，可以为这个策略起一个名字，支持中文，非常方便。

tunnel local：这个通常情况下用不到，如果说一个外网有多个IP的情况下，这个时候如果建立想单独使用一个空闲的地址作为协商，那么就需要通过该命令指定了。

触发方式：之前的讲解中都是以流量触发讲解的，就是当实际业务流量访问，IPSec才能够建立，但是华为是支持自动建立方式的，不用业务触发，也能自动建立。sa     trigger-mode  auto（默认为流量触发）

respond-only     enable：该功能是禁止本端主动发起IPSec建立，平时用不上，在排错的时候有一定帮助，可以定位故障。

在实际部署中一个接口只能调用一个IPSec策略，可能会存在策略方式以及模板方式共存，那么这个时候，模板方式的ID建议在最后，比如ID 1000，策略方式的ID在前面，这样在实施的时候减少故障率。

6、接口调用

接口调用的话注意一个策略只能调用一个IPSec安全策略，并且如果要删除某一个IPSecpolicy 的某个ID并且有对应的IKE SA与IPSEC SA信息的时候，需要先去掉接口调用才能删除，否则会提示删除不了。

如果IPSec建立过程中，一端出现故障或者设备重启后发现隧道建立不起来了怎么办？      

正常情况下192.168.10.1访问20.2通过IPSec访问没任何问题，但是这个时候突然CS_FW那边跳闸了，导致设备重启，这个时候就会出现一个问题。

造成BJ这边有IKE与IPSec sa信息，而CS那边由于重启了没有了这些信息，那么这个时候数据访问就会出现问题。

因为在BJ_FW这边它是有IKE与IPSec Sa的，能够直接用SA信息进行加密数据出去，但是到了CS那边，由于重启的原因，SA信息丢失，无法直接加解密，则直接丢弃了。

解决这个问题，实际有三种办法

keepalive与heartbeat：这两种方式用的少，原因是（1）周期性的发送会消耗CPU （2）每个厂家的标准不一样，存在兼容性问题，无法对接，在实际中用的很少。

DPD：非常灵活，支持周期性发送与按需性发送，而且兼容性好，所以在实际中建议采用DPD的方式。

按需型：本端需要向对端发送IPSec数据业务时，如果当前距离最后一次收到对端的IPSec报文的时长已超过DPD空闲时间，则触发DPD检测，本端主动向对端发送DPD请求报文。

周期型：如果当前距离最后一次收到对端的IPSec报文或DPD请求报文的时长已超过DPD空闲时间，则本端主动向对端发送DPD请求报文。

主动向对端发送DPD请求报文后，若在DPD报文重传间隔内没有收到对端的DPD回应报文，则向对端重传DPD请求报文，根据重传次数进行重传之后，若仍然没有收到对端的DPD回应报文，则认为对端离线，删除该IKE      SA和对应的IPSec SA。

DPD的配置

基于IKE 进程单独配置，这样只用于单个进程

ikepeer  cs

dpd type on-demand

全局配置，会应用于全部IKE peer

ike dpd type on-demand

（这里注意DPD配置后，建议清空SA信息，然后重新建立隧道，在模拟一次故障，否则会出现不生效的情况。）

这个时候在去访问业务端，由于这里我们采用的是按需的方式，那么DPD会触发检测，会发送请求报文，请求报文会发送3次，如果对方依旧没有相应，则会清空IKE与IPSec SA信息。

这个时候在去访问就正常了，因为两边会重新开始建立。

DPD使用建议

建议基于ike peer进程来创建，因为在实际中可能每个peer之间的链路环境不一样，可以根据不同环境选择按需还是周期（如果是hub环境，hub这边建议选择周期。）

建议两边都开启，因为在实际中任何一边都有可能发生故障。

配合自动建立效果更佳。

如果一边有动态公网地址，一边没有，能否建立IPSec呢？

如果一边有动态公网地址，是可以建立的，需要在动态地址那边关联动态域名（比如3322或者花生壳等），然后做模板方式，最关键的就是没有公网地址端的配置。

ike peer  1

remote-addresshost-name  ccieh3c.com  （可以直接指定实际申请的DDNS域名）

注意的是设备本身要开启DNS解析，否则解析不到当前域名所在的IP地址导致访问失败。（一般DHCP或者拨号的都会自动下发DNS的，可以通过display  dns server查看，也可以手动dns server设置DNS服务器地址。）

IPSec模板实际中部署（提高对接率，减少故障）

在下一代防火墙中，有这样的一个功能，配合模板方式特别好使，这个是35篇的内容，CD_FW与CS_FW都是动态或者是私网地址，BJ_FW是以模板的时候配置的，在实际环境中，分支这边可能由于设备型号不一致、版本、厂商等情况导致支持的安全参数不一样，那么这个时候统一就有点困难，BJ_FW这边需要建立多个安全提议去匹配，有这样一个功能“协议兼容”。

ikepeer BJ

ikenegotiate compatible

该功能启用后，对方发送过来的IKE安全提议以及IPSec的安全提议，如果本地没有相对于的匹配，直接以对方发送过来的参数进行响应，这种方式在实际中部署可以大大提高连接的成功率，但是有一定的风险，可能对方是低安全策略，造成风险的可能。（适合分支设备厂商比较杂的情况，建议可以做做实验，把CS_FW与CD_FW的IKE与IPSec的加密算法与安全算法全部改掉，跟BJ_FW不匹配，然后测试下是否能够建立起来隧道。）

实战案例题（1）：如果防火墙上面部署了策略路由、NAT server，对IPsec有什么影响吗？

实战案例题（2）：如果外网有多条线路，这个时候IPSec怎么部署好？

实战案例题（3）：如果防火墙单独作为一个IPSec server，应该如何融入到网络

视频补充（4）：WEB端配置讲解

IPSec实际注意的地方

IPSec在实际中除了对接上面注意的地方，除了上面说安全提议策略以外，在实际中还需要考到线路问题。

尽量双方在部署的时候选择同一个运营商的，比如固定专线那边是电信、那边其他点用电信是最好的

不同运营商之间建立IPSec隧道，延迟跟稳定性不如同一个运营商，这个在部署  的时候告知客户

如果分支之间需要互访，但分支又没有动态公网地址，那只能通过总部之间中转。

如果分支采用的猫拨号（猫是路由模式），有可能会导致IPSec隧道建立不起来的情况，建议改成桥接模式

总部与分支，以及其他分支之间的网段是不能重叠的，就是不能有相同的，否则建立不起来的情况。

以上就是IPSec在实施中经验分享的介绍，Vecloud为国内外用户供给包括全球主机托管、主机租用、云专线接入等方面的专业服务，资源覆盖全球。欢迎咨询。