IPSEC流程例子及两个阶段的协商过程详细介绍

IPSEC VPN两个阶段的协商过程详细介绍

IPSec体系结构模型图

　　我们来看一个完整的IPSec体系结构模型图，以便更好地理解IPSec体系结构。

　　IPSec流程图

SAKMP/IKE第一阶段称为ISAKMP/IKE的管理连接阶段.使用双向的UDP端口为500的数据连接,来共享IPSEC消息.

第一阶段

有主模式和积极模式2种

主模式执行3步,6个数据包的双向交换.过程如下:

1.对等体间协商如何来保护管理连接.(使用加密变换集来保护)

2.对等体间使用DH算法来共享密钥以及保护连接.

3.对等体间进行彼此的验证.

积极模式执行的过程:

1.交换保护管理连接的策略,DH算法建立公钥/密钥对并在对等体间进行认证.

2.对收到的数据包做验证,DH算法来共享加密的密钥,并查看连接是否成功建立.

PS:除了预共享密钥认证外.其他的认证方式默认为主模式.

注意!!!只有remote vpn和Easy vpn是积极模式的,其他都是用主模式来协商的
让IKE对等体彼此验证对方并确定会话密钥,这个阶段永DH进行密钥交换,创建完IKE SA后,所有后续的协商都将通过加密合完整性检查来保护
phase 1帮助在对等体之间创建了一条安全通道,使后面的phase 2过程协商受到安全保护

第二阶段
快速模式
协商IPSEC SA使用的安全参数,创建IPSEC SA,使用AH或ESP来加密IP数据流
总结
第一阶段作用-----对等体之间彼此验证对方,并协商出IKE SA,保护第二阶段中IPSEC SA协商过程
第二阶段作用-----协商IPSEC 单向SA,为保护IPS数据流而创建
主模式协商
IKE phase 1在IPSEC对等体间交换6条消息,这些消息的具体格式取决于使用的对等体认证方法

一,使用预共享密钥进行验证的主模式(6条)
协商过程使用ISAKMP消息格式来传递(UDP 500)

第一阶段
准备工作
在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息
cookie---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识, 实际上cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个 cookie值

1&2消息
消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命)
消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应
注意!!!发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）

在1&2消息中报错可能出现的原因
1，peer路由不通
2，crypto iskmp key没有设置
3，一阶段的策略不匹配

3&4消息
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID
随后便根据SKEY__ID来推算出其他几个skeyID
skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密

5&6消息
这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)
HASH认证成分－－－SKEYID_a,cookieA,cookieB，preshare_key,SA paload,转换集，策略

在5&6消息中报错可能出现的原因
1，crypto iskmp key设置错了

消息6--接受者处理过程
1,用skeyID_e对消息进行加密 2,用ID(源IP)查找出与共享密钥 3,skeyID_a和preshare-key等一堆东西一起来计算HASH 4,和收到的HASH做比较

第二阶段(3条)
phase 2的目标是协商IPSEC SA,而且只有一种模式,快速模式,快速模式的协商是受IKE SA保护的

1&2消息
消息1---发送方发送一条报文,其中包含HASH,IPSEC策略提议,NONCE和可选的DH,身份ID
HASH:是用于给接受方作完整性检查的,用于再次认证对等体(必须)HASH的成分和5－6阶段一样
IPSEC策略提议:其中包括了安全协议,SPI,散列算法,隧道模式,IPSEC SA生命周期(必须)
NONCE:用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到
ID:描述IPSEC SA是为哪些地址,协议和端口建立的
PFS(利用DH交换,可选):用了PFS后就会在第二阶段重新DH出个数据加密KEY,这个KEY和以前IKE协商出来的KEY没有任何关系,然后由这 个新KEY来加密数据，只有到这个IPSEC SA的生命周期后,会再次DH出新的KEY,这样,安全性就提高了（普通等ipec SA过期或密钥超时时，重新生成的数据加密密钥还是根据以阶段DH出来的skeyID_d衍生出来的）（PFS启用后，数据加密部分使用的密钥就没有了衍 生的过程）
DH:重新协商IPSEC SA实使用的密钥(正常情况下IPSEC阶段使用的密钥都是由skeyID_d衍生而来,密钥之间都有一定的关系,就算IPSEC SA超时,新的KEY还是和skeyID_d有一定的关系)

在1&2消息中报错可能出现的原因
1，ipsec trasport不匹配
2，感兴趣流不对称

消息2---使用相同的消息进行相应

3消息

发送方发送第三条消息,其中包含一个HASH,其作用时确认接受方的消息以及证明发送方处于Active状态(表示发送方的第一条消息不是伪造的)

IPSec流程实例

　　为简单起见，我们假设这是一个Intranet例子，每台主机都有处于激活状态的IPSec策略：

　　1．用户甲（在主机A上）向用户乙（在主机B上）发送一消息 
　　2．主机A上的IPSec驱动程序检查IP筛选器，查看数据包是否需要受保护以及需要受到何种保护 
　　3．驱动程序通知IKE开始安全协商 
　　4．主机B上的IKE收到请求安全协商通知 
　　5．两台主机建立第一阶段SA，各自生成共享"主密钥" 注：若两机在此前通信中已经建立起第一阶段SA，则可直接进行第二阶段SA协商 
　　6．协商建立第二阶段SA对：入站SA和出站SA。SA包括密钥和SPI。 
　　7．主机A上IPSec驱动程序使用出站SA对数据包进行签名（完整性检查）与/或加密。 
　　8．驱动程序将数据包递交IP层，再由IP层将数据包转发至主机B 
　　9．主机B网络适配器驱动程序收到数据包并提交给IPSec驱动程序。 
　　10．主机B上的IPSec驱动程序使用入站SA检查完整性签名与/或对数据包进行解密。 
　　11．驱动程序将解密后的数据包提交上层TCP/IP驱动程序，再由TCP/IP驱动程序将数据包提交主机B的接收应用程序。

　　以上是IPSec的一个完整工作流程，虽然看起来很复杂，但所有操作对用户是完全透明的。中介路由器或转发器仅负责数据包的转发，如果中途遇到防火墙、安全路由器或代理服务器，则要求它们具有IP转发功能，以确保IPSec和IKE数据流不会遭拒绝。

　　这里需要指出的一点是，使用IPSec保护的数据包不能通过网络地址译码NAT。因为IKE协商中所携带的IP地址是不能被NAT改变的，对地址的任何修改都会导致完整性检查失效。