ipsec原理学习笔记(转载)

ipsec 简介

IPsec（Internet Protocol Security）是为IP网络提供安全性的协议和服务的集合，它是VPN（Virtual Private Network，虚拟专用网）中常用的一种技术。 由于IP报文本身没有集成任何安全特性，IP数据包在公用网络如Internet中传输可能会面临被伪造、窃取或篡改的风险。通信双方通过IPsec建立一条IPsec隧道，IP数据包通过IPsec隧道进行加密传输，有效保证了数据在不安全的网络环境如Internet中传输的安全性。 IPsec VPN是指采用IPsec实现远程接入的一种VPN技术，通过在公网上为两个或多个私有网络之间建立IPsec隧道，并通过加密和验证算法保证VPN连接的安全。

IPsec VPN保护的是点对点之间的通信，通过IPsec VPN可以在主机和主机之间、主机和网络安全网关之间或网络安全网关（如路由器、防火墙）之间建立安全的隧道连接。其协议主要工作在IP层，在IP层对数据包进行加密和验证。相对于其他VPN技术，IPsec VPN安全性更高，数据在IPsec隧道中都是加密传输，但相应的IPsec VPN在配置和组网部署上更复杂。

ipsec工作流程

IPsec的工作原理大致可以分为4个阶段：

• 识别“感兴趣流”。网络设备接收到报文后，通常会将报文的五元组等信息和IPsec策略进行匹配来判断报文是否要通过IPsec隧道传输，需要通过IPsec隧道传输的流量通常被称为“感兴趣流”。

• 协商安全联盟（Security Association，以下简称SA）。SA是通信双方对某些协商要素的约定，比如双方使用的安全协议、数据传输采用的封装模式、协议采用的加密和验证算法、用于数据传输的密钥等，通信双方之间只有建立了SA，才能进行安全的数据传输。 识别出感兴趣流后，本端网络设备会向对端网络设备发起SA协商。在这一阶段，通信双方之间通过IKE协议先协商建立IKE SA（用于身份验证和密钥信息交换），然后在IKE SA的基础上协商建立IPsec SA（用于数据安全传输）。

• 数据传输。IPsec SA建立成功后，双方就可以通过IPsec隧道传输数据了。 IPsec为了保证数据传输的安全性，在这一阶段需要通过AH或ESP协议对数据进行加密和验证。加密机制保证了数据的机密性，防止数据在传输过程中被窃取；验证机制保证了数据的真实可靠，防止数据在传输过程中被仿冒和篡改。

• 如图所示，IPsec发送方会使用加密算法和加密密钥对报文进行加密，即将原始数据“乔装打扮”封装起来。然后发送方和接收方分别通过相同的验证算法和验证密钥对加密后的报文进行处理得到完整性校验值ICV。如果两端计算的ICV相同则表示该报文在传输过程中没有被篡改，接收方对验证通过的报文进行解密处理；如果ICV不相同则直接丢弃报文。

• 隧道拆除。通常情况下，通信双方之间的会话老化（连接断开）即代表通信双方数据交换已经完成，因此为了节省系统资源，通信双方之间的隧道在空闲时间达到一定值后会自动删除。

ipsec的3个重要协议- IKE/AH/ESP

IKE（Internet Key Exchange，因特网密钥交换）

IKE协议是一种基于UDP的应用层协议，它主要用于SA协商和密钥管理。IKE协议分IKEv1和IKEv2两个版本，IKEv2与IKEv1相比，修复了多处公认的密码学方面的安全漏洞，提高了安全性能，同时简化了安全联盟的协商过程，提高了协商效率。IKE协议属于一种混合型协议，它综合了ISAKMP（Internet Security Association and Key Management Protocol）、Oakley协议和SKEME协议这三个协议。其中，ISAKMP定义了IKE SA的建立过程，Oakley和SKEME协议的核心是DH（Diffie-Hellman）算法，主要用于在Internet上安全地分发密钥、验证身份，以保证数据传输的安全性。IKE SA和IPSec SA需要的加密密钥和验证密钥都是通过DH算法生成的，它还支持密钥动态刷新。

AH（Authentication Header，认证头）

AH协议用来对IP报文进行数据源认证和完整性校验，即用来保证传输的IP报文的来源可信和数据不被篡改，但它并不提供加密功能。AH协议在每个数据包的标准IP报文头后面添加一个AH报文头，AH协议对报文的完整性校验的范围是整个IP报文。

ESP（Encapsulating Security Payload，封装安全载荷）

ESP协议除了对IP报文进行数据源认证和完整性校验以外，还能对数据进行加密。ESP协议在每一个数据包的标准IP报头后方添加一个ESP报文头，并在数据包后方追加一个ESP尾（ESP Trailer和ESP Auth data）。ESP协议在传输模式下的数据完整性校验范围不包括IP头，因此它不能保证IP报文头不被篡改。AH和ESP可以单独使用，也可以同时使用。AH和ESP同时使用时，报文会先进行ESP封装，再进行AH封装；IPsec解封装时，先进行AH解封装，再进行ESP解封装。

IPsec使用的端口

IPsec中IKE协议采用UDP 500端口发起和响应协商，因此为了使IKE协商报文顺利通过网关设备，通常要在网关设备上配置安全策略放开UDP 500端口。另外，在IPsec NAT穿越场景下，还需要放开UDP 4500端口。

而AH和ESP属于网络层协议，不涉及端口。为了使IPsec隧道能正常建立，通常还要在网关设备上配置安全策略放开AH（IP协议号是51）和ESP（IP协议号是50）服务。

IPsec VPN和SSL VPN对比

IPsec和SSL是部署VPN时最常用的两种技术，它们都有加密和验证机制保证用户远程接入的安全性。从以下几个方面对IPsec VPN和SSL VPN进行对比：

• OSI参考模型工作层级 OSI定义了网络互连的七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。IPsec工作在网络层，它直接运行在IP（Internet Protocol，互联网协议）之上。而SSL工作在应用层，是一种应用层协议，它加密的是HTTP流量，而不是直接加密IP数据包。

• 配置部署 IPsec VPN通常适用于Site to Site（站点到站点）的组网，要求站点分别部署VPN网关或远程用户安装专用的VPN客户端，因此配置部署复杂度和维护成本都比较高。但SSL VPN通常适用于Client to Site（客户端到站点）的组网，只要求远程用户使用支持SSL的标准浏览器安装指定插件即可进行访问，通过数据中心部署VPN网关进行集中管理和维护，因此配置部署更简单，维护成本相对较低。

• 安全性 IPSec工作在网络层，对站点间传输的所有数据进行保护。IPSec VPN要求远程用户安装专用的VPN客户端或在站点部署VPN网关设备，用户访问会受到客户端或网关在用户认证规则、安全策略规则或内容安全过滤方面的检查，因此安全性更高。而SSL VPN不要求安装专用客户端或接入站点部署网关设备，更容易受到安全威胁的影响。

• 访问控制 IPsec工作在网络层，不能基于应用进行细粒度的访问控制。而SSL VPN在精细化访问控制上更灵活，网络管理员可以将网络资源根据不同的应用类型划分为不同的资源类型，每一类资源的访问权限不同。

ipsec详解

加解密

一方传递消息之前，先使用加密算法和加密密钥，将消息改头换面，该过程称为加密；另一方收到消息后，使用相同的加密算法和加密密钥，逆向将消息恢复为真实面貌，该过程称为解密

两端使用相同的密钥来加密和解密，这种方式也叫对称加密算法，主要包括DES、3DES和AES

项目	DES	3DES	AES
全称	Data Encryption Standard	Triple Data Encryption Standard	Advanced Encryption Standard
密钥长度	56位	168位	128位、192位、256位
安全级别	低	中	高

数据签名

一方传递消息之前，先使用验证算法和验证密钥对消息进行处理，得到签名，然后将签名随消息一同发出去。另一方收到消息后，也使用相同的验证算法和验证密钥对消息进行处理，同样得到签名，然后比对两端的签名，如果相同则证明该消息没有被篡改。

除了对消息的完整性进行验证，IPSec还可以对消息的来源进行验证，即验明消息的正身，保证消息来自真实的发送者。通常情况下，验证和加密配合使用，加密后的报文经过验证算法处理生成签名。常用的验证算法有MD5和SHA系列。

项目	MD5	SHA1	SHA2
全称	Message Digest 5	Secure Hash Algorithm 1	Secure Hash Algorithm 2
签名长度	128位	160位	SHA2-256:256位; SHA2-384:384位; SHA2-512:512位
安全级别	低	中	高

AH只能用来验证，没有加密的功能，而ESP同时具有加密和验证的功能，AH和ESP可以单独使用也可以配合使用

安全封装

IPSec设计了两种封装模式:

• 隧道模式 在隧道模式下，AH头或ESP头到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，隧道模式使用新的报文头来封装消息，可以保护一个网络的消息，适用于两个网关之间通信，是比较常用的封装模式

• 传输模式 在传输模式中，AH头或ESP头会插入到IP头与传输层协议头之间，传输模式不改变报文头，隧道的源和目的地址就是最终通信双方的源和目的地址，通信双方只能保护自己发出的消息，不能保护一个网络的消息。所以该模式只适用于两台主机之间通信，不适用于内部私网之间通信。

互信盟友

IPSec中通信双方建立的连接叫做安全联盟SA（Security Association），顾名思义，通信双方结成盟友，使用相同的封装模式、加密算法、加密密钥、验证算法、验证密钥，相互信任亲密无间。安全联盟是单向的逻辑连接，为了使每个方向都得到保护，ipsec两端的每个方向上都要建立安全联盟。一端接入方向上的安全联盟对应另一端发出方向上的安全联盟，一端发出方向上的安全联盟对应另一端接入方向上的安全联盟。

为了区分这些不同方向的安全联盟，IPSec为每一个安全联盟都打上了唯一的标识符，这个标识符叫做SPI（Security Parameter Index）， 建立安全联盟最直接的方式就是分别在两端人为设定好封装模式、加密算法、加密密钥、验证算法、验证密钥，即手工方式建立IPSec安全联盟。

ipsec的手工配置

IPSec为手工方式定义了四个步骤

• 定义需要保护的数据流 只有内部网络之间交互的消息才被IPSec保护，其他消息不受保护

• 配置IPSec安全提议 两端根据对方的提议，决定能否成为盟友。封装模式、ESP、加密算法和验证算法均在安全提议中设置

• 配置手工方式的IPSec安全策略 指定两端的公网地址、安全联盟标识符SPI，以及加密密钥和验证密钥

• 应用IPSec安全策略

IKE自动协商

IKE综合了三大协议：ISAKMP（Internet Security Association and Key Management Protocol）、Oakley协议和SKEME协议。ISAKMP主要定义了IKE伙伴（IKE Peer）之间合作关系（IKE SA，跟IPSec SA类似）的建立过程。Oakley协议和SKEME协议的核心是DH（Diffie-Hellman）算法，主要用于在Internet上安全地分发密钥、验证身份，以保证数据传输的安全性。

ISAKMP

为建立IPSec SA而进行的IKE协商工作是由ISAKMP报文来完成的

ISAKMP报文封装如下

IP报文头

• 源地址src：本端发起IKE协商的IP地址，可能是接口IP地址，也可能是通过命令配置的IP地址
• 目的地址dst：对端发起IKE协商的IP地址，由命令配置

UDP报文头

IKE协议使用端口号500发起协商、响应协商。在总舵和分舵都有固定IP地址时，这个端口在协商过程中保持不变

ISAKMP报文头

• Initiator’s Cookie（SPI）和responder’s Cookie（SPI）：在IKEv1版本中为Cookie，在IKEv2版本中Cookie为IKE的SPI，唯一标识一个IKE SA
• Version：IKE版本号
• Exchange Type：IKE定义的交互类型，交换类型定义了ISAKMP消息遵循的交换顺序
• Next Payload：标识消息中下一个载荷的类型。一个ISAKMP报文中可能装载多个载荷，该字段提供载荷之间的“链接”能力。若当前载荷是消息中最后一个载荷，则该字段为0
• Type Payload：载荷类型，ISAKMP报文携带的用于协商IKE SA和IPSec SA的“参数包”。载荷类型有很多种，不同载荷携带的“参数包”不同

IKEv1

IKE诞生以来，有过一次大的改进。老的IKE被称为IKEv1，改进后的IKE被称为IKEv2，IKEv1版本中可以在交换类型字段查看协商模式，阶段1分为两种模式：主模式和野蛮模式，阶段2采用快速模式。主模式是主流技术，野蛮模式是为解决现实问题而产生的，IKEv2版本中定义了查看创建IKE SA和CHILD SA（对应IKEv1的IPSec SA）的IKE_SA_INIT、IKE_AUTH（创建第一对CHILD SA）、CREATE_CHILD_SA（创建后续的CHILD SA）

相比手工方式，IKE方式仅增加了两步：配置IKE安全提议和IKE对等体。IKE安全提议主要用于配置建立IKE SA用到的加密和验证算法。IKE对等体主要配置IKE版本、身份认证和交换模式

IKEv1版本分两个阶段来完成动态建立IPSec SA的任务：

• 阶段1-建立IKE SA：阶段1采用主模式或野蛮模式协商。
• 阶段2-建立IPSec SA：阶段2采用快速模式协商。

阶段1-建立IKE SA（主模式）

主模式下IKEv1采用3个步骤6条ISAKMP消息建立IKE SA。下面以网关A主动发起IKE协商为例进行讲解

1. 协商IKE安全提议 协商分两种情况：

• 发起方的IKE Peer中引用了IKE Proposal
• 发起方的IKE peer中没有引用IKE Proposal

二种情况下响应方都会在自己配置的IKE安全提议中寻找与发送方相匹配的IKE安全提议，如果没有匹配的安全提议则协商失败。IKE Peer双方安全提议匹配的原则为协商双方有相同的加密算法、认证算法、身份认证方法和DH组标识（不包括IKE SA生存周期）。 说明：通过IKEv1协议协商建立IPSec安全联盟时，采用本地生存周期和对端生存周期中较小的一个，不必保证隧道两端设备配置的生存周期相同（sa duration）。

1. 使用DH算法交换密钥材料，并生成密钥 网关A和B利用ISAKMP消息的Key Exchange和nonce载荷交换彼此的密钥材料。Key Exchange用于交换DH公开值，nonce用于传送临时随机数。由于DH算法中IKE Peer双方只交换密钥材料，并不交换真正的共享密钥，所以即使黑客窃取了DH值和临时值也无法计算出共享密钥，这一点正是DH算法的精髓所在。

密钥材料交换完成后，IKE Peer双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程（预共享密钥或数字证书都会参与到密钥计算过程中），最终会产生三个密钥：

• SKEYID_a：ISAKMP消息完整性验证密钥――谁也别想篡改ISAKMP消息了，只要消息稍有改动，响应端完整性检查就会发现！
• SKEYID_e：ISAKMP消息加密密钥――再也别想窃取ISAKMP消息了，窃取了也看不懂！

以上两个密钥保证了后续交换的ISAKMP消息的安全性！

• SKEYID_d：用于衍生出IPSec报文加密和验证密钥――最终是由这个密钥保证IPSec封装的数据报文的安全性！

整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新，避免了密钥长期不变带来的安全隐患。

1. 身份认证

IKE Peer通过两条ISAKMP消息（5、6）交换身份信息，进行身份认证。目前有两种身份认证技术比较常用:

• 预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称
• 数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（俗称签名）

以上身份信息都由SKEYID_e进行加密，所以在抓包中我们只能看到标识为“Encrypted”的ISAKMP消息，看不到消息的内容（身份信息）

预共享密钥是最简单、最常用的身份认证方法。这种方式下设备的身份信息可以用IP地址或名称（包括FQDN和USER-FQDN两种形式）来标识。当IKE Peer两端都有固定IP地址的时候，一般都用IP地址作为身份标识；当一端为动态获取IP地址的时候，没有固定IP地址的一端只能用名称来标识。

在IKE Peer两端都有固定IP地址的场景下，remote-address命令配置的IP地址要跟对端发起IKE协商的IP地址保持一致即可。这个IP地址的作用不仅仅是指定了隧道对端的IP地址，还参与了预共享密钥的查找, 对端发来的身份信息后，需要用密钥（SKEYID_a和SKEYID_e）进行完整性验证和解密，只有先找到正确的预共享密钥才能计算出这两个密钥。但网关为每个IKE Peer都配置了一个预共享密钥。怎么找呢？此时只能根据IKE Peer发来的ISAKMP报文的源IP地址（src）来查找预共享密钥，只要报文源地址与本端IKE Peer视图下remote-address命令配置的IP地址一致，就认为该配置的pre-shared-key是对端的预共享密钥

阶段2-建立IPSec SA

在阶段2中IKEv1采用快速交换模式通过3条ISAKMP消息建立IPSec SA。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID_e对ISAKMP消息进行加密，所以我们抓到的报文都是加密的，看不到载荷里面的具体内容。故下面只能文字介绍一下每一步的作用。 下面以网关A发起IPSec协商为例进行讲解。

1. 发起方发送IPSec安全提议、被保护的数据流（ACL）和密钥材料给响应方。
2. 响应方回应匹配的IPSec安全提议、被保护的数据流，同时双方生成用于IPSec SA的密钥。 IPSec对等体两端协商IPSec安全提议的过程跟协商IKE安全提议的过程类似，不再赘述。 IKEv1不协商ACL规则，建议两端设备配置的ACL规则互为镜像，避免IPSec SA协商失败。 IPSec对等体两端交换密钥材料（SKEYID_d、SPI和协议1、nonce等参数），然后各自进行密钥计算生成用于IPSec SA加密验证的密钥，这样可以保证每个IPSec SA都有自己独一无二的密钥。由于IPSec SA的密钥都是由SKEYID_d衍生的，一旦SKEYID_d泄露将可能导致IPSec VPN受到侵犯。为提升密钥管理的安全性，IKE提供了PFS（完美向前保密）功能。启用PFS后，在进行IPSec SA协商时会进行一次附加的DH交换，重新生成新的IPSec SA密钥，提高了IPSec SA的安全性。 说明：1、协议指AH和/或ESP协议。
3. 发起方发送确认结果。 协商完成后发送方开始发送IPSec（ESP）报文。

IPSec SA是单向的（区分源和目的），两个方向的IPSec SA共同组成一条IPSec隧道。 说明：一般来说一条数据流对应一个IPSec SA。但当IPSec同时采用了ESP+AH封装时，一条数据流会对应两个IPSec SA。

野蛮模式

配置命令exchange-mode aggressive即可将IKEv1的协商模式改为野蛮模式。抓包看一下野蛮模式的情况

野蛮模式只用了3条ISAKMP消息就完成了阶段1的协商过程，阶段2仍旧是快速模式不变。

发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方，IKE协商效率提高了。但由于身份信息是明文传输，没有加密和完整性验证过程，IKE SA的安全性降低了。既然这样不够安全，为什么野蛮模式还会出现？ 在IPSec VPN出现的早期，由于主模式+预共享密钥身份认证方式下，IPSec需要通过对端的IP地址来在本地查找预共享密钥（主模式中已经详细解释了这个问题）。这种密钥查找方式在对端没有固定IP地址的情况下（比如IPSec NAT穿越场景，网络出口动态获取IP地址场景）行不通。此时，野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密，IPSec就直接用对端发送来的身份信息来查找预共享密钥即可。所以在IPSec VPN应用初期，野蛮模式主要用于解决没有固定IP地址的节点部署IPSec VPN的问题。现在，IPSec VPN解决这个问题有很多方法，不安全的野蛮模式已经不是最好的选择了

IKEv2

IKEv1似乎已经很完美了，但用得久了仍旧会发现不尽人意之处。

协商建立IPSec SA的时间太长

• IKEv1主模式协商一对IPSec SA，需要6（协商IKE SA）+3（协商IPSec SA）=9条消息。

• IKEv1野蛮模式协商一对IPSec SA，需要3（协商IKE SA）+3（协商IPSec SA）=6条消息。

• 不支持远程用户接入 IKEv1不能对远程用户进行认证。若想支持远程用户接入，只能借助L2TP，通过PPP来对远程用户进行AAA认证。 这些问题怎么解决呢？办法总比问题多！IKEv2中完美的解决了这些问题。

IKEv2相比IKEv1：

• 协商建立IPSec SA的速度大大提升 正常情况IKEv2协商一对IPSec SA只需要2（协商IKE SA）+2（协商IPSec SA）=4条消息。后续每建立一对IPSec SA只会增加2条消息。

• 增加了EAP（Extensible Authentication Protocol）方式的身份认证。 IKEv2通过EAP协议解决了远程接入用户认证的问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。今天强叔只介绍IKEv2的基本协商过程，EAP认证留待后续再讲。

IKEv2的配置思路与IKEv1完全相同，只是细节稍有不同：

说明：红色命令与IKEv1不同。缺省情况下，防火墙同时开启IKEv1和IKEv2协议。本端发起协商时，采用IKEv2，接受协商时，同时支持IKEv1和IKEv2。可以不关闭IKEv1

IKEv2协商IPSec SA的过程跟IKEv1有很大差别：

1. 初始交换4条消息同时搞定IKE SA和IPSec SA。 初始交换包括IKE安全联盟初始交换（IKE_SA_INIT交换）和IKE认证交换（IKE_AUTH交换）

第一个消息对（IKE_SA_INIT）：负责IKE安全联盟参数的协商，包括IKE Proposal，临时随机数（nonce）和DH值。 SA载荷主要用来协商IKE Proposal. KE（Key Exchange）载荷和Nonce载荷主要用来交换密钥材料. IKEv2通过IKE_SA_INIT交换后最终也生成三类密钥： SK_e：用于加密第二个消息对。 SK_a：用于第二个消息对的完整性验证。 SK_d：用于为Child SA（IPSec SA）衍生出加密材料

第二个消息对（IKE_AUTH）：负责身份认证，并创建第一个Child SA（一对IPSec SA）。 目前三种身份认证技术比较常用：

• 预共享密钥方式（pre-share）：设备的身份信息为IP地址或名称。
• 数字证书方式：设备的身份信息为证书和通过证书私钥加密的部分消息Hash值（签名）。
• EAP方式：采用EAP认证的交换过程属于扩展交换的内容，将在后面讲解。

以上身份信息都通过SKEYID_e加密。 创建Child SA时，当然也要协商IPSec安全提议、被保护的数据流。IKEv2通过TS载荷（TSi和TSr）来协商两端设备的ACL规则，最终结果是取双方ACL规则的交集（这点跟IKEv1不同，IKEv1没有TS载荷不协商ACL规则）。 当一个IKE SA需要创建多对IPSec SA时，例如两个IPSec对等体之间有多条数据流的时候，需要使用创建子SA交换来协商后续的IPSec SA。

1. 子SA交换2条消息建立一对IPSec SA。

子SA交换必须在IKE初始交换完成之后才能进行，交换的发起者可以是IKE初始交换的发起者，也可以是IKE初始交换的响应者。这2条消息由IKE初始交换协商的密钥进行保护。 IKEv2也支持PFS功能，创建子SA交换阶段可以重新进行一次DH交换，生成新的IPSec SA密钥。

ikev1与ikev2对比： |功能|IKEv1|IKEv2| |—|—|—| |IPSec SA建立过程|分两个阶段，阶段1分两种模式：主模式和野蛮模式，阶段2为快速模式。- 主模式+快速模式需要9条信息建立IPSec SA。- 野蛮模式+快速模式需要6条信息建立IPSec SA。|不分阶段，最少4条消息即可建立IPSec SA。| |ISAKMP|二者支持的载荷类型不同|| |认证方法|预共享密钥,数字证书,数字信封（较少使用）|预共享密钥,数字证书,EAP,数字信封（较少使用）| |IKE SA完整性算法|不支持|支持| |PFS|支持|支持| |远程接入|通过L2TP over IPSec来实现|支持|

显然IKEv2以其更加快捷、更加安全的服务胜出，长江后浪推前浪又成为了没有任何悬念的事实。

IPSec协议框架总结

• 安全协议（AH和ESP）――IP报文的安全封装。穿上AH或/和ESP马甲的IP报文称为IPSec报文。此“马甲”并非一般的马甲，是交织了“加密”和“验证”算法的刀枪不入的“软猬甲”。说明：AH封装的验证范围实际要还更大一些，包括新的IP头.

• 加密算法（DES、3DES、AES）――IPSec报文的易容之术。IPSec数据报文采用对称加密算法进行加密，但只有ESP协议支持加密，AH协议不支持。另外，IKE协商报文也会进行加密。

• 验证（MD5、SHA1、SHA2）――IPSec报文的验明正身之法。加密后的报文经过验证算法处理生成数字签名，数字签名填写在AH和ESP报文头的完整性校验值ICV字段发送给对端；在接收设备中，通过比较数字签名进行数据完整性和真实性验证。

• IKE――手握密钥管理大权的贴心管家。IPSec使用IKE协议在发送、接收设备之间安全地协商密钥、更新密钥。

• DH算法――贴心管家的铁算盘。DH被称为公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息进行交换，并最终在收发两端计算出加密密钥和验证密钥。

---

参考文献

什么是IPsec？

【防火墙技术连载25】强叔侃墙 VPN篇 Internet危机四伏，IPSec闪亮登场

【防火墙技术连载26】强叔侃墙 VPN篇 IPSec携手IKE，珠联璧合显神威