IKE简介

一、 IKE协商的阶段简单描述：

       IKE协商采用的UDP报文格式，默认端口是500，在主模式下，一个正常的IKE协商过程需要经过9个报文的来回，才最终建立起通信双方所需要的IPSec SA，然后双方利用该SA就可以对数据流进行加密和解密。下面结合简单描述一下协商的过程。

         假设A和B进行通信，A作为发起方，A发送的第一个报文内容是本地所支持的IKE的策略（即下面所提到的Policy），该policy的内容有加密算法、hash算法、D-H组、认证方式、SA的生存时间等5个元素。这5个元素里面值得注意的是认证方式，目前采用的主要认证方式有预共享和数字证书。在简单的VPN应用中，一般采用预共享方式来认证身份。在本文的配置中也是以预共享为例来说明的。

        可以配置多个策略，对端只要有一个与其相同，对端就可以采用该policy，并在第二个报文中将该policy发送回来，表明采用该policy为后续的通信进行保护。

        第三和第四个报文是进行D-H交换的D-H公开值，这与具体的配置影响不大。在完成上面四个报文交换后，利用D-H算法，A和B就可以协商出一个公共的秘钥，后续的密钥都是从该秘密衍生出来的。

        第五和第六个报文是身份验证过程，前面已经提高后，有两种身份验证方式——预共享和数字证书，在这里，A将其身份信息和一些其他信息发送给B，B接受到后，对A的身份进行验证，同时B将自己的身份信息也发送给A进行验证。采用预共享验证方式的时候，需要配置预共享密钥，标识身份有两种方式，其一是IP地址，其二是主机名（hostname）。在一般的配置中，可以选用IP地址来标识身份。完成前面六个报文交换的过程，就是完成IKE第一阶段的协商过程。如果打开调试信息，会看到IKE SA Establish（IKE SA已经建立），也称作主模式已经完成。

        其余的三个报文主要是协商IPSec SA，利用第一阶段所协商出来的公共的秘钥，可以为该三个报文进行加密。在配置中，主要涉及到数据流、变换集合以及对完美前向保护（PFS）的支持。在很多时候，会发现IKE SA已经建立成功，但是IPSec SA无法建立起来，这时最有可能的原因是数据流是否匹配（A所要保护的数据流是否和B所保护的数据流相对应）、变换集合是否一致以及pfs配置是否一致。

配置数据流（access-list）：
很容易理解，部署任何VPN都需要对数据流所限制，不可能对所有的数据流都进行加密（any to any）。配置好数据流后，在加密映射（map）中引用该数据流。

变换集合(transform-set)：即传输模式，是某个对等方能接受的一组IPSec协议和密码学算法。分为三种模式：AH验证，ESP加密，ESP验证。每种模式有不同的参数，每种参数类型中只可选一个方式，但是可以同时选3种传输模式。

转载于:https://www.cnblogs.com/jone_linux/archive/2009/09/15/1566765.html