第九章 IPSec VPN技术

目标 学完本课程后，您将能够: 理解IPSec技术的基本原理 理解AH和ESP技术 了解IKE协议的业务流程 掌握IPSec VPN的应用场景及配置

目录 IPSec VPN概述 IPSec VPN体系结构 验证头（AH）技术 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术 IPSec VPN应用场景分析

IPSec简介 IPSec（IP Security）协议族是IETF制定的一系列安全协议，它为端到端IP报文交互提供了基于密码学的、可互操作的、高质量的安全保护机制。IPSec VPN是利用IPSec隧道建立的网络层VPN。 总部 分支机构 IPSec VPN 安全隧道

IPSec特性 IPSec 机密性 防重放 完整性 真实性 Confidentiality Data integrity Anti-replay Data authentication Data integrity 完整性 机密性 真实性 IPSec 机密性：对数据进行加密，确保数据在传输过程中不被其它人员查看； 完整性：对接收到数据包进行完整性验证，以确保数据在传输过程中没有被篡改； 真实性：验证数据源，以保证数据来自真实的发送者（IP报文头内的源地址）； 抗重放：防止恶意用户通过重复发送捕获到的数据包所进行的攻击，即接收方会拒绝 旧的或重复的数据包。

IPSec安全防护特点 APP Data TCP/ UDP IP 安全保护区域 访问总部流量 IPSec VPN 分支机构 Internet业务 访问总部流量 访问Internet部流量 支持在IP层及以上协议层进行数据安全保护，并对上层应用透明（无需对各个应用程 序进行修改）。安全保护措施包括机密性、完整性、真实性和抗重放等。 IPSec协议基于策略对数据包进行安全保护，如对某业务数据流采用某类保护措施， 而对另一类业务数据流采用其它类保护措施，或不进行任何保护措施。 本图例中，访问总部的流量实施安全保护，而对于访问互联的流量，则不进行安全保 护。

IPSec安全防护场景 IPSec端到端应用场景 安全网关（如防火墙）之间（典型场景）； 主机与安全网关之间； 主机与主机之间； 总部 出差员工 分支机构 IPSec VPN WWW服务器 IPSec端到端应用场景 安全网关（如防火墙）之间（典型场景）； 主机与安全网关之间； 主机与主机之间； 当分布于不同地域的企业或个人通过Internet进行通信时，由于处于不同的物理地域 ，它们之间进行通信的绝大部分流量都需要穿越Internet上的未知网络，无法保证在网络 上发送和接收数据的安全性。 IPSec提供了一种建立和管理安全隧道的方式，通过对要传输的数据报文提供认证和 加密服务来防止数据在网络内或通过公网传输时被非法查看或篡改，相当于为位于不同地 域的用户创建了一条安全的通信隧道。 应用场景主要由以下三种类型： 网关（如防火墙）之间 此种应用场景也叫点到点或点到多点IPSec VPN，主要用于公司总部与分支机构之间 建立IPSec隧道，从而实现局域网之间互通。 主机与网关之间 主要用于出差员工通过互联网需要访问总部资源时。 主机与主机之间 主机之间通过互联网进行数据传输，需要加密时，加解密操作在主机侧完成。某些场 景中，例如服务器放在DMZ区域，防火墙配置NAT server,也可以实现。

目录 IPSec VPN概述 验证头（AH）技术 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术

IPSec VPN体系结构 除提供AH协议的所有功能外（但其数据完整性校验不包括IP头），还可提供对IP报文的加密功能 AH提供数据完整性、数据源验证和抗报文重放功能, AH并不加密所保护的数据报 IPSec VPN体系结构 AH：验证头 ESP和AH定义了协议和载荷头的格式及所提供的服务，但却没有定义实现以上能力所需具体转码方式，转码方式包括对数据转换方式，如算法、密钥长度等。为简化IPSec的使用和管理，IPSec还可以通过IKE进行自动协商交换密钥、建立和维护安全联盟的服务。 ESP：封装安全载荷 IKE协商 验证算法 加密算法 IPSec VPN体系结构主要由AH、ESP和IKE协议套件组成。IPSec通过ESP来保障IP 数据传输过程的机密性，使用AH/ESP提供数据完整性、数据源验证和抗报文重放功能。 ESP和AH定义了协议和载荷头的格式及所提供的服务，但却没有定义实现以上能力所需 具体转码方式，转码方式包括对数据转换方式，如算法、密钥长度等。为简化IPSec的使 用和管理，IPSec还可以通过IKE进行自动协商交换密钥、建立和维护安全联盟的服务。 具体介绍如下： AH协议：AH是报文头验证协议，主要提供的功能有数据源验证、数据完整性校验和 防报文重放功能。然而，AH并不加密所保护的数据报。 ESP协议：ESP是封装安全载荷协议。它除提供AH协议的所有功能外（但其数据完 整性校验不包括IP头），还可提供对IP报文的加密功能。 IKE协议：IKE协议用于自动协商AH和ESP所使用的密码算法。 密钥管理 安全策略

IKE与AH/ESP之间关系 IKE IKE KEY KEY IP TCP UDP TCP UDP AH/ESP AH/ESP IKE是UDP之上的一个应用层协议，是IPSec的信令协议。IKE为IPSec协商生成密钥, 供AH/ESP加解密和验证使用。AH协议和ESP协议有自己的协议号，分别是51和50。

IPSec安全协议 AH（Authentication Header）报文头验证协议，主要提供的功能有数据源验证、数据完整性校验和防报文重放功能；然而，AH并不加密所保护的数据报文。 AH ESP（Encapsulating Security Payload）ESP是封装安全载荷协议。它除提供AH协议的所有功能外（但其数据完整性校验不包括IP头），还可提供对IP报文的加密功能。 ESP IPSec通过AH（Authentication Header）和ESP（Encapsulating Security Payload）这两个安全协议来实现数据报文在网络上传输时的私有性、完整性、真实性和防重放。 AH和ESP是IPSec的两个主要协议。认证头（AH , Authentication Header）协议为IP 通信提供数据源认证、数据完整性检验和防重放保证。封装安全载荷（ESP, Encapsulating Security Payload）为IP通信提供完整性检验、认证、加密和防重放保证。 AH和ESP可以单独使用，也可以同时使用。 在实际的组网中,ESP协议使用较多。

IPSec协议封装模式 传输模式 隧道模式 Data IPH Data IPH IPSec New IPH IPSec Data 在传输模式下，IPSec头被插入到IP头之后但在所有传输层协议之前，或所有其他IPSec协议之前。 传输模式 在隧道模式下， IPSec头插在原始IP头之前，另外生成一个新的报文头放到AH或ESP之前。 隧道模式 IP报头与原始IP分组中的IP报头是一致的，只是IP报文中的协议字段会被改成IPSec协议的协议号（50或者51) ，并重新计算IP报头校验和。 Data IPH 传输模式 Data IPH IPSec IPSec协议有两种封装模式：传输模式和隧道模式。 在传输模式下，IPSec协议处理模块会在IP报头和高层协议报头之间插入一个IPSec报 头。在这种模式下，IP报头与原始IP分组中的IP报头是一致的，只是IP报文中的协议字段 会被改成IPSec协议的协议号（50或者51) ，并重新计算IP报头校验和。传输模式保护数 据包的有效载荷、高层协议，IPSec源端点不会修改IP报头中目的IP地址，原来的IP地址 也会保持明文。传输模式只为高层协议提供安全服务。这种模式常应用在需要保护的两台 主机之间的端到端连接，而不是多台主机的两个网关之间的数据流。 与传输模式不同，在隧道模式下，原始IP分组被封装成一个新的IP报文，在内部报头 以及外部报头之间插入一个IPSec报头，原IP地址被当作有效载荷的一部分收到IPSec的保 护。另外，通过对数据加密，还可以隐藏原数据包中的IP地址，这样更有利于保护端到端 通信中数据的安全性。 传输模式（Transport Mode）： 1）应用场景1：主机与网络安全网关之间的通信； 2）应用场景2：主机与主机之间的通信。 隧道模式（Tunnel Mode）： 1）应用场景：网络安全网关与网络安全网关之间的通信。 隧道模式 New IPH IPSec Data Org IPH

IPSec协议封装模式对比 IP数据 原IP头 IPSec头 原IP数据 新IP头 传输模式： 隧道模式： 封装模式对比： 安全性： 性能： 具体选择那封装模式，需要在性能和安全之间做权衡 。

传输模式的安全保护范围 传输模式主要用于主机到主机之间的端到端连接，它使用原始IP包头中的地址进行寻址。为上层协议提供安全保护，只保护IP包的有效载荷。 IP头 传输层数据报 IP头 IPsec头 传输层数据报

隧道模式的安全保护范围 隧道模式主要用于两个安全网关（如路由器）之间的连接，它通过将新的IP包头添加到原始IP包头之前来实现IP-in-IP的封装。原始IP包头在隧道中传输的时候被保留，直到隧道终端删除附加包头时才使用。隧道模式实现对整个IP包进行保护。

加密和验证算法 加密算法 验证算法 计算复杂度与加密强度没必然联系 MD5( 128bit ) DES ( 56bit64bit ) AES (128、192、256) 国密(256) 验证算法 MD5( 128bit ) SHA-1( 160bit ) 加密算法： ESP能够对IP报文内容进行加密保护，防止报文内容在传输过程中被窥探。加密算法实 现主要通过对称密钥系统，它使用相同的密钥对数据进行加密和解密。 一般来说IPSec使用加密算法有以下几种： DES（Data Encryption Standard） 使用56bit的密钥对一个64bit的明文块进行加密。 3DES（Triple Data Encryption Standard） 使用三个56bit的DES密钥（共168bit密钥）对明文进行加密。 AES（Advanced Encryption Standard） 使用AES密钥对明文进行加密。密钥的长度分为128bit、192bit、256bit。 3DES比DES具有更高的安全性，但其加密数据的速度要比DES慢得多。AES比 3DES的计算复杂度低，而加密强度却比3DES高。 验证算法： AH和ESP都能够对IP报文的完整性进行验证，以判别报文在传输过程中是否被篡改。 验证算法的实现主要是通过杂凑函数，杂凑函数是一种能够接受任意长的消息输入，并产 生固定长度输出的算法，该输出称为消息摘要。IPSec对等体计算摘要，如果两个摘要是 相同的，则表示报文是完整未经篡改的。

目录 IPSec VPN概述 IPSec VPN体系结构 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术 验证头（AH）技术 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术 IPSec VPN应用场景分析

IPSec安全协议-AH AH （Authentication Header）为IP数据包提供如下3种服务 数据完整性验证 数据源身份认证 通过哈希函数（如MD5）产生的校验来保证 数据源身份认证 通过在计算验证码时加入一个共享密钥来实现 防重放攻击 AH报头中的序列号可以防止重放攻击。

散列（HASH）函数介绍 主要应用方向：数据完整性校验和身份认证； 11011000110101010000111100000110101010001010000100111100010011000100000101001000101001001001001010001001010010010000101011010010100101000100 Hash运算 110000100100100100100100010 定长的输出 变长的输入 Hash运算 100010101010101010100011100101001001100100101001001001100100010111111010 1100001001001001001001000100 主要应用方向：数据完整性校验和身份认证； 主要特点：输入是变长的数据，输出是定长的数据HASH值；且必须是单向的，正向计算很容易，但求逆极其困难，难以实现； 常用的HASH函数：MD5、SHA—1，这两种HASH函数都没有密钥输入，其中MD5的输出为128位、SHA—1的输出为160位；

MD5函数 输入要发送的消息 得到128位的定长输出 HASH运算 (MD5) 共享密钥 将输出结果填入到AH头部的认证数据字段 IP头部 AH 负 载 填充 输入要发送的消息 HASH运算 (MD5) 得到128位的定长输出 共享密钥 输入共享密钥

IPSec安全协议-AH 提供数据源验证（真实性）、完整性校验和抗重放 不支持加密算法 下一个报文头 载荷长度 保留字段 安全参数索引（SPI） 序列号 IPSec协议组成——AH 验证头（Authentication Header, AH）是IPSec协议集合中的另外一个重要安全协议， 用于为IP提供数据完整保护、数据原始身份认证以及防重放服务。它定义在RFC2402中。 除了机密性之外，AH提供ESP能够提供的一切功能。 由于AH不提供机密性保证，所以它也不需要加密算法。AH定义保护方法、报头的位置 、身份验证的覆盖范围以及输出和输入处理规则，但没有对所用的身份验证算法进行定义 。与ESP一样，AH没有硬性规定防重放保护，是否使用防重放服务由接收端自行选择。 发送端无法得知接收端是否会检查其序列号，其结果是，发送端必须一直认定接收端正在 采用防重放服务。 和ESP一样，AH也是IP的一个万用型安全服务协议。但是AH提供的数据完整性与ESP 提供的数据完整性稍有不同； AH对外部IP头各部分也会进行身份验证。 AH分配到的协议号是51。也就是说，使用AH协议进行安全保护的IPv4数据报文的IP头 部中协议字段将是51，表明IP头之后是一个AH头。AH头比ESP头简单得多，因为它没有 提供机密性。由于不需要填充和一个填充长度指示器，因此也不存在尾部字段。另外，也 不需要一个初始化向量。 认证数据 载荷数据

AH头部格式 （1） 下一个头（Next Header）：8位 （2） 载荷长度（Payload Length）：8位 表示紧跟在AH头部的下一个载荷的类型，也就是紧跟在AH头部后面数据的协议类型。 在传输模式下，该字段是处于保护中的传输层协议的值，比如6（TCP）、17（UDP）或者50（ESP）； 在隧道模式下，AH所保护的是整个IP包，该值是4，表示IP-in-IP协议。 （2） 载荷长度（Payload Length）：8位 其值是以32位（4字节）为单位的整个AH数据 （3） 保留（reserved）：16位 作为保留用，实现中应全部设置为0。

AH头部格式 （4） SPI（Security Parameter Index，安全参数索引）：32位 与源/目的IP地址、IPSec协议一起组成的三元组可以为该IP包惟一地确定一个SA。 [1，255]保留为将来使用，0保留本地的特定实现使用。因此，可用的SPI值为[256，232- 1]。 （5） 序列号（Sequence Number）：32位 作为一个单调递增的计数器，为每个AH包赋予一个序号。当通信双方建立SA时，计数器初始化为0。SA是单向的，每发送一个包，外出SA的计数器增1；每接收一个包，进入SA的计数器增1。 该字段可以用于抵抗重放攻击。

AH头部格式 （6） 验证数据（Authentication Data） 可变长部分，包含了验证数据，也就是HMAC算法的结果，称为ICV（Integrity Check Value，完整性校验值）。 该字段必须为32位的整数倍，如果ICV不是32位的整数倍，必须进行填充，用于生成ICV的算法由SA指定。

AH报文封装模式 New IPH AH Data Org IPH IPH AH在IP报文头中的协议号为51 传输模式: 验证整个IP报文 隧道模式 IPH 传输模式 验证所有不变部分 验证除新IP头可变字段之外的所有不变部分 AH在IP报文头中的协议号为51 传输模式: 验证整个IP报文 隧道模式: 验证新IP头及整个IP报文 AH使用传输模式来保护一个上层协议，或者使用隧道模式来保护一个完整的IP数据报 。在任何一种模式下， AH头都会紧跟在一个IP头之后。AH可以单独使用， 也可以与 ESP联合使用，为数据提供最完整的安全保护。 AH用于传输模式时，保护的是端到端的通信。通信的终点必须是IPSec终点。AH头 被插在数据报中，紧跟在IP头之后（和任意选项），需要保护的上层协议之前。 AH用于隧道模式时，它将自己保护的数据报文封装起来，另外，在AH头之前，另添 了一个新的IP头。“里面的”IP数据报中包含了通信的原始报文，而新的IP头则包含了 IPSec端点的地址。隧道模式可用来替换端对端安全服务的传输模式。

AH运行模式(1)－传输模式 AH插入到IP头部（包括IP选项字段）之后，传输层协议（如TCP、UDP）或者其他IPSec协议之前。 验证区域 （可变字段除外） IP头部(含选项字段) AH头部 TCP头部(含选项字段) TCP头部(含选项字段) 数据 数据 图a 应用AH之前 图b 应用AH之后

AH运行模式(2)－隧道模式 在隧道模式中，AH插入到原始IP头部之前，然后在AH之前再增加一个新的IP头部。在隧道模式中，AH可以单独使用，也可以和ESP一起嵌套使用。 新IP头部(含选项字段) 验证区域 （可变字段除外） AH头部 IP头部(含选项字段) IP头部(含选项字段) TCP头部(含选项字段) TCP头部(含选项字段) 数据 数据 图a 应用AH之前 图b 应用AH之后

目录 IPSec VPN概述 IPSec VPN体系结构 验证头（AH）技术 Internet密钥交换（IKE）技术 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术 IPSec VPN应用场景分析

IPSec安全协议-ESP 提供数据真实性、数据完整性、抗重放、数据机密性 支持加密算法 载荷数据 序列号 安全参数索引（SPI） 填充长度 认证数据 下一个报头 填充字段 初始化向量 IPSec协议组成——ESP ESP使用一系列加密算法提供机密性，数据完整性则由认证算法保证。具体使用过程 中采用的算法则是由ESP安全联盟的相应组件决定的。另外ESP能够通过序列号提供防重 放服务，至于是否采用则由数据包的接收者来决定。这是因为一个唯一的、单向递增的序 列号是由发送端插入的，但却并不要求接收端对该数据报进行检验。由于这项保护对安全 性大有好处，所以一般都会采用。 ESP可在不同的操作模式下使用。不管ESP处于什么模式， ESP头都会紧紧跟在一个 IP头之后。在IPv4中，ESP头紧跟在IP头后面。ESP使用的协议号是50。也就是说，当 ESP头插入原始报文中后，ESP之前的IP头中的协议字段将是50，以表明IP头之后是一个 ESP头 作为一个IPSec头，ESP头中必然包含一个SPI字段。这个值，和IP头之前的目标地址 以及协议结合在一起，用来标识特定的安全联盟。SPI本身是个任意数，可以是使用者自 己指定，也可交由一些密钥管理技术自行协商决定。需要注意的是， SPI可以经过了验证 ，但却无法被加密。这是必不可少的一种做法，因为SPI用于SA的标识，指定了采用的加 密算法以及密钥，并用于对包进行解密。如果SPI本身已被加了密，我们会碰到一个非常 严重的问题——“先有鸡，还是先有蛋”。 序列号是一个独一无二、单向递增、并由发送端插在ESP头中的一个32位数值。通过 序列号，ESP具有了防重放的能力。与SPI一样，序列号经过了验证，但却没有加密。这 是由于我们希望在协议模块处理流程的最前端可以根据它判断一个包是否重复，然后决定 是否丢弃这个包，而不至于动用更多的资源对其进行解密。

ESP报头格式 （1） SPI：32位 （2） 序列号（Sequence Number）：32位 与目的IP地址、协议一起组成的三元组可以为该IP包唯一地确定一个SA。 （2） 序列号（Sequence Number）：32位 单调递增的计数器，为每个ESP包赋予一个序号。 通信双方建立SA时，计数器初始化为0。SA是单向的，每发送一个包，外出SA的计数器增1；每接收一个包，进入SA的计数器增1。 该字段可以用于抵抗重放攻击。

ESP报头格式 （3） 载荷数据（Payload Data）：变长 （4） 填充（Padding） 包含了实际的载荷数据。不管SA是否需要加密，该字段总是必需的。如果采用了加密，该部分就是加密后的密文；如果没有加密，该部分就是明文。 如果采用的加密算法需要一个IV（Initial Vector，初始向量），IV也是在本字段中传输的。该加密算法的规范必须能够指明IV的长度以及在本字段中的位置。对于强制实施的DES-CBC来说，IV是该字段当中第一个8位组。 本字段的长度必须是8位的整数倍。 （4） 填充（Padding） 填充字段包含了填充位。 （5） 填充长度（Pad Length）：8位 以字节为单位指示了填充字段的长度，其范围为[0，255]。

ESP报头格式 （6） 下一个头（Next Header）：8位 （7） 验证数据（Authentication Data）：变长 指明了封装在载荷中的数据类型，例如6表示TCP数据，4表示IP-in-IP。 （7） 验证数据（Authentication Data）：变长 只有选择了验证服务时才会有该字段，包含了验证的结果。

ESP报文封装模式 ESP在IP报头中的协议号为50 New IPH ESPH Data IPH Org IPH 传输模式 隧道模式 ESP Auth ESP Trailer 加密部分 验证部分 ESP在IP报头中的协议号为50 传输模式: ESP报头位于IP报头和传输层协议报头之间，在数据后面增加ESP尾 隧道模式: ESP报头位于新IP头和初始报文之间，在数据后面增加ESP尾。 具体应用中，ESP可以使用传输模式也可以使用隧道模式。不同的模式决定了ESP对 保护对象的定义。在传输模式中无法保护原有的IP头；在隧道模式中，整个原始报文都可 以受到保护。

ESP运行模式(1)－传输模式 加密不包括SPI和序号字段； 加密不包括验证数据； IP头部(含选项字段) ESP头部 验证区域 加密区域 TCP头部(含选项字段) IP头部(含选项字段) 数据 TCP头部(含选项字段) ESP尾部 数据 ESP验证数据 图a 应用ESP之前 图b 应用ESP之后 加密不包括SPI和序号字段； 加密不包括验证数据；

ESP运行模式(2)－隧道模式 保护的是整个IP包，对整个IP包进行加密； 在隧道模式中，ESP插入到原始IP头部之前，然后在ESP之前再增加一个新的IP头部。 新IP头部(含选项字段) ESP头部 验证区域 加密区域 IP头部(含选项字段) IP头部(含选项字段) TCP头部(含选项字段) TCP头部(含选项字段) 数据 数据 ESP尾部 ESP验证数据 图a 应用ESP之前 图b 应用ESP之后

ESP隧道模式与ESP传输模式的比较 ESP隧道模式的验证和加密能够提供比ESP传输模式更加强大的安全功能，因为隧道模式下对整个原始IP包进行验证和加密，可以提供数据流加密服务；而ESP在传输模式下不能提供流加密服务，因为源、目的IP地址不被加密。 不过，隧道模式将占用更多的带宽，因为增加了一个额外的IP头部。 尽管ESP隧道模式的验证功能不像AH传输模式或隧道模式那么强大，但ESP隧道模式提供的安全功能已经足够了。

目录 IPSec VPN概述 IPSec VPN体系结构 验证头（AH）技术 封装安全载荷（ESP）技术 IPSec VPN应用场景分析 Internet密钥交换（IKE）技术 IPSec VPN应用场景分析

IKE概述 Oakley Internet 密钥交换 （IKE） SKEME ISAKMP 基于DH算法的自由形态协议 … 定义了如何验证密钥交换 SKEME … 定义了沟通方式、信息格式 、 保障通信安全的状态变换过程 ISAKMP 用IPSec保护一个IP包之前，必须先建立一个安全联盟（SA）。IPSec的安全联盟可 以通过手工配置的方式建立。但是当网络中节点较多时，手工配置将非常困难，而且难以 保证安全性。这时就可以使用IKE（Internet Key Exchange）自动进行安全联盟建立与密 钥交换的过程。Internet密钥交换（IKE）就用于动态建立SA，代表IPSec对SA进行协商。 由RFC2409文件描述的IKE属于一种混合型协议。它建立在由Internet安全联盟和密钥 管理协议（ISAKMP）定义的一个框架上，详情可见RFC2408文件。同时，IKE还实现了 两种密钥管理协议的一部分——Oakley和SKEME。此外，IKE还定义了它自己的两种密钥 交换方式。 Oakley是由亚利桑那大学的安全专家Hilarie Orman开发的一种基于Diffie-Hellman（ 简称“DH”）算法的协议。它是一种自由形态的协议，允许各研究机构根据自身的水平改 进协议状态。IKE在其基础上定义了正规的密钥交换方法。尽管由于降低了Oakley模型的 灵活性，但仍然提供了多种交换模式供用户选择，所以最终还是成为一个非常适宜的密钥 交换技术。 SKEME则是另外一种密钥交换协议，由加密专家Hugo Krawczyk设计。SKEME定义 了如何验证密钥交换。其中，通信各方利用公共密钥加密实现相互间的验证，同时“共享 ”交换的组件。每一方都要用对方的公共密钥来加密一个随机数字，两个随机数（解密后 ）都会对最终的密钥产生影响。IKE在它的一种验证方法（公共密钥加密验证）中，直接 借用了SKEME的这种技术。 ISAKMP是由美国国家安全局（NSA）的研究人员开发出来的。NSA过去是一个高度 机密的组织，美国政府甚至还否认过它的存在。近年来， NSA已慢慢走到公众面前，其专

IKE的安全机制 DH算法、 密钥分发 身份保护 前向安全性 身份验证 加密的前提是交换加密数据的双方必须 要有共享的密钥。 Diffie-Hellman 算法 是一种公共密钥算法。通信双方在不传 送密钥的情况下通过交换一些数据，计 算出共享的密钥。 IKE的安全机制 DH算法、 密钥分发 身份保护 前向安全性 身份验证 IKE 的精髓就在于它永远不在不安全的网络上直接传送密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥。即使第三者（如黑客）截获了双方用于计算密钥的所有交换数据，也不足以计算出真正的密钥 IKE具有一套自保护机制，可以在不安全的网络上安全地分发密钥、验证身份、建立 IPSec 安全联盟。 DH（Diffie-Hellman）交换及密钥分发 Diffie-Hellman 算法是一种公共密钥算法。通信双方在不传送密钥的情况下通过交换 一些数据，计算出共享的密钥。加密的前提是交换加密数据的双方必须要有共享的密钥。 IKE 的精髓就在于它永远不在不安全的网络上直接传送密钥，而是通过一系列数据的交换 ，最终计算出双方共享的密钥。即使第三者（如黑客）截获了双方用于计算密钥的所有交 换数据，也不足以计算出真正的密钥。 完善的前向安全性（Perfect Forward Secrecy） PFS 是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密 钥间没有派生关系。PFS 是由DH 算法保障的。此特性是通过在IKE 阶段2的协商中增加 密钥交换来实现的。 身份验证 身份验证确认通信双方的身份。对于pre-shared key 验证方法，验证字用来作为一个 输入产生密钥，验证字不同是不可能在双方产生相同的密钥的。验证字是验证双方身份的 关键。 身份保护 身份数据在密钥产生之后加密传送，实现了对身份数据的保护。 IKE具有一套自保护机制，可以在不安全的网络上安全地分发密钥、验证身份、建立IPSec安全联盟。

DH算法 Host A Host B Internet 得出共享密钥Key= gab mod m 发送Y=gb mod m 发送X=ga mod m 做计算 X=ga mod m KB=Xb mod m=gab mod m 产生一个很大的数 a Host A Host B 事先双方协商两个公共数值， 非常大的素数m和整数g 两者相等 产生一个很大的数 b KA=Ya mod m=gab mod m 做计算 Y=gb mod m 得出共享密钥Key= gab mod m

IKE在IPSec协议的作用 降低手工配置的复杂度 安全联盟定时更新 密钥定时更新 允许IPSec提供反重放服务 允许在端与端之间动态认证 IKE协议中的DH交换过程，每次的计算和产生结果都是毫无关系的。为保证每个安全 联盟所使用的密钥互不相关，必须每次安全联盟的建立都运行DH交换过程。 IPSec使用IP报文头中的序列号实现防重放。此序列号是一个32比特的值，此数溢出 后，为实现防重放，安全联盟需要重新建立，这个过程与要IKE协议的配合。 对安全通信的各方身份的的验证和管理，将影响到IPSec的部署。IPSec的大规模使用 ，必须有CA-Certification Authority（认证中心）或其他集中管理身份数据的机构的参与。

安全联盟（Security Association） 定义： SA是通信对等体间对某些要素的约定 ,通信的双方符合SA约定的内容,就可以建立SA。 SA由三元组来唯一标识 ，包括： 安全参数索引 目的IP地址 安全协议号 安全联盟是IPSec的基础，也是IPSec的本质。SA是通信对等体间对某些要素的约定，例如，使用哪种安全协议、协议的操作模式（传输模式和隧道模式）、加密算法（DES和3DES）、特定流中保护数据的共享密钥以及密钥的生存周期等。 安全联盟是单向的，在两个对等体之间的双向通信，最少需要两个安全联盟来分别对两个方向的数据流进行安全保护。入站数据流和出站数据流分别由入站SA和出站SA进行处理。同时，如果希望同时使用AH和ESP来保护对等体间的数据流，则分别需要两个SA，一个用于AH，另一个用于ESP。 IPSec是在两个端点之间提供安全通信，端点被称为IPSec对等体。IPSec能够允许系 统、网络的用户或管理员控制对等体间安全服务的粒度。例如，某个组织的安全策略可能 规定来自特定子网的数据流应同时使用AH和ESP进行保护，并使用3DES（Triple Data Encryption Standard）进行加密；另一方面，策略可能规定来自另一个站点的数据流只使 用ESP保护，并仅使用DES加密。通过SA（SecurityAssociation），IPSec能够对不同的 数据流提供不同级别的安全保护。 安全联盟是IPSec的基础，也是IPSec的本质。SA是通信对等体间对某些要素的约定 ，例如，使用哪种安全协议、协议的操作模式（传输模式和隧道模式）、加密算法（DES 和3DES）、特定流中保护数据的共享密钥以及密钥的生存周期等。 安全联盟是单向的，在两个对等体之间的双向通信，最少需要两个安全联盟来分别对 两个方向的数据流进行安全保护。入站数据流和出站数据流分别由入站SA和出站SA进行 处理。同时，如果希望同时使用AH和ESP来保护对等体间的数据流，则分别需要两个SA ，一个用于AH，另一个用于ESP。 安全联盟由一个三元组来唯一标识，这个三元组包括安全参数索引（SPI, Security Parameter Index）、目的IP地址、安全协议号（AH 或ESP）。SPI 是为唯一标识SA而生 成的一个32 比特的数值，它在IPSec头中传输。 IPSec设备会把SA的相关参数放入SPD（Security Policy Database）里面，SPD里面 存放着“什么数据应该进行怎样的处理”这样的消息，在IPSec数据包出站和入站的时候 会首先从SPD数据库中查找相关信息并做下一步处理。

IKE的交换阶段 IKE IKE IKE使用了两个阶段为IPSec进行密钥协商并建立安全联盟： 第一阶段 TCP UDP key key IKE SA 协商 IKE IKE 第一阶段 TCP UDP key key TCP UDP 第二阶段 IPSec IPSec 加密的IP报文 IKE使用了两个阶段为IPSec进行密钥协商并建立安全联盟： 第一阶段，通信各方彼此间建立了一个已通过身份验证和安全保护的隧道，即 IKE SA。协商模式包括主模式、野蛮模式。认证方式包括预共享密钥、数字签名 方式、公钥加密。 第二阶段，用在第一阶段建立的安全隧道为IPSec协商安全服务，建立IPSec SA。 IPSec SA用于最终的IP数据安全传送。协商模式为快速模式。 IKE使用了两个阶段的ISAKMP。第一阶段建立IKE安全联盟（IKE SA），第二阶段利 用这个既定的安全联盟，为IPSec协商具体的安全联盟。 在RFC2409（The Internet Key Exchange）中规定，IKE 第一阶段的协商可以采用两 种模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。这两种模式各自做着 相同的事情：建立一个加密和验证无误的通信信道（IKE SA），以及生成验证过的密钥， 为双方的IKE通信提供机密性、消息完整性以及消息源验证服务。IKE中定义的其他所有交 换都要求一个验证过的IKE SA作为首要条件。所以无论主模式还是野蛮模式，第一阶段都 必须在其他任何交换之前完成。 IKE的工作流程如下： 当一个报文从某接口外出时，如果此接口应用了IPSec，会进行安全策略的匹配。 如果找到匹配的安全策略，会查找相应的安全联盟。如果安全联盟还没有建立，则触 发IKE进行协商。IKE首先建立第一阶段的安全联盟，即IKE SA。 在第一阶段安全联盟的保护下协商第二阶段的安全联盟，即IPSec SA。 使用IPSec SA保护通讯数据。

IKE交换的第一阶段—IKE SA IKE经过两个阶段为IPSec进行密钥协商并建立安全联盟： 第一阶段交换，通信各方彼此间建立了一个已通过身份验证和安全保护的通道，此阶段的交换建立了一个ISAKMP安全联盟，即ISAKMP SA（也可称为IKE SA）。 第二阶段交换，用已经建立的安全联盟（IKE SA）为IPSec协商安全服务，即为IPSec协商具体的安全联盟，建立IPSec SA，IPSec SA用于最终的IP数据安全传送

认证方法(pre-share/rsa-encr/ rsa-sig) IKE SA与IPSec SA ≠ IKE SA IPSec SA 认证方法(pre-share/rsa-encr/ rsa-sig) 安全协议(AH ESP AH+ESP) 认证算法（md5、sha1） 操作模式（传输模式和隧道模式） 加密算法（DES和3DES…） 加密算法（DES和3DES…） IKE SA 生命周期 共享密钥以及密钥的生存周期 从协商的内容上来看，由于IKE SA的主要作用是为IPSec SA协商出所使用的安全协 议，因此IKE SA的主要协商内容为AH或ESP协议所使用的认证算法和加密算法，以及 IPSec所使用的认证方法。 IPSec SA是要建立IPSec隧道的通信双方对隧道参数的约定，包括隧道两端的IP地址 ，隧道采用的验证方式、验证算法、验证密钥、加密算法、加密密钥、共享密钥以及生存 周期等一系列参数。 IKE经过两个阶段为IPSec进行密钥协商并建立安全联盟： 第一阶段交换，通信各方彼此间建立了一个已通过身份验证和安全保护的通道，此阶 段的交换建立了一个ISAKMP安全联盟，即ISAKMP SA（也可称为IKE SA）。 第二阶段交换，用已经建立的安全联盟（IKE SA）为IPSec协商安全服务，即为 IPSec协商具体的安全联盟，建立IPSec SA，IPSec SA用于最终的IP数据安全传送。 …… ……

IKE预共享密钥方式主模式交换过程 发起者 接受者 发起者cookie 模式协商 响应者cookie 各类算法确定 各类密钥生成 发起者cookie，SA载荷 响应者cookie 各类算法确定 响应者cookie，响应SA载荷 密钥交换载荷Xa 临时值载荷Ni Xa Ni DH交换 Nonce交换 密钥交换载荷Xb 临时值载荷Nr Xb Nr 各类密钥生成 密钥HASH 生成散列载荷 发送者标识载荷、散列载荷 身份验证 主模式被设计成将密钥交换信息与身份认证信息相分离的一种交换技术。这种分离保 证了身份信息在传输过程中的安全性，这是因为交换的身份信息受到了加密保护。 主模式总共需要经过三个步骤共6条消息来完成第一阶段的协商，最终建立IKE SA。 这三个步骤分别是模式协商、Diffie-Hellman交换和nonce交换、以及对对方身份的验 证。主模式的特点包括身份保护以及对ISAKMP协商能力的完全利用。其中，身份保护在 对方希望隐藏自己的身份时显得尤为重要。在我们讨论野蛮模式时，协商能力的完全利用 与否也会凸显出其重要性。若使用预共享密钥方法验证。 在消息1、2发送之前，协商发起者和响应者必须计算产生自己的cookie，用于唯一标 识每个单独的协商交换，cookie使用源/目的IP地址、随机数字、日期、和时间进行MD5运 算得出，并且放入消息1的ISAKMP中，用以标识单独的一个协商交换。 在第一次交换中，需要交换双方的cookie和SA载荷，在SA载荷中携带需要协商的IKE SA的各项参数，主要包括IKE的散列类型、加密算法、认证算法和IKE SA的协商时间限制 等。 第一次交换后第二次交换前，通信双方需要生成用于产生Diffie-Hellman共享密钥的 DH值。生成方法是双方各自生成一个随机数字，通过DH算法对随机数字进行运算，得出 一个DH值Xa和Xb（Xa是发起放的DH值，Xb是响应者的DH值），然后双方再根据DH算 法运算得出一个临时值Ni和Nr。 第二次交换中，双方交换各自的密钥交换载荷（即Diffie-Hellman交换）以及临时值载 荷（即nonce交换）。其中密钥交换载荷包含了Xa和Xb，临时值交换包含了Ni和Nr。 密钥HASH 生成散列载荷 响应者标识载荷、散列载荷 结束

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

第1、2条消息 消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命) 消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应。 注意：发起者会将它的所有策略发送给接受者,接受者则在自己 的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)

第1、2条消息 IPSec设备使用IKE提议来协商IKE参数，路由器A将自己的所有提议集发送到路由器B，路由器B将自己的提议分别和路由器A的提议集比较，直到发现匹配为止。路由器A的提议10 和路由器B的提议20匹配，如果没有发现匹配，会话将被拆除。

SKey_ID为主密钥，用来衍生其他三种密钥 第3、4条消息 SKey_ID为主密钥，用来衍生其他三种密钥 这2条消息,用于交换DH的公开信息和随机数 两个对等体根据DH的公开信息都算出了双方相等的共享密钥后,两个Nonce交换的值连同事先设置好的预共享密钥生成第一个Skey __ ID 随后便根据SKEY__ID来推算出其他几个skeyID skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的 skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥) skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密

第5、6条消息 第三次交换是对标识载荷和散列载荷进行交换。标识载荷包含了发起者的标识信息、IP地址或主机名，散列载荷包含上一过程中产生的三组密钥进行HASH运算得出的值。这两个载荷通过SKEYID_e进行加密，如果双方的载荷相同，那么认证成功。IKE第一阶段主模式预共享密钥交换也就完成了。

IKE野蛮模式 主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时，则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应地预共享密钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体。 但是当发起者的IP地址是动态分配获得的时候，由于发起者的IP地址不可能被响应者提前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对应地预共享密钥。野蛮模式就是被用于解决这个矛盾的。 IKE交换阶段第一阶段——野蛮模式交换 从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密 钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时， 则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应地预共享密 钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体。 但是当发起者的IP地址是动态分配获得的时候，由于发起者的IP地址不可能被响应者提 前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对 应地预共享密钥。野蛮模式就是被用于解决这个矛盾的。 与主模式不同，野蛮模式仅用3条信息便完成了IKE SA的建立。由于对消息数进行了限 制，野蛮模式同时也限制了它的协商能力，而且不会提供身份保护。 在野蛮模式的交换过程中，发起者会提供一个保护套件列表、Diffie-Hellman公共值、 nonce以及身份资料。所有这些信息都是随第一条信息进行交换的。作为响应者，则需要 回应选择一个保护套件、Diffie-Hellman公共值、nonce、身份资料以及一个验证载荷。发 起者将它的验证载荷在最后一条消息交换。 野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加 密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就 有了更多灵活的应用。

IKE野蛮模式预共享密钥协商过程 Peer 1 Peer 2 发 起 方 接 收 方 保护套件列表、DH公共值 Nonce、身份资料 同消息1、验证载荷 野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就有了更多灵活的应用 验证载荷 野蛮模式一共需要交换3个消息 消息1交换SA载荷、密钥材料、和身份信息 消息2在交换消息1内容的同时增加了Hash认证载荷 消息3是响应方对发起方的认证 IKE交换阶段第一阶段——野蛮模式交换 从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密 钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时， 则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应地预共享密 钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体。 但是当发起者的IP地址是动态分配获得的时候，由于发起者的IP地址不可能被响应者提 前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对 应地预共享密钥。野蛮模式就是被用于解决这个矛盾的。 与主模式不同，野蛮模式仅用3条信息便完成了IKE SA的建立。由于对消息数进行了限 制，野蛮模式同时也限制了它的协商能力，而且不会提供身份保护。 在野蛮模式的交换过程中，发起者会提供一个保护套件列表、Diffie-Hellman公共值、 nonce以及身份资料。所有这些信息都是随第一条信息进行交换的。作为响应者，则需要 回应选择一个保护套件、Diffie-Hellman公共值、nonce、身份资料以及一个验证载荷。发 起者将它的验证载荷在最后一条消息交换。 野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加 密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就 有了更多灵活的应用。 54

IKE主模式和野蛮模式区别 交换的消息: 身份保护： 对等体标识: 主模式为6个，野蛮模式为3个。 主模式的最后两条消息有加密，可以提供身份保护功能；而野蛮 模式消息集成度过高，因此无身份保护功能 对等体标识: 主模式只能采用IP地址方式标识对等体；而野蛮模式可以采用IP地 址方式或者Name方式标识对等体。

IKE交换的第二阶段（IPSec SA）—快速模式交换 建立好IKE SA之后（无论通过主模式还是通过野蛮模式交换），便可用它为IPSec生成相应的SA。IPSec SA是通过快速模式交换来建立的，对快速模式交换来说，它是在以前建立好的IKE SA的保护下完成的。

IKE交换的第二阶段（IPSec SA）—快速模式交换 来自IKE SA的SKEYID_a的值作为一个密钥，对快速模式交换的整个消息进行验证。这种验证除了能提供数据完整性保证之外，还能对数据源的身份进行验证： 通过加密（使用SKEYID_e），则可保障交换的机密性

IKE交换的第二阶段（IPSec SA）—快速模式交换 正常情况下IPSEC阶段使用的密钥都是由SkeyID_d衍生而来,密钥之间都有一定的关系,就算IPSEC SA超时,新的KEY还是和SkeyID_d有一定的关系 快速模式需要从SKEYID_d状态中衍生出用于IPSec SA的密钥。随同交换的nonce以及来自IPSec SA的SPI及协议一道，这个密钥将在伪随机函数中使用，这样便可确保每个SA都有自己独一无二的密钥：每个SA都有一个不同的SPI。 所有IPSec密钥都是自相同的来源衍生的，所以相互间都有关联。假如一名攻击者能够根据IKE SA判断出SKEYID_d的值，那么就能非常容易地掌握自那个SKEYID_d衍生出来的任何IPSec SA的任何密钥。另外，还能继续掌握未来将要衍生的所有密钥！

IKE交换的第二阶段（IPSec SA）—快速模式交换 快速模式为此专门提供了一个PFS选项，来满足这方面的需要，用户可根据自己地安全需要选择是否使用PFS（完美向前保密） 。 为了在快速模式交换中实现PFS，需要执行一次额外的Diffie-Hellman交换，最终生成的共享密钥将在为IPSec生成密钥的过程中用到。显然，一旦交换完成，这个密钥便不复存在。一旦完成，它所驻留的那个内存位置必须清零和释放。从而保证了密钥之间地不相关性。PFS启用后，数据加密部分使用的密钥就没有了衍生的过程 。

快速模式协商过程 发 起 方 接 收 方 用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到 SA载荷是用来协商各种保护算法的 Peer 1 Peer 2 发 起 方 接 收 方 SA载荷、Ni、Xa、发起者ID 用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到 响应SA载荷、 Nr、Xb、响应者ID SA载荷是用来协商各种保护算法的 确认信息 描述IPSEC SA是为哪些地址,协议和端口建立的 快速模式一共需要交换3个消息 消息1和消息2中，交换SA、KEY、Nonce和ID。用以协商算法、保证PFS 以及提供“在场证据” 消息3是用于验证响应者是否可以通信，相当于确认信息。 IKE交换阶段第二阶段——快速模式交换 建立好IKE SA之后（无论通过主模式还是通过野蛮模式交换），便可用它为IPSec生成 相应的SA。IPSec SA是通过快速模式交换来建立的，对快速模式交换来说，它是在以前 建立好的IKE SA的保护下完成的。 在一次快速交换模式中，通信双方需要协商拟定IPSec安全联盟的各项特征，并为其生 成密钥。IKE SA保护快速模式交换的方法是：对其进行加密，并对消息进行验证。消息的 验证是通过伪随机函数来进行的。来自IKE SA的SKEYID_a的值作为一个密钥，对快速模 式交换的整个消息进行验证。这种验证除了能提供数据完整性保证之外，还能对数据源的 身份进行验证：在消息接收到之后，我们知道它只有可能来自验证通过的实体，而且那条 消息在传送过程并未发生改变。而通过加密（使用SKEYID_e），则可保障交换的机密性 。 快速模式需要从SKEYID_d状态中衍生出用于IPSec SA的密钥。随同交换的nonce以及 来自IPSec SA的SPI及协议一道，这个密钥将在伪随机函数中使用，这样便可确保每个SA 都有自己独一无二的密钥：每个SA都有一个不同的SPI，所以入方向SA的密钥也会与出方 向SA不同。所有IPSec密钥都是自相同的来源衍生的，所以相互间都有关联。假如一名攻 击者能够根据IKE SA判断出SKEYID_d的值，那么就能非常容易地掌握自那个SKEYID_d 衍生出来的任何IPSec SA的任何密钥。另外，还能继续掌握未来将要衍生的所有密钥！这 显然是个大问题，所有这些密钥都不能保证所谓的“完美向前保密（PFS）”。快速模式 为此专门提供了一个PFS选项，来满足这方面的需要，用户可根据自己地安全需要选择是 否使用PFS。 Xa以及Xb将与IKE第一阶段生成的SKEYID_d、Ni、Nr以及SPI等信息共同生成最终用于IPSec加密的密钥

密钥保护 密钥生存周期 完美向前保密（PFS） Diffie-Hellman(DH)组 DH算法是一种公共密钥算法。IKE的精髓在于它永远不在不安全的网络上直接传送密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥。IKE共定义了5个DH组，组1定义的密钥长度为768位；组2长度为1024位。密钥长度越长，所生成的密钥安全度也就越高，越难被破译。DH组的选择很重要，因为DH组只在第一阶段的SA协商中确定，第二阶段的协商不再重新选择DH组，两个阶段使用的是同一个DH组，因此该DH组的选择将影响所有“会话密钥”的生成。在协商过程中，对等的实体间应选择同一个DH组，即密钥长度应该相等。若DH组不匹配，将视为协商失败。 密钥生存周期 密钥具有一定生存期，当生存期到达时，用新的密钥替代原有密钥； 完美向前保密（PFS） 定义两个密钥之间无任何关系 Diffie-Hellman(DH)组 公共密钥加密系统，可在一个公共的、不受安全保护通讯信道（Internet）交换共享密钥生成过程信息； 密钥生存周期 密钥生命周期设置决定何时把旧密钥替换成新密钥。密钥生命周期决定了在一定的时间 段内，新旧密钥交替的周期。例如，在某业务通信中需要1000秒，而我们设定密钥生命周 期为100秒，那么整个数据报文传输期间将会产生10个密钥。由于在此业务通信周期内使 用了10个密钥，即使攻击者破解了某个密钥对数据报文进行解密处理，也无法实现对所有 数据报文的解密。 完美向前保密（PFS） 完美向前保密，即每一密钥均是“独一无二”的，这样一个密钥被破解，并不影响其他 密钥的安全性，因为这些密钥间没有派生关系。所以若有攻击者破解了一个密钥后，只能 访问受这个密钥保护的所有数据报文，而受其它密钥保护的数据报文还是无法破解。 PFS 是由DH算法保障的。此特性是通过在IKE阶段2的协商中增加密钥交换来实现的。 Diffie-Hellman (DH) 组 DH算法是一种公共密钥算法。通信双方在不传送密钥的情况下通过交换一些数据，计 算出共享的密钥。加密的前提是交换加密数据的双方必须要有共享的密钥。IKE的精髓在 于它永远不在不安全的网络上直接传送密钥，而是通过一系列数据的交换，最终计算出双 方共享的密钥。即使第三方（如黑客）截获了双方用于计算密钥的所有交换数据，也不足 以计算出真正的密钥。IKE共定义了5个DH组，组1定义的密钥长度为768位；组2长度为 1024位。密钥长度越长，所生成的密钥安全度也就越高，越难被破译。DH组的选择很重 要，因为DH组只在第一阶段的SA协商中确定，第二阶段的协商不再重新选择DH组，两个 阶段使用的是同一个DH组，因此该DH组的选择将影响所有“会话密钥”的生成。在协商过 程中，对等的实体间应选择同一个DH组，即密钥长度应该相等。若DH组不匹配，将视为 协商失败。

IKE阶段2－IPSec SA 阶段2主要完成的功能：使用 IPSec 提议协商IPSec 参数

数据传输 一旦 IPSec 隧道建立成功，数据包和它的后续数据包在发送时，都会应用安全关联的参数。后续数据包是指和第一个数据包满足相同访问控制规则的数据包。IPSec 对等体间的流量将通过安全的通道交换。

隧道终止 若使用 IKE 建立安全关联策略，这些安全关联策略都有相应的生存周期（Lifetime），当指定的生存周期过期时，IPSec 的安全关联就超时了，此时密钥也会丢失。对于后来的数据，IKE 会执行一个新的阶段2 协商（即重新建立一个新的IPSec SA）。

IPSec流量处理 出站与入站 入站 总部 出站 丢弃报文（入站） 绕过安全服务 应用安全服务 分支机构 出站流量：防火墙首先查看出站数据报文流量是否属于定义的保护数据流，以判断将 为这个报文提供哪些安全服务输出，可能有以下几类情况： 绕过安全服务：在这类情况下，报文不属于定义的保护数据流，将不应用IPSec策略，只进行传统的IP转发处理流程； 应用安全服务：在这类情况下，此报文将根据已建立的SA，对报文应用IPSec策略后进行转发。对于尚未建立SA情况，将调用IKE，以便完成SA建立； 入站流量：入站流量处理与出站流量有所区别，其将根据报文是否含有IPSec头对此 报文进行以下动作处理。 丢弃报文：若报文不含IPSec头，且查看防火墙安全转发策略后，其策略输出为丢弃，那么数据报文就会被丢弃。若策略输出为应用IPSec，但SA未建立数据报文同样也会被丢弃 绕过安全服务: 若报文不含IPSec头，则根据防火墙安全转发策略将数据报文进行传统的IP转发处理流程； 应用安全服务：若报文含IPSec头，且已建立SA，那么数据报文将会被递交给IPSec层进行处理；

目录 IPSec VPN概述 IPSec VPN体系结构 验证头（AH）技术 封装安全载荷（ESP）技术 Internet密钥交换（IKE）技术 IPSec VPN应用场景分析

点对点IPSec应用场景 组网需求 USG A USG B Eth 0/0/0 202.38.160.1/16 202.38.169.1/16 Eth 0/0/1 192.168.0.1/24 192.168.1.1/24 PC1 192.168.0.2/24 PC2 192.168.1.2/24 组网需求 PC1与PC2之间进行安全通信，在FWA与FWB之间使用IKE自动协商建立安全通道。 在FWA和FWB上均配置序列号为10的IKE提议。 为使用pre-shared key验证方法的提议配置验证字。 FWA与FWB均为固定公网地址 两个网络的公网IP地址固定不变，且两个网络之间要互相访问，可建立IKE协商的点 到点方式的IPSec隧道，使两个网络中的设备都可以主动发起连接。 对于USG_A和USG_B，配置思路相同。如下： 完成接口基本配置、路由配置，并开启本地策略和转发策略。 配置IKE协商的第一阶段参数，包括IKE版本、协商模式、预共享密钥、对端IP地址等 。 在第一阶段基础上建立第二阶段。 配置IPSec安全策略，添加需保护的数据流，即网络A和网络B两个网段的通信数据。 将IPSec安全策略应用到接口上。

IPSec VPN配置关键步骤 定义保护的数据流 关联前三个步骤 应用到出接口 第一阶段 第二阶段 配置高级ACL 配置IKE 配置私网路由 配置IKE安全提议 配置IKE对等体

步骤一：定义需要保护的数据流 配置高级ACL，定义需要保护的数据流 [USG_A] acl 3000 [USG_A-acl-adv-3000] rule permit ip source 192.168.0.0 0.0.0.255 destination 192.168.1.0 0.0.0.255 [USG_B] acl 3000 [USG_B-acl-adv-3000] rule permit ip source 192.168.1.0 0.0.0.255 destination 192.168.0.0 0.0.0.255 为不同方向、不同应用的数据流提供IPSec保护，使用ACL定义需要保护的数据流。 数据流是一组流量（traffic）的集合，由源地址/掩码、目的地址/掩码、IP报文承载的协议 号、源端口号、目的端口号等来规定。一个数据流由一个ACL来定义，所有匹配一个访问 控制列表的流量，在逻辑上作为一个数据流。 IPSec使用高级ACL（Access Control List，访问控制列表）来定义需要保护的数据流 。高级ACL的取值范围是3000-3999，通过源IP地址、目的IP地址、ToS、时间段、协议 类型、优先级、ICMP报文类型和ICMP报文码等多个维度来对进行流量匹配，在大部分功 能中都可使用高级ACL来进行精确流量匹配。

步骤二：配置IKE 创建IKE安全提议 配置IKE对等体 [USG_A] ike proposal 10 [USG_A-ike-proposal-10] authentication-method pre-share [USG_A-ike-proposal-10] authentication-algorithm sha1 [USG_A-ike-proposal-10] integrity-algorithm hmac-sha1-96 配置IKE对等体 [USG_A] ike peer b [USG_A-ike-peer-b] ike-proposal 10 [USG_A-ike-peer-b] remote-address 202.38.169.1 [USG_A-ike-peer-b] pre-shared-key abcde 如果选择了pre-shared key验证方法，需要为每个对端配置预共享密钥。建立安全连 接的两个对端的预共享密钥必须一致。 在野蛮模式下可以配置对端IP地址与对端名称，主模式下只能配置对端IP地址。缺省 情况下，IKE协商采用主模式。

步骤三：IPSec安全提议配置 创建IPSec安全提议 USG_B上的IPSec安全提议配置与USG_A相同 [USG_A] ipsec proposal tran1 [USG_A-ipsec-proposal-tran1] encapsulation-mode tunnel [USG_A-ipsec-proposal-tran1] transform esp [USG_A-ipsec-proposal-tran1] esp authentication-algorithm md5 [USG_A-ipsec-proposal-tran1] esp encryption-algorithm des USG_B上的IPSec安全提议配置与USG_A相同 在配置IPSec安全提议时，可以只需要创建一个安全提议，其它参数采用缺省参数。 缺省情况下，安全协议使用esp，AH和ESP协议采用的验证算法为MD5，ESP协议采用的 加密算法为DES加密算法。

步骤四：配置IPSec安全策略 创建安全策略 [USG_A] ipsec policy map1 10 isakmp [USG_A-ipsec-policy-isakmp-map1-10] security acl 3000 [USG_A-ipsec-policy-isakmp-map1-10] proposal tran1 [USG_A-ipsec-policy-isakmp-map1-10] ike-peer b [USG_A-ipsec-policy-manual-map1-10] quit [USG_B] ipsec policy map1 10 isakmp [USG_B-ipsec-policy-isakmp-map1-10] security acl 3000 [USG_B-ipsec-policy-isakmp-map1-10] proposal tran1 [USG_B-ipsec-policy-isakmp-map1-10] ike-peer a [USG_B-ipsec-policy-isakmp-map1-10] quit

步骤五：应用IPSec安全策略 分别在USG_A和USG_B的外网出接口上引用各自的安全策略如下： [USG_A] interface Ethernet 0/0/0 [USG_A- Ethernet0/0/2] ipsec policy map1 [USG_B] interface Ethernet 0/0/0 [USG_B- Ethernet0/0/2] ipsec policy map1

配置IKE peer，在防火墙B上的配置应与防火墙A对应。 Web方式步骤一：配置IKE 配置IKE peer，在防火墙B上的配置应与防火墙A对应。 配置IKE 对等体远端地址。 配置IKE阶段1和阶段2。 选择“VPN > IPSec > IKE协商”。 单击“阶段1”。 在“新建阶段1”界面中，配置阶段1参数，如图所示。其中，“预共享密钥”设置为 abcde。 在第一阶段，通信各方彼此间建立了一个已通过身份验证和安全保护的通道，此阶段的交 换建立了一个ISAKMP安全联盟，即ISAKMP SA（也可称IKE SA）。在安全隧道的两 端设置的安全协议、认证算法、加密算法、预共享密钥、完整性算法、DH组等必须相 同，否则协商不能通过。 配置对端网关IP时，对端网关IP地址为对端网关建立隧道的接口的IP地址，即IPSec 策略应用到的接口的IP地址。

Web方式步骤二：配置IKE高级选项 在阶段一“高级”选项中，指定加密及认证算法 在阶段一中的加密算法、认证算法、完整性算法等参数的缺省配置为图中所示。

Web方式步骤三：IPSec安全提议配置 在“新建阶段2”界面中，配置阶段2参数 在Web界面下，IPSec安全提议的配置在IKE第二阶段中实现。 实质上，IKE阶段二的内容既为IPSec安全提议配置中所需要配置的内容。 在IKE第二阶段交换中，用已经建立的安全联盟（IKE SA）为IPSec协商安全服务， 即为IPSec协商具体的安全联盟，建立IPSec SA。IPSec SA用于最终的IP数据安全传送。 在第一阶段建立后，才能建立第二阶段，并对第一阶段进行引用。在安全隧道的两端设置 的安全协议、报文封装模式、认证算法、加密算法、PFS等必须相同，否则协商不能通过 。

在IPSec安全策略中定义保护的数据流。 Web方式步骤四：定义保护的数据流 在IPSec安全策略中定义保护的数据流。 应用IPSec策略。 选择“VPN > IPSec > IPSec策略”。 单击“新建”。 在“新建IPSec策略”界面中，配置IPSec策略参数 在命令行界面的配置中，首先使用ACL定义需要保护的数据流，然后再IPSec安全策 略中应用该ACL。但在Web界面的配置中，可以直接在新建IPSec策略时指定需要保护的 数据流。

Web方式步骤五：应用IPSec安全策略 选择“VPN > IPSec > IPSec策略”。 单击“policy1”后的“应用接口：- NONE - ”。 在下拉列表中选择GE0/0/2。 单击“应用”。

点对多点IPSec应用场景 一个总部到多个分支机构的组网，分支节点建立到总部的IPSec隧道。 PC 2 10.1.2.2/24 IPSec Tunnel 1 USG_B GE0/0/2 202.38.169.2/24 USG_A GE0/0/1 10.1.2.1/24 GE0/0/1 10.1.1.1/24 202.38.163.1/24 202.38.169.1/24 PC 3 10.1.3.2/24 PC 1 10.1.1.2/24 GE0/0/2 202.38.163.2/24 202.38.170.1/24 GE0/0/2 202.38.170.2/24 在实际的应用中，经常需要使用HUB-Spoke类型的组网，即一个总部到多个分支机构 的组网，分支节点建立到总部的IPSec隧道，各个分支机构之间的通信由总部节点转发和 控制。这样的应用场景，为点对多点的IPSec应用场景。 对于场景中的对于USG_A、USG_B和USG_C，配置思路相同。如下： 完成接口基本配置、路由配置，并开启本地策略和转发策略。 配置IKE协商的第一阶段参数，包括IKE版本、协商模式、预共享密钥、对端IP地址等 。 其中，USG_A不主动发起连接，不用指定对端网关IP地址。USG_B和USG_C需要指 定对端网关IP地址为202.38.163.2/24。 在第一阶段基础上建立第二阶段。 配置IPSec安全策略，添加需保护的数据流，即总部、分支机构1和分支机构2网段的 通信数据。 将IPSec安全策略应用到接口上。 点到点与点到多点应用场景的配置比较类似，各分支机构的配置大致相同，他们的对 端设备都应该为总部的USG防火墙。 GE0/0/1 10.1.3.1/24 IPSec Tunnel 2 USG_C

IPSec VPN配置向导(Web) 进入Web配置页面，选择菜单栏中 “快速接入向导—>IPSec向导”，选择相应应用场 景进行IPSec VPN配置； 1）选择应用场景； 2）配置网络：选择启用“IPSec应用”的网络口，且配置对端网关IP； 3）配置定义爱保护数据流； 4）配置加密与认证：一般情况下可采用默认配置，并保持两端配置统一；

IPSec结果验证与维护命令 查看到两条双向IPSec SA <FWA>display ipsec sa brief current ipsec sa number: 2 -------------------------------------------------------------------------------------------------------------- Src Address Dst Address SPI VPN Protocol Algorithm --------------------------------------------------------------------------------------------------------------- 202.38.160.1 202.38.169.1 957073432 0 ESP E:DES;A:HMAC-MD5-96; 202.38.169.1 202.38.160.1 2838744079 0 ESP E:DES;A:HMAC-MD5-96; PC1与PC2之间数据通信将触发IKE协商和IPSec VPN建立，成功建立VPN后，PC1与 PC2之间进行可以相互访问.

IPSec结果验证与维护命令 查看到IKE peer和IKE sa的信息 <sysname> display ike sa current ike sa number: 4 ---------------------------------------------------------------------------------- conn-id peer flag phase vpn 101 202.38.169.1 :2048 RD v2:2 public 100 202.38.169.1 :2048 RD v2:1 public 17 1.1.1.2 RD|ST v2:2 v12 7 1.1.1.2 RD|ST v2:1 v12 flag meaning RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT TD--DELETING NEG--NEGOTIATING D--DPD display ike sa命令可以查看到的信息包括：安全通道的标识符、安全联盟的对端IP 地址、VPN实例名称、SA所属阶段、SA所属解释域、此安全联盟的状态。 在参数中，Peer表示此安全联盟的对端的IP地址。Phase表示此SA所属阶段，具体说 明如下： Phase 1：建立安全通道进行通信的阶段，此阶段建立ISAKMP SA； Phase 2：协商安全服务的阶段，此阶段建立IPSec SA。 Flag显示此安全联盟的状态，其中： RD（READY）：表示此SA已建立成功； ST（STAYALIVE）：表示此端是通道协商发起方； RL（REPLACED）：表示此通道已经被新的通道代替，一段时间后将被删除； FD（FADING）：表示此通道已发生过一次软超时，目前还在使用，在硬超时时会删除 此通道； TO（TIMEOUT）：表示此SA在上次keepalive超时发生后还没有收到keepalive报文， 如果在下次keepalive超时发生时仍没有收到keepalive报文，此SA将被删除。 TD（DELETING）：表示该条SA即将被删除。 NEG（NEGOTIATING）：表示IKE SA正在协商中，是由隧道两端设置的某些参数不一致 导致。 D（DPD）：表示开启了DPD检测功能，并正在做DPD检测。

IPSec VPN配置注意事项 防火墙上必须有到达对方私网网段的正确路由 USG2100连接内网的接口需要取消接口快转功能 主动触发IPSec VPN的防火墙ACL中必须定义Source字段,推荐双方的ACL的互为镜像 IPSec 常见问题定位： IKE第一阶段没有成功。 使用display ike peer和display ike proposal检查隧道两端ike peer和ike proposal配置 是否一致。 IKE第二阶段没有成功。 一般问题都出在ACL上，确认被引用的ACL是否已经被匹配到。 服务器端模板方式下，客户端ACL必须指定源IP所在网段。 隧道中间是否存在NAT设备，是否配置了NAT穿越。 IPSec SA创建没有成功。 检查IPSec proposal配置是否一致。 IPSec SA已经建立但是业务不通。 配置Local和Untrust域间缺省包过滤规则的目的为允许IPSec隧道两端设备通信，使其能够协商SA

总结 IPSec技术的基本原理 AH和ESP技术 IKE协议的业务流程 IPSec VPN的应用场景及配置

思考题 IPSec VPN可提供哪些安全服务？每个安全服务的意义和实现方式是什么？ IPSec的2个主要安全协议是什么？它们之间有什么区别？ IKE可提供哪4个安全机制？每个安全机制的作用各是什么？ 安全联盟SA在IPSec中有何重要作用？它是通过哪三元组进行唯一标识？ IKE第一阶段协商有哪2种模式？它们之间主要应用在什么场景下？ IKE第一阶段协商2种模式的配置选项有什么不同？ IPSec是采用什么技术触发IPSec隧道的建立？ 在隧道模式下，如何配置私有网络路由？ IPSec应用场景下，域间包过滤如何设置才能符合最小权限要求？请从业 务流流向进行分析。