IPsec NAT穿越分析和总结.docx

IPsec NAT 穿越 2009-09-02 23:40:52 标签：ipsec 职场 休闲 nat-t 前言 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 通道进行通信。 IKE 协商使用 UDP 封装 RFC3947 主要描述如何检测是否存在 NAT 设备，并如何在IKE 中协商使用UDP 来封装IPSec 数据包。 检测 功能是检测通信中是否存在 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 字节,在后面介绍其值