IPsec是IP通信提供安全性的一系列协议和服务的集合，工作在IP层，可以为上层协议和应用提供透明的安全服务。

IPsec提供两种安全机制：认证和加密

认证机制: 通过对IP报文进行Hash(如MD5, SHA-1等)，接收方收到报文后，对报文进行同样的Hash算法得出同样的Hash值，从而确认报文未在中途发生篡改 (使用场景限于主机和主机之间，且中间没有NAT设备对报文IP进行转换，适用场景少，较少使用）。

加密机制：通过对数据进行加密运算(DES, 3DES, AES等加密算法)来保证数据的机密性，以防数据在传输过程中被窃听， 同时通过报文序列号方式确保报文不被重放，防止中间人攻击。

IPsec的两种安全机制工作协议：

# AH与ESP的封装区别

AH协议(Authentication Headers，认证头协议):

IP协议号为51，工作原理是在每一个数据包上添加一个身份验证报文头，此报文头插在标准IP包头后面，对数据提供完整性保护。可选择的认证算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）等。MD5算法的计算速度比SHA-1算法快，而SHA-1算法的安全强度比MD5算法高。

ESP协议(Encapsulated Security Payload，封装安全载荷）：

IP协议号为50，使用较广）提供加密、数据源认证、数据完整性校验和防报文重放功能。ESP的工作原理是在每一个数据包的标准IP包头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾。与AH协议不同的是，ESP将需要保护的用户数据进行加密后再封装到IP包中，以保证数据的机密性。常见的加密算法有DES、3DES、AES等。同时，作为可选项，用户可以选择MD5、SHA-1算法保证报文的完整性和真实性。这三个加密算法的安全性由高到低依次是：AES、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。对于普通的安全要求，DES算法就可以满足需要。

提供隧道和安全两种模式，满足不同的网络结构需求

隧道（tunnel）模式：

用户的整个IP数据包被用来计算AH或ESP头，AH或ESP头以及ESP加密的用户数据被封装在一个新的IP数据包中。通常，隧道模式应用在两个安全网关之间的通讯。

传输（transport）模式：

只是传输层数据被用来计算AH或ESP头，AH或ESP头以及ESP加密的用户数据被放置在原IP包头后面。通常，传输模式应用在两台主机之间的通讯，或一台主机和一个安全网关之间的通讯 。

IPsec中一些关键名词

SA (Security Association，安全联盟):

IPsec 对数据流提供的安全服务通过安全联盟SA 来实现，它包括协议、算法、密钥等内容，具体确定了如何对IP 报文进行处理。一个SA 就是两个IPsec 系统之间的一个单向逻辑连接，输入、输出数据流分别由输入SA(安全联盟)与输出SA(安全联盟)分别处理。安全联盟由一个三元组（SPI、IP 目的地址、安全协议号---AH或ESP）来唯一标识。安全联盟可通过手工配置和自动协商两种方式建立。

手工建立安全联盟的方式是指用户通过在两端手工设置一些参数，然后在接口上应用安全策略建立安全联盟。自动协商方式由IKE 生成和维护，通信双方基于各自的安全策略库经过匹配和协商，最终建立安全联盟而不需要用户的干预。

SPI (Security Parameters Index，安全索引)：

是一个32比特的数值，在每一个IPSec 报文中都携带该值。SPI、IP目的地址、安全协议号三者结合起来共同构成三元组，来唯一标识一个特定的安全联盟。在手工配置安全联盟时，需要手工指定SPI 的取值。为保证安全联盟的唯一性，每个安全联盟需要指定不同的SPI 值；使用IKE协商产生安全联盟时，SPI 将随机生成。

兴趣流：

在 IPsec 中，一组具有相同源地址/掩码、目的地址/掩码和上层协议的数据集称为数据流。通常，一个数据流采用一个访问控制列表（ACL）来定义，所有为ACL允许通过的报文在逻辑上作为一个数据流。为更容易理解，数据流可以比作是主机之间一个的TCP 连接。IPsec 能够对不同的数据流施加不同的安全保护，例如对不同的数据流使用不同的安全协议、算法或密钥。

IKE(Internet Key Exchange，因特网密钥交换协议):

用于动态建立SA，SA有生命周期，如果安全策略要求建立安全、保密的连接，但又不存在与该连接相应的SA，IPsec会立刻启动IKE来协商SA。

ISAKMP(Internet Security Association Key Management Protocol，安全联盟密钥管理协议):

定义了协商、建立、修改和删除SA的过程和包格式，只是提供了一个通用框架，并没有定义具体的SA格式，与IKE独立，可以被不同的密钥交换协议使用。IKE使用ISAKMP消息来协商并建立SA。

IPsec的秘钥协商过程

两个需要建立IPsec隧道实体之间的IKE协商分为两个阶段

Phase I (第一阶段)：建立ISAKMP SA

协商出一个ISAKMP SA对第二阶段的协商提供保护(UDP端口500)

两种模式协商（二选一）:

Ø 主模式(Main Mode): 6条ISAKMP消息交互Ø 积极模式(Aggressive Mode): 3条ISAKMP消息交互

报文内容

#报文格式

# 实际报文抓取

Cookie： 用于帮助通信双方确认一个ISAKMP报文是否真的来自对方，对于一个SA，cookie是唯一的，即在协商过程中，cookie不能改变。cookie由各自实体的机密信息生成，该机密信息不能通过cookie推到出来。交换类型：表示该报文所属的交换类型，通常为主模式或积极模式。标志 ：加密位（encryp）：如果是1，表示ISAKMP头部后的所有载荷都被加密了；如果是0，表示是载荷是明文，没有被加密。提交位（commit）：用于确保在发送被保护的数据之前完成协商。

Phase II (第二阶段): IPsec SA协商：

协商出一个通讯秘钥，对数据进行加密，提供数据安全保护。

仅有快速模式（Quick Mode）一种：3条ISAKMP消息交互

# 完整协商过程

组网验证：两个IPsec实体均有公网地址，路由可达：

期望在GW1与GW2两个网关(IPsec实体)之间建立IPsec隧道，GW1内网中的192.168.100.0/24子网与GW2内的192.168.66.0/24子网之间(兴趣流)通过IPsec隧道实现安全通讯。

# 无NAT组网

协商过程：

# 协商过程的报文交互

准备工作:

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

消息1 &2 (Proposal):

消息1： 发起方支持协商模式(Main或Aggressive), 所有支持的安全策略(5元组: 加密算法, 散列算法, DH, 认证方法, IKE SA寿命)

消息2：接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应

在1&2消息中报错可能出现的原因：

Ø peer路由不通Ø crypto iskmp key没有设置Ø 一阶段的策略不匹配

消息3 &4 (Key Exchange):

这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消息 (Identity Protection):

这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的

为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)

HASH认证成分: SKEYID_a, cookieA, cookieB，preshare_key, SA payload, 转换集，策略

消息6--接受者处理过程：

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

在5&6消息中报错可能出现的原因

crypto isakmp key设置错了

第二阶段(3条消息): 协商IPsec SA

phase 2的目标是协商IPsec SA,而且只有一种模式,快速模式,快速模式的协商是受IKE SA保护的(即内容被IKE SA秘钥加密)。

消息7&8：

消息7： 发送方发送一条报文,其中包含HASH,IPSEC策略提议,NONCE和可选的DH,身份IDHASH:是用于给接受方作完整性检查的, 用于再次认证对等体(必须), 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,这样,安全性就提高了（普通等IPSec SA过期或密钥超时时，重新生成的数据加密密钥还是根据以阶段DH出来的skeyID_d衍生出来的）（PFS启用后，数据加密部分使用的密钥就没有了衍生的过程） DH: 重新协商IPSEC SA实使用的密钥(正常情况下IPSEC阶段使用的密钥都是由skeyID_d衍生而来,密钥之间都有一定的关系,就算IPSEC SA超时,新的KEY还是和skeyID_d有一定的关系)

消息8: 使用相同的消息进行响应

在消息7&8过程中可能错的原因

Ø IPsec trasport不匹配Ø 感兴趣流不对称

消息9：

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

其中一方在NAT后面：

# 一方在NAT后面

期望在GW1与GW2两个网关(IPsec实体)之间建立IPsec隧道，GW1内网中的192.168.100.0/24子网与GW2内的192.168.66.0/24子网之间(兴趣流)通过IPsec隧道实现安全通讯。

其中GW2处于NAT后面，对于GW2来说GW1的地址可见，但是对于GW1来说，GW2的地址不可见，仅当GW2发起Proposal（消息1）时，GW1接收的Proposal发起地址为NAT地址（172.13.0.254经过转换后, Source IP变为10.10.11.248）。

注意： GW1显然不可能主动发现Proposal, 只能被动等待GW1的Proposal开始ISAKMP协商。

IPsec的NAT穿越(RFC 3947 Negotiation of NAT-Traversal in the IKE):

ISAKMAP消息1-4时，完成NAT穿越协商(报文的UDP端口为500), 在消息5-6以后，报文的UDP端口为4500.

与未经过NAT的组网相比，ESP加密内容增加了UDP头, 如下所示:

未经NAT的加密报文封装:

经过NAT的加密报文封装:

配置过程举例：

1. 配置阶段1所有IKE版本，共享密码，支持的算法，支持的DH组，秘钥生存时间，本地ID等

# ISAKMP参数配置（Phase I）

2. 配置阶段2兴趣流，支持加密方法， 支持DH组秘钥协商等.

# Phase II 兴趣流和加密参数

# Phase II 其它参数

3. IPsec对等体做同样的配置，若是作为远程拨号接入服务器（即该GW不知道出于NAT后的另一个对等体）则做如下配置： 在选定的接口下监听拨号用户接入。

# 远程拨号接入服务器

4. 设置IP策略（ACL规则）：两条规则，一条是从本地内网流出到对端内网的报文规则； 一条是从对端经过IPsec Tunnel接口流入到本地内网的规则

流出规则：

# Lan to Tunnel

流入规则：

# Tunnel to Lan

5. 设置路由策略：到对端的报文经过Tunnel接口转发，同时配置一条黑洞路由

# 路由策略配置

将对等体做同样的配置，即完成IPsec Tunnel的配置