配置错误导致IPSec VPN不通

最近，笔者所在的公司为了开展一项新的业务，需要与外地的另一家公司进行内部数据上的互访，我们选择了在互联网出口建立IPSec VPN，通过加密隧道，在用互联网传送内部专网的内容的同时，保证内部数据的安全性，实现企业之间的业务互通。

虽然IPSec VPN对企业虚拟业务专网的构建有着诸多好处，但是由于互联网环境的复杂，真正实施起来却并不轻松，笔者负责我公司这边的接口建立，就遇到了一点小麻烦，甚至差点影响到新业务的开展，处理故障所积累的一些经验，与大家分享。

我们知道，IPSec VPN的建立分为两个阶段：第一阶段，VPN客户端和接入点互相认证，确认对方身份；第二阶段，主要是协商针对特定的流量采用什么样的加密传输策略以及传输数据的完整性校验策略。通常情况下，我们只要把两边的IPSec参数设置成相同，并且感兴趣数据流匹配了，通道就能建立起来了。于是，按照对方提供的参数，配置了本端设备。

故障现象

配置完成后，发现通道并没有建立。难道是参数提供有误吗？联系了对方的工程师，确认了配置参数是一致的，并用display ike peer和display ike proposal查看配置信息确认也是一致的。对方工程师告诉笔者，对方使用的设备与本端是同一厂家不同系列的，比我方的配置要高，版本要新。会不会是新版本的设备和老版本的兼容性有问题呢？设备厂家的售后工程师告诉笔者，以前并没有遇到过这种情况，还是应该从IPSec的配置上找原因。

故障排查

使用debug命令抓取VPN设备的IKE和IPSec数据，发现了“IKE/7/DEBUG:recv ID: find ike peer by address (0x0affff01)failed!”这样一条数据，意思是寻找对端的IP地址失败，和对端的IP地址之间无法通信。可对端的IP地址是可以Ping通的呀。使用display firewall session table verbose destination-port 500命令查看设备的连接信息，发现对端设备一直有数据包发过来，而我方设备没有回去的数据包，这是怎么回事呢？难道是设备的访问策略有问题吗？再次联系对方的工程师，双方将设备的访问策略暂时全部放开，通道仍然没有建立起来。对方的工程师告诉笔者，IPSec的配置信息是参照其他正在运行的链路的，应该不会有问题。

配置信息没问题，那会不会链路上有什么问题呢？一筹莫展之时，公司为其他项目采购的一批新的防火墙到货了。对了，本地搭建一个环境测试一下吧，正好也熟悉一下新的设备。虽然不是同一个品牌的防火墙，通道还是成功地建立了，也证实了笔者的猜测，链路上一定有问题。

又一次联系对方的工程师，这次大概摸清了整个网络的结构。笔者这边比较简单，支持IPSec VPN的一台防火墙架设在公网的接口上，内网的客户端需要去访问对方的服务器。而对方公司的网络结构就比较复杂了，对方的防火墙是在内网，通过端口映射成公网IP，笔者这边的内网IP需要先转换成特定的IP地址，经过IPSec通道到达对方网内后，再经过对方的再次地址转换去访问第三方的服务器。

这样的网络环境，我们在防火墙上启用了NAT穿越，于是笔者怀疑是对端NAT设备的映射有问题。对方的工程师给笔者提供了一条不经过NAT的链路测试，也证实了笔者的猜想是正确的，通道能够正常建立起来。于是，我们一起对设备的NAT映射做了一一比对，却没有发现任何问题。

在这里介绍一下IPSec的作用，即数据的机密性、完整性、认证性。机密性就是保证数据包的原始内容不被看到；完整性即保证数据包的内容不会被修改；认证性保证数据来自被信任的客户端。IPSec中的封装格式有两种（AH和 ESP），AH在IP数据包中插入了一个包头，其中包含对整个数据包内容的校验值；ESP用户加密整个数据包内容，同时也可以对数据包进行认证。IPSec有两种不同的模式：传输模式和隧道模式。一种是传输模式，主要用于主机到主机之间的直接通信。另一种是隧道模式主要用于主机到网关或网关到网关之间。传输模式和隧道模式主要在数据包封装时有所不同。无论传输模式还是隧道模式，AH都会认证整个数据包，并且AH还会认证位于AH头之前的IP 头。当NAT设备修改了IP 头之后，IPSec就会认为这是对数据包完整性的破坏，从而丢弃数据包，因此，AH是不可能和NAT 在一起工作的。而ESP在传输模式时会保护TCP/UDP头，但是并不保护IP头，因此，修改IP地址并不会破坏整个数据包的完整性。但是，如果数据包是TCP/UDP数据包，NAT设备就需要修改数据包的校验值，而这个校验值是被ESP所保护的，这样却会导致完整性校验失败。所以，最终可能和NAT一起工作的只能是隧道模式下的ESP。

故障解决

正在我们一筹莫展的时候，我在一个技术论坛里看到了这样一句话，“IKE V2和IKE V1一样，也是使用UDP500端口进行IKE SA和IPSec SA的协商,但是不再存在ESP和AH的流量了,因为在后续的流量中，统一流量都是UDP4500传输了。也就是说，在IKE V2的环境里，不再担心NAT环境了”。之前的防火墙配置里面，我们一直使用的是IKE V1，换成IKE V2试试看，通道终于建立起来了！

经验总结

这真是想不到，IKE的版本居然会受到NAT的影响，印象中无论是哪个版本都应该支持NAT穿越的！

IKE V1阶段1的目的是建立IKE SA，它支持两种协商模式：主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快，但是由于野蛮模式密钥交换与身份认证一起进行而无法提供身份保护。IKE V1阶段2的目的就是建立用来传输数据的IPSec SA，通过快速交换模式（3条ISAKMP消息）完成协商。而IKE V2简化了协商过程，IKE V2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA，如果要求建立的IPSec SA大于一对时，每一对SA只需额外增加1次交换，也就是2条消息就可以完成。

IPSec VPN配置完成后，出现故障的几个可能原因及排查方法。

1.感兴趣流是否匹配

可以用display acl acl-number命令来检查流量是否匹配了acl规则，例 如 dis acl 3001，返 回信 息rule 5 permit ip source 10.11.12.0 0.0.0.7 destination 10.11.13.11 0 (0 times matched)。

命中次数为0表示流量没有命中规则，不会触发建立隧道。这时要检查源地址和目的地址是不是符合实际数据流的信息。

2.两端设备的IKE安全提议配置是否一致

分别在两端的IPSec设备上执行命令display ike proposal，查 看 两 台设备的IKE安全提议配置是否一致，包括加密算 法（authentication algorithm）、认 证 算 法（encryption algorithm）和DH组标识（Diffie-Hellman group）等。

3.对端IP地址或对端域名配置错误、两端设备的预共享密钥配置是否一致、是否启用了NAT穿越功能。

分别在两端的IPSec设备上执行命令display ike peer name，查看对端IP地址是否配置正确，两端设备的预共享密钥是否一致，两端IKE版本是否一致，是否启用了NAT穿越功能等。

4.两端设备的IPSec安全提议配置是否一致

分别在两端设备上上执行命令display ipsec proposal，查看两台设备的IPSec安全提议配置是否一致，包括采用的安全协议、安全协议采用的认证算法和加密算法、报文封装模式等。

5.两端设备的PFS功能配置参数是否一致

两台设备的PFS功能指定的DH组必须一致，否则IPSec隧道协商失败。分别在两端设备上执行命令display ipsec policy，查看两台设备的PFS功能参数配置是否一致。

6.IPSec安全策略顺序号配置是否正确

在设备上可以创建多个具有相同名字的IPSec安全策略，这些IPSec安全策略可以组成一个IPSec安全策略组，序号越小优先级越高，接口将优先处理该IPSec安全策略，优先为该IPSec安全策略定义的数据流建立IPSec隧道。因此确保需要使用的IPSec安全策略的序号最小。分别在两端设备上执行命令display ipsec policy，查看两台设备的IPSec安全策略顺序号。

7.IPSec安全策略应用是否在正确的接口上

IPSec安全策略应用到的接口一定是建立隧道的接口，且该接口一定是到对端私网路由的出接口。误将IPSec安全策略应用到其他接口会导致VPN业务不通。

8.安全策略和NAT策略配置问题

为了保证IPSec隧道正常建立，需要正确配置安全策略，包括Local区域与应用IPSec策略的接口所在区域间的安全策略，以及内网接口所在安全区域与应用IPSec策略的接口所在区域间的安全策略；配置NAT策略时需要对IPSec保护的数据流不做NAT转换。

9.是否已清除旧的或已经存在的SA（安全联盟）

当管理员修改或增加IPSec配置后，要使用reset ike sa和reset ipsec sa命令清除旧的或已经存在的SA。

总的来说，在IPSec VPN的配置上，首先要保证两端数据的一致性，然后在路由、安全策略和NAT策略上一定要正确，在故障筛查时，更是不能放过任何一个细节，多做测试，否则，有些故障真是想破了脑袋也想不出解决方法来啊。