IPSec的NAT穿越

参考资料：RFC3715，3947，3948

1. 前言

IPSec提供了端到端的IP通信的安全性，但在NAT环境下对IPSec的支持有限，AH协议是肯定不能进行NAT的了，这和AH设计的理念是相违背的；ESP协议在NAT环境下最多只能有一个VPN主机能建立VPN通道，无法实现多台机器同时在NAT环境下进行ESP通信。关于IPSec在NAT环境下的需求问题在RFC3715中进行了描述。

NAT穿越(NAT Traversal，NAT-T)就是为解决这个问题而提出的，在RFC3947，3948中定义，在RFC4306中也加入了NAT-T的说明，但并没废除RFC3947，3948，只是不区分阶段1和阶段2。该方法将ESP协议包封装到UDP包中（在原ESP协议的IP包头外添加新的IP头和UDP头），使之可以在NAT环境下使用的一种方法，这样在NAT的内部网中可以有多个IPSec主机建立VPN通道进行通信。

2. IKE协商使用UDP封装

RFC3947主要描述如何检测是否存在NAT设备，并如何在IKE中协商使用UDP来封装IPSec数据包。

2.1 检测

功能是检测通信中是否存在NAT设备和对方是否支持NAT-T。

正常的IKE协商使用的UDP包的源和目的端口都是500，如果存在NAT设备，大多数情况下该UDP包的源端口部分会改变，只有少数情况不改。接收方如果发现UDP源端口不是500，那可以确定数据是经过了NAT设备。另外，确定NAT的位置也是重要的，在检测对方失效（DPD）时，应该尽量由在NAT设备后面的一方主动进行DPD探测，而从另一方探测有可能会失败。

检测对方是否支持NAT-T是通过交换vendor ID载荷来实现的，如果自身支持NAT-T，在IKE开始交互就要发送这种载荷，载荷内容是“RFC 3947”的MD5值，也就是十六进制的“4a131c81070358455c5728f20e95452f”。

判断是否在NAT设备后面是通过发送NAT-D(NAT-Discovery)载荷来实现的，载荷内容是IP地址和UDP端口的HASH值，NAT-D载荷格式如下，载荷类型值是20：
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED     | Payload length           |
+---------------+---------------+---------------+---------------+
~           HASH of the address and port             ~
+---------------+---------------+---------------+---------------+

HASH值的计算方法如下，具体HASH是根据协商来确定的：
    HASH = HASH(CKY-I | CKY-R | IP | Port)
CKY-I和CKY-R是协商发起方和响应方的cookie。

协商中双方各自至少要发送两个NAT-D载荷，第一个载荷是对方的地址和端口的HASH，后面的载荷是自己的地址和端口，如果本地有多个地址，则要发送多个载荷，包括所有地址和端口的HASH，对方接收到载荷后重新根据收到的包的实际地址端口来计算HASH值后进行比较，就可以知道是否有NAT设备以及哪一方在NAT设备之后了。

有些的NAT设备具有端口固定的功能，也就是进行NAT转换后只改变地址而不改变端口，而且针对IKE通信使用cookie来区分内部各个IPSec设备的IKE连接，后续IKE协商如果继续用500端口协商就会出现问题。对于这类设备，解决方法是改变IKE协商端口从500到4500，因为这些设备只对500端口进行特殊处理而不对4500端口处理。在协商时，发现了自己在NAT设备之后的一方立即要将协商端口从500该为4500，源和目的端口都是4500，此时协商数据包格式为：
  IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
其中“non-ESP marker”为4字节,在后面介绍其值。

接收方接收此包解密并认证通过后，要改变自己的状态将原来处理500端口状态改为处理4500端口，后续的协商过程都使用