结合配置、抓包来分析IKE/IPSec的整个协商过程

IKE/ISKAMP的协商过程

这里主要讲解IKEV1的版本，在V1版本中有两个模式，一个主模式，一个野蛮模式（也称为积极模式），下面就以上一篇的拓扑跟配置为基础，来通过抓包来分析，先从IKE的主模式开始。

IKE与IPSEC相关的配置回顾

当192.168.10.1访问20.2的时候中间发生了什么事情？

当192.168.10.2去ping或者其他流量访问192.168.20.2的时候，数据包会抵达防火墙，防火墙查询路由表

路由表里面最终匹配一条默认路由从G1/0/1出去。

防火墙发现该接口调用了IPSEC的功能，就不会单纯的直接转发出去，它会去判断该流量是否走IPSEC。

判断的依旧就是配置里面写的ACL，BJ这边的内容是当192.168.10.0网段去访问192.168.20.0触发VPN的建立，这个时候就会开始第一阶段的隧道建立，也就是IKE。

提前开启抓包，然后客户端开始ping 20.2，这个时候抓包会现实内容，可以过滤下，输入iskamp，会发现有9个数据包，前面的6个包，它是第一阶段IKE的主模式，有6个包的交互，后面三个是第二阶段 IPSEC SA，采用快速模式建立。

第一阶段建立（IKE）

这是BJ主动发起的isakmp触发建立，里面的内容很多，对于现在最关心的就是红色框起来的，proposal 1，里面的内容会发现，包含了加密AES-CBC-256，认证算法SHA2-256，认证方式预共享密钥，DH组2048位，时间为秒，但是下面数值写的1，其实不是说1秒，而是1天（点开后下面的值是86400）。那这个参数可能会觉得奇怪，实际第一阶段IKE配置里面是没有配置这些加密、认证算法的，那它怎么来的呢？

通过 display ike proposal 可以发现里面原来有这么多内容。

实际上在配置里面，只是配置了一个ike proposal 1，并没有定义详细的参数，但是这里博主说下，不管是思科、华三还是华为的设备，默认都会有一个内置的默认策略，当创建了一个porposal后，没有定义实际的配置，那么就会继承默认参数，但华为防火墙里面有一个更人性化的地方，它默认内置了一个default，并且加密与认证算法都包含了几种不同强度在里面，这样的好处就是尽可能得简化用户的配置，实用默认的就可以直接建立。

这个里面的内容就对应起来了，第一个包的作用就是发送本地IKE安全提议给对方，核心参数有认证方式、认证算法、验证算法跟DH。（display显示的PRF与Intergrity Algorithm这个是IKEV2才需要用到的，但是华为防火墙里面会在安全提议里面一起显示，如果使用的是IKEV1，这个可以不关心，抓包里面也可以体现出来，防火墙并没有携带这两个参数）

当CS防火墙收到以后，会进行回应，在来看第二个包

CS防火墙回应的内容其实跟BJ的一样，这个回复的作用就是跟BJ防火墙协商达成一致，双方采用相同加密算法、认证算法、身份认证、DH组来进行接下来的隧道建立，如果两边有任何一方的这些参数不一致，那么隧道协商直接终止，不在进行下一阶段。（这里比较注意的是，时间参数并不要求两端一致，如果双方有不一致的情况下，那么最终会以最小的为准）

总结：第一阶段1、2个数据包协商的目的是协商出相同的安全提议。

关于第三个包与第四个包的内容则就是利用了DH算法的精髓，Key Exchange是用于交换DH的公开值，而NONCE用于传送临时的随机数，由于交换的只是公开值，而并不是真正的密钥，即时被获取了也无法得到正真的密钥，那我们并不需要了解DH的实际如何去计算的，这个过程是非常复杂，这里来了解了解DH的的作用。

在密钥交互完成后，IKE协商双方会通过配置的预共享密钥跟安全提议来进行复杂的密钥计算，最终会产生三个有用的密钥。

• SKEYID_a：用于ISKAMP完整性验证的密钥，如果ISKAMP中途被篡改，那么直接可以发现并终止协商。
• SKEYID_e：用于ISKAMP消息加密密钥，有了这个密钥，就可以建立一个安全的通道，后续的协商则在这个安全的隧道里面完成，全程加密。

总结下来上面两个数据包的作用是保证后续的ISKAMP消息的安全性、完整性。

• SKEYID_d：这个密钥就比较关键了，之前说IKE可以动态的建立IPSec，它的作用就是衍生出IPSec报文中需要的加密跟验证的密钥（手动配置IPSec的时候是人为定义的，而有了这个密钥则可以自动衍生出来）。

而且整个密钥是有超时时间的，也就是在安全提议里面定义的时间，默认为86400（一天），该时间到期后，又会重新进行DH算，来得到新的密钥，避免了密钥长期不变带来的安全问题。

最后5、6两个包就看不到任何内容了，因为它被DH算法生成的SKEYID_e进行加密了，上面也提到过这个密钥就是用来加密ISKAMP的，建立一个安全的通道，这里就提下这两个包的作用是用于身份认证，主流的两种技术

• 预共享密钥方式：采用设备的IP地址或者名称、别名作为身份信息
• 证书认证：通过签名方式进行认证（用证书的私钥进行HASH得到的值）

在预共享密钥下有一个比较关键的地方一定要注意，在配置中的peer是5、6的关键，它的作用并不是单单的指定对方的隧道地址，它还起到了一个查找密钥的作用，通过这个peer地址能够快速找到对应的预共享密钥来进行验证对端的身份。所以在实际场景中，如果两端都是用固定的公网IP，那么peer的双方一定要保持一致，否则在第五六个包的协商中会出现问题，当让实际中可能还会遇到不是固定的场景，这个后续会讲解解决办法。

总结下来：IKE整体完成的三个关键点

• 生成了ISKAMP的加密和验证密钥，生成了IPSec需要的加密验证密钥。
• 在加密的状态下完成了双方的身份认证（身份信息在后续的案例中会以多种形式出现，比如固定IP、设备名称、域名以及更复杂的证书，证书这次不会演示）
• 有了存活时间，在手工方式下，IPSec隧道是一直存在的，没有超时一说，但是在IKE里面是有存活时间的，默认为一天，一旦超时，那么IKE会重新进行协商建立，所有之前计算得到的密钥全部失效，重新生成，解决了IPSec的最大的密钥管理与维护的问题，这也是上面一篇称IKE为“智能密钥管家”的原因。

第二阶段建立（IPSec SA）

由于第二阶段的包都是被IKE加密了，所以看不到任何内容，它们交互的内容这里来了解下，这也是后面排错的关键部分。

（1）BJ_FW会发送IPSec定义的安全参数，这里就需要了解IPSec定义的安全参数有哪些（包括IPSec的安全提议以及感兴趣流量ACL）和密钥材料给送给对方。

（2）CS_FW收到后回应相同的安全提议，感兴趣流量，并且生成IPSec SA需要的密钥

（3）BJ_FW收到以后，也生成相同的密钥，并且回应对方确认信息，最终完成隧道的建立。

这里说下，IPSecSA的密钥由SKEYID_d、SPI与ESP、NONCE等参数共同进行计算得到IPSec SA加密与验证需要的密钥，后续业务数据通过IPSec SA隧道的时候，则使用对应密钥进行加密与解密，保障数据的安全性，另外IPSec SA也是有超时时间的，默认是3600秒，超过这个时间，整个IKE sa与IPSEC sa都会删除重新建立，这样做的目的为了更加确保安全。

还一个小知识点补充，为了防止KEYID_d密钥泄露的可能性，IKE还提供了一个PFS（完美向前保密）功能，启用该功能后，在IPSec SA协商时候还会进行一次DH交换，重新生成新的IPSec SA密钥，进一步保障安全性，该功能需要两边同时开启。

总结IKE/IPSec结合实现的功能

在手动模式下IPSec SA的全部参数，包括加密、验证密钥都需要用户手动配置（需要人工定期修改）以及建立后SA的时间是永久的，那么在有了IKE以后，IPSec需要的加密、验证密钥通过DH算法生成，可以定期刷新，解决了密钥管理的成本，并且密钥不定期的刷新，提高了安全性，并且IPSec SA也有了时间的参数，可以定期的更新。当一个两边需要建立IPSec的时候，一个数据包（在感兴趣流量内）触发了IPSec过程，那么IPsec会使用ISAKMP/IKE阶段1来构建一个安全的管理连接，这个管理连接可以让两个对等体可以彼此安全的通信，用于共享IPsec的信息（比如共享密钥，验证信息的载荷）。通常也会把第一阶段称为管理连接。 通过这个安全的管理连接，两个IPsec的对等体将协商用于构建安全数据连接的参数，这个安全的数据连接用于传输用户的数据，通常这个ISAKMP/IKE第二阶段也称为数据连接。管理连接与数据连接都各自有一个生存期存在，确保在有人试图破解你安全密钥的情况下，密钥信息在周期性的重新产生来保证安全性。

野蛮模式

在上面提到过在IKE 5、6个包用于身份认证，其中就需要用到固定的IP地址来查找共享密钥，可能出现这样一种情况，双方有一端没有固定IP的情况下，那么早期就通过野蛮模式来解决这个问题，因为野蛮模式中在第一阶段只有三个数据包交互，并且是把安全提议、密钥信息和身份信息一次性打包发给对方，而且在不加密的情况下，对端很轻松的就能知道密钥是什么，也不需要根据IP来查找了。

[BJ_FW]ike peer  cs
[BJ_FW-ike-peer-cs]exchange-modeaggressive
 
[CS_FW]ike peer bj
[CS_FW-ike-peer-bj]exchange-modeaggressive

当我们改成野蛮模式后，在来抓包看看。

抓包可以看到，野蛮模式的BJ_FW第一个包，就把安全提议、密钥交换、NONCE、身份信息一次打包发给对方，并且是明文的方式。

CS_FW收到以后，也回应相匹配的信息给发送方，也是明文的。

第三个包BJ_FW反馈认证结果给CS_FW，这个过程是加密的。

野蛮模式好处就是提高了IKE的效率，从之前的六个包变成了现在的三个，但是坏处就是安全性降低，因为身份信息是基于明文传输的，在实际中野蛮模式通常用于双方有一端不是固定IP或者双方都不是固定IP的场景，后续会在用案例提及到。

主模式与野蛮模式在实际中的使用

建立IPSec是为了在不安全的internet下提供安全性，但是在实际中往往情况会很多，所以关于主模式跟野蛮模式并没有绝对说选择哪个更好，往往要考虑实际的客户环境来做出选择。

• 客户两端都有公网IP，这个时候用主模式
• 客户两端只有一端有公网IP，如果都是华为设备（思科），可以使用主模式
• 客户两端只有一端有公网IP，并且两边设备不是一个厂商，建议使用野蛮模式

这里在多提一句，在工作中往往会以通起来为主要前提，通了后才会去考虑更好的安全性。

回顾IKE/IPSEC的整体配置流程

对于配置流程来说只要明白了IKE、IPSEC的协商流程就知道如何配置了。

第一阶段的重点：两边通过IKE的安全提议与身份认证信息来协商出管理连接，重点是双方的预共享密钥、安全提议、peer、交互模式要一致，一致的情况下，那么第一阶段就没多大问题了。

（1）ike proposal：这个用于定义双方IKE的安全提议，默认系统也内置了参数，注意的地方就是两边一定要一致。

（2）ike peer：这里面有几个关键的地方需要注意

• 默认华为防火墙工作在IKEV2版本，需要通过undo version 2开切换到IKEV1
• Pre-shared-key两边必须一致
• exchange-mode ：默认为main模式，上面配置可以省略，两边保持一致即可
• ike-proposal 调用安全提议，默认情况下是没有调用任何，如果调用了某一个，那么在协商的时候只会发送或者接受该调用的提议，如果没有调用，在配置里面有的提议都会发发送或者来匹配。（display ike proposal）

• remote-address：这个通常情况下是写对方公网地址，在两边都有固定IP的情况下，而且地址一定要指定对，否则在身份验证这块导致密钥查询失败，第一阶段建立不起来。

第二阶段的重点：在IKE建立起来后，紧接着就开始进入IPSec的快速模式，三个包交互，内容包含了感兴趣流量（ACL），IPSec的安全提议，以及算法自动生成的密钥，那么里面由我们可控制的内容就分为两个，一个就是ACL的内容，一个是安全提议，这两个来决定IPSec SA能否协商起来的关键因素，密钥由算法自动生成，人为是控制不了的，也不用去管。