天翼云研发告诉我：AH封装的IPsec不能穿越NAT设备

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

最近跟中国电信做VPN的研发交流了一下技术，发现技术爱好者跟研发之间的差距还是很明显的。

问题是我在配置天翼云的IPsec VPN连接时，发现IPsec策略的传输协议只有ESP协议可选，我就跑去问了研发为什么不支持AH。

研发的答复是AH不可以穿越NAT设备，并且不具备安全性，为了避免客户配置后业务异常，做了屏蔽处理。

我一想，这不对啊，AH（Authentication Header）可以提供数据来源认证、数据完整性校验和抗重放功能，可以保护报文免受篡改，但不能防止报文被窃听，适合用于传输非机密数据，这一点我是知道的。但AH协议不支持NAT穿越功能，这个我咋没有印象呢？

我还去华三官网搜了一下，确实有一句话，不过也只有一句话，提到了“AH协议不支持NAT穿越功能”。

好吧，可能一直没用过，导致这个点成了我的知识盲区。

今天来简单验证一下，AH到底能不能穿越NAT，实验拓扑如下：

实验环境为HCL V5.10.2版本，设备均使用MSR36-20，版本为Version 7.1.064, Release 0427P22。

配置上，RT2设备的GE0/1接口配置NAT，模拟RT1设备位于NAT设备之后，RT3设备具有公网IP地址的场景。

我们首先配置安全协议使用ESP协议，配置过程参考（NAT穿越场景下采用IKE野蛮模式建立保护IPv4报文的IPsec隧道），详细配置如下：

RT1

#
interface GigabitEthernet0/0
 ip address 10.12.1.1 255.255.255.0
 ipsec apply policy ahesp
#
interface GigabitEthernet0/1
 ip address 10.11.1.1 255.255.255.0
#
ip route-static 0.0.0.0 0 10.12.1.2
#
acl advanced 3000
 rule 0 permit ip source 10.11.1.0 0.0.0.255 destination 10.33.1.0 0.0.0.255
#
ipsec transform-set ahesp
 esp encryption-algorithm aes-cbc-128
 esp authentication-algorithm sha1
#
ipsec policy ahesp 10 isakmp
 transform-set ahesp
 security acl 3000
 remote-address 23.1.1.3
 ike-profile ahesp
#
ike profile ahesp
 keychain ahesp
 exchange-mode aggressive
 local-identity fqdn rt1
 match remote identity address 23.1.1.3 255.255.255.255
#
ike keychain ahesp
 pre-shared-key address 23.1.1.3 255.255.255.255 key simple ahesp

RT3

#
interface GigabitEthernet0/0
 ip address 23.1.1.3 255.255.255.0
 ipsec apply policy ahesp
#
interface GigabitEthernet0/1
 ip address 10.33.1.1 255.255.255.0
#
ip route-static 10.11.1.0 24 23.1.1.2
#
ipsec transform-set ahesp
 esp encryption-algorithm aes-cbc-128
 esp authentication-algorithm sha1
#
ipsec policy-template ahesp 1
 transform-set ahesp
 local-address 23.1.1.3
 ike-profile ahesp
#
ipsec policy ahesp 10 isakmp template ahesp
#
ike profile ahesp
 keychain ahesp
 exchange-mode aggressive
 match remote identity fqdn rt1
#
ike keychain ahesp
 pre-shared-key address 23.1.1.2 255.255.255.255 key simple ahesp

然后在PCA访问PCB触发建立IPsec VPN。

查看IKE SA和IPsec SA信息。

可以看到，IPsec安全提议中的安全协议为ESP-ENCRYPT-AES-CBC-128（ESP加密算法使用AES-CBC-128）和ESP-AUTH-SHA1（ESP认证算法使用SHA1），协商建立VPN隧道成功，通信正常。

抓包看一下。

可以看到，一阶段IKE协商使用野蛮模式的交互报文还是和主模式相同的，紧接着有一个NAT-keepalive报文，然后进入快速模式。之后的8个报文，就是封装之后的PCA探测PCB的报文了，报文是ESP封装过的，什么都看不到。

接下来，我们清空两端的SA信息，并将IPsec安全提议中的安全协议修改为AH。

ipsec transform-set ahesp
 protocol ah
 ah authentication-algorithm sha1

再去触发IPsec协商，发现业务报文就不通了。

查看两端设备的SA状态，发现还是正常协商起了IKE SA和IPsec SA，IPsec安全提议中的安全协议为AH-SHA1（AH认证算法使用SHA1），协商建立VPN隧道成功，只是无法正常通信。

抓包查看协商过程。

发现前面的协商报文还是一样的，只不过后面的业务报文就不通了。查看ESP报文，显示序列号错误。

然后在设备上debug看一下。

RT3接收到了RT1的报文，只不过SPI不匹配，然后被丢弃了。保温携带的SPI是67371008，而设备接受的SPI是2482589925。

再看发送端RT1这边。

发送端的状态都是正常的，调用的正确的SPI（2482589925），然后使用AH封装发送出去，结果经过NAT设备之后，一切都变了。

回顾一下正常的主模式下AH封装的IPsec业务报文（通过WireShark对比IPsec VPN不同配置方式和算法下的报文封装差异）。

可以看到正确的协议信息，因为没有加密，还可以看到内层的业务报文；当然，SPI也是正常的。

回顾一下，按照AH的RFC协议规定（AH：RFC2402-IP Authentication Header），SPI（Security Parameters Index，安全参数索引）是一个任意的 32 位值，结合目标IP地址和安全协议，唯一标识此数据报的安全联盟。一般来讲，SPI仅具有本地意义，由SA创建者（通常是携带SPI的数据包的接收者）定义；因此，SPI 通常被视为一个不透明的位串。

而AH对数据进行完整性检查时，会对包括源IP地址和目的IP地址在内的整个IP报文进行Hash运算。当NAT设备对IP报文进行源地址或目的地址的转换时，会改变IP地址，从而破坏AH的Hash值，导致在目的地接收到数据包后，由于AH验证失败而被丢弃。因此，AH协议不支持NAT穿越。

一般来讲，在实际部署中，如果要使用AH协议，通常会结合ESP协议使用，即AH-ESP，先使用ESP封装，再使用AH封装。