一、AH/ESP协议能否与NAT/PAT共存？

对于AH协议来说，无论是传输模式还是隧道模式，都会对包括IP头中源/目IP地址等字段在内的整个数据包进行哈希计算。对源/目IP地址或TCP/UDP端口号的任何修改都会破坏AH协议对数据包哈希计算的结果，导致数据包在接收端完整性校验失败，最终被丢弃。同时，AH协议的设计初衷是防止数据包在传输过程中被篡改/伪造，保证数据包的完整性，这与NAT/PAT需要修改数据包的源/目IP地址或TCP/UDP端口号的做法相违背，因此AH协议本质上就无法与NAT/PAT共存，如果IPSec对等体之间存在NAT/PAT设备，则必须用ESP代替AH协议。

注：AH协议只对数据包IP头中的源/目IP地址、协议号等固定字段进行哈希计算，而不会包括TTL/校验和这种传输过程中每跳都会变化的字段，在哈希计算和完整性校验时会将TTL/校验和字段的值视为零，保证TTL/校验和字段的改变不会破坏哈希计算结果导致完整性验证失败。

对于ESP协议来说，无论是传输模式还是隧道模式，都不会对数据包的IP头部进行哈希计算，并且哈希计算(完整性验证功能)是可选的，对数据包头中的源/目IP地址的改变不会导致数据接收端完整性校验失败。但ESP协议在面对NAT/PAT时仍然面临着两个问题：

1. 无论传输模式还是隧道模式，ESP协议报文没有TCP/UDP端口供PAT进行转换。

2. 传输模式下，NAT转换数据包头中的源/目IP地址后，无法更新TCP/UDP校验和导致数据接收端TCP/UDP校验失败。

为了解决IPSec在NAT/PAT环境下遇到的通信问题，使ESP协议报文能够穿越NAT/PAT设备，IETF提供了一种解决机制即NAT-T(Network Address Translation Traversal)，使ESP协议能够与NAT/PAT共存。NAT-T作为IPSec的一个扩展协议，发布在RFC3947/RFC3948中，它只适用于ESP协议，不支持AH协议。

二、NAT-T的工作原理

1. IKE阶段一中的NAT-T协商

通过主模式或积极模式的1/2包交互负载内容为字符串‘RFC 3947’的MD5散列值(4a131c81070358455c5728f20e95452f)的vendor ID，检测双方是否支持NAT-T功能。

如果双方支持NAT-T，则通过主模式的3/4包(积极模式的2/3包)交互NAT-D负载检测双方通信路径中是否存在NAT/PAT设备。双方各自会发送至少两个NAT-D负载，第一个NAT-D负载内容是对端IP地址和端口号的散列值；第二个NAT-D负载内容是本端IP地址和端口号的散列值。如果收到的第一个NAT-D与本端第二个NAT-D不匹配，则说明本端存在NAT/PAT设备；如果收到的第二个NAT-D与本端的第一个NAT-D不匹配，则说明对端存在NAT/PAT。