通过WireShark对比IPsec VPN不同配置方式和算法下的报文封装差异

正文共：1888 字 18 图，预估阅读时间：2 分钟

听说大家最近学习WireShark抓包的热情比较高涨**（** WireShark抓包报文结构分析、 听说你要WireShark抓包的分析案例？DHCP来了！），那我就多发几篇，反正库存多的是。

前面我们提到SD-WAN的时候**（** SD-WAN网络中的IPsec流量是怎么转发的？我给你简单演示一下），提到过目前SD-WAN的Overlay隧道实现方式主要还是通过IPsec来建立。那了解IPsec的相关协议**（** RFC2401-互联网协议的安全架构）、配置过程**（** GRE over IPsec，IPsec不服，要求IPsec over GRE）还有报文结构就变得非常重要，整体上已经出了一个合集了**（** IPsec VPN文章及知识点汇总【墙裂建议收藏】）。当然，后来文章又有更新，具体请参考**（** IPsec文章合集）。

结合RFC2401（ IPsec：互联网协议的安全架构）、RFC2402（ AH：IP认证头）、RFC2406（ ESP：IP封装安全载荷**）**的相关说明：

**IPsec SA（Security Association，安全联盟）**分为两种类型：传输模式和隧道模式。

传输模式 SA 是两个主机之间的安全联盟。在 ESP 的情况下，传输模式 SA 仅为这些更高层协议提供安全服务，而不是为 IP 标头或 ESP 标头之前的任何扩展标头提供安全服务。在 AH 的情况下，保护还扩展到 IP 标头的选定部分、扩展标头的选定部分和选定的选项。

隧道模式SA本质上是应用于IP隧道的SA。每当SA的任一端是安全网关时，SA 必须是隧道模式。因此，两个安全网关之间的 SA 始终是隧道模式 SA，主机和安全网关之间的 SA 也是如此。

对于隧道模式 SA，有一个"外部"IP 标头指定 IPsec 处理目的地，加上一个"内部"IP 标头，指定数据包的（表面）最终目的地。安全协议头出现在外部 IP 头之后，内部 IP 头之前。如果在隧道模式下使用 AH，则外部 IP 报头的部分将受到保护（如上所述），以及所有隧道传输的 IP 数据包（即，所有内部 IP 报文头都受到保护，以及更高层协议）。如果采用 ESP，则仅对隧道数据包提供保护，而不对外部报文头提供保护。

总之，主机必须同时支持传输和隧道模式；要求安全网关仅支持隧道模式，如果安全网关支持传输模式，则应仅在安全网关充当主机时使用。

组网图

实验组网图如下。

设备配置

IPsec这个实验我是在H3C模拟器HCL中做的，主要配置任务包括以下几点：

1、配置IPsec保护的数据流量。一般也称为感兴趣流，用ACL来进行匹配；

2、配置IPsec安全提议。指定对IP报文的封装形式为传输模式或隧道模式，选择安全协议为AH或ESP或AH-ESP，并配置与之对应的加密算法及认证算法；

3、配置IPsec安全策略。包含配置应用感兴趣流，应用IPsec安全提议，指定IPsec隧道地址，配置安全协议的SPI（Security Parameter Index，安全参数索引） 和**SA（Security Association，安全联盟）**密钥；

4、在接口上应用IPsec安全策略。

所以，今天，我们将主要通过调整安全协议、加密算法和认证算法来验证一下。

IPsec安全提议支持的安全协议有AH、ESP和AH-ESP，相关协议介绍请参照相关RFC文档，不同安全协议的数据封装格式如下图所示：

模拟器支持的安全协议：

缺省情况下，采用ESP安全协议，那就延用上个实验的环境，先测一下ESP安全协议。

使用ESP安全协议的报文结构

已知使用ESP封装的报文，MTU值为1400字节。从RFC2406我们得知，ESP封装报文头格式如下：

虽然抓包的可读性比较差，但还是要做一下分析。

将标准的封装格式和实际报文进行对比，可以得出：

1、SPI字段长度为4字节；

2、序列号字段长度为4字节；

3、加密填充内容字段长度可变，长度为0-255字节；

4、填充长度字段长度为1字节；

5、下一个头部字段长度为1字节；

6、认证数据字段长度可变，并且是可选的。

所以上面1和2为ESP头，3-6位ESP-T（校验尾），初步推算ESP-T长度为44字节。

所以使用ESP封装的完整报文结构如下图所示：

使用AH安全协议的报文结构

修改安全协议在IPsec的安全提议transform-set中，重新配置安全协议为AH。并在IPsec策略中修改SA的SPI和密钥。

sql 复制代码

#
ipsec transform-set tran1
 protocol ah
 ah authentication-algorithm sha1
#
ipsec policy ipsec 10 manual
 sa spi inbound ah 123321
 sa string-key inbound ah simple 123321
 sa spi outbound ah 123321
 sa string-key outbound ah simple 123321

查看SA信息，发现协议已经是AH了，并且没有加密算法。

测试封装后的MTU为1428字节。

抓包进行分析，发现仅仅是在原始报文头部加了一个认证头，没有对报文进行加密，原始报文数据一目了然。

对比RFC2402中的报文结构，AH头部封装和协议中完全一致。RFC2402中AH ICV字段为可变长度，此处该字段长度为12字节。

所以使用ESP封装的完整报文结构如下图所示：

组合使用AH-ESP安全协议的报文结构

再从IPsec的安全提议transform-set中，配置安全协议为AH-ESP。并在IPsec策略中添加SA的SPI和密钥。需要注意，AH和ESP的SPI值不能重复，否则无法配置。

sql 复制代码

#
ipsec transform-set tran1
 esp encryption-algorithm aes-cbc-128
 esp authentication-algorithm sha1
#
ipsec policy ipsec 10 manual
 sa spi inbound ah 123321
 sa spi inbound esp 321123
 sa string-key inbound ah simple 123321
 sa string-key inbound esp simple 123321
 sa spi outbound ah 123321
 sa spi outbound esp 321123
 sa string-key outbound ah simple 123321
 sa string-key outbound esp simple 123321

查看SA信息，能发现SA中同时包含AH和ESP，加密算法和认证算法均有体现。

测得封装后的链路MTU为1376字节。

抓包进行分析，发现报文封装结构和之前学习的一样，先封装ESP，再加一个AH认证头。

所以组合使用AH和ESP封装的完整报文结构如下图所示：

修改ESP加密算法

验证完了安全协议，那加密算法会不会对报文封装有影响呢？

这个验证还是比较简单的，仅需要在IPsec安全提议transform-set中修改加密算法即可，此处将原来的aes-cbc-128算法修改为aes-ctr-256。

properties 复制代码

#
ipsec transform-set tran1
 protocol ah-esp
 esp encryption-algorithm aes-ctr-256
 esp authentication-algorithm sha1
 ah authentication-algorithm sha1

修改之后查看SA信息，验证加密算法修改成功。