2. Known Incompatibilities between NA(P)T and IPsec (NA(P)T 与 IPsec 之间的已知不兼容性)

NA(P)T 与 IPsec 之间的不兼容性可以分为三类:

固有的 NA(P)T 问题。这些不兼容性直接源于 [RFC3022] 中描述的 NA(P)T 功能。因此, 这些不兼容性将存在于任何 NA(P)T 设备中。
NA(P)T 实现缺陷。这些不兼容性不是 NA(P)T 固有的, 但存在于许多 NA(P)T 实现中。此类别包括处理入站或出站分片的问题。由于这些问题不是 NA(P)T 固有的, 原则上可以在未来的 NA(P)T 实现中解决。然而, 由于实现问题似乎很普遍, 它们需要在 NA(P)T 穿越解决方案中加以考虑。
辅助功能问题。这些不兼容性存在于试图提供 IPsec NA(P)T 穿越的 NA(P)T 设备中。具有讽刺意味的是, 这种 "辅助" 功能造成了进一步的不兼容性, 使本已困难的问题更难解决。虽然 IPsec 穿越 "辅助" 功能并非存在于所有 NA(P)T 中, 但这些特性正变得足够流行, 因此也需要在 NA(P)T 穿越解决方案中加以考虑。

2.1. Intrinsic NA(P)T Issues (固有的 NA(P)T 问题)

NA(P)T 固有的不兼容性包括:

a) IPsec AH [RFC2402] 与 NAT 之间的不兼容性。由于 AH 头部在密钥消息完整性检查中包含了 IP 源地址和目的地址, NAT 或反向 NAT 设备对地址字段的更改将使消息完整性检查失效。由于 IPsec ESP [RFC2406] 在其密钥消息完整性检查中不包含 IP 源地址和目的地址, 因此 ESP 不会出现此问题。

b) 校验和与 NAT 之间的不兼容性。TCP 和 UDP 校验和通过在计算中包含 "伪头部" 而依赖于 IP 源地址和目的地址。因此, 当校验和被计算并在接收时检查时, 它们将因通过 NAT 或反向 NAT 设备而失效。

因此, IPsec 封装安全负载 (Encapsulating Security Payload, ESP) 只有在不涉及 TCP/UDP 协议 (如在 IPsec 隧道模式或 IPsec 保护的 GRE 中) 或不计算校验和 (如 IPv4 UDP 可能的情况) 时才能不受阻碍地通过 NAT。如 [RFC793] 中所述, IPv4 中需要 TCP 校验和计算和验证。IPv6 中需要 UDP/TCP 校验和计算和验证。

流控制传输协议 (Stream Control Transmission Protocol, SCTP), 如 [RFC2960] 和 [RFC3309] 中定义, 使用仅在 SCTP 数据包 (公共头部 + 块) 上计算的 CRC32C 算法, 因此不覆盖 IP 头部。因此, NAT 不会使 SCTP CRC 失效, 问题不会出现。

请注意, 由于传输模式 IPsec 流量使用强密码学进行完整性保护和身份验证, 因此可以在检查 UDP/TCP 校验和之前检测到数据包的修改。因此, 校验和验证仅提供针对内部处理中错误的保证。

c) IKE 地址标识符与 NAT 之间的不兼容性。当 IP 地址在互联网密钥交换协议 (Internet Key Exchange Protocol, IKE) 阶段 1 [RFC2409] 或阶段 2 中用作标识符时, NAT 或反向 NAT 对 IP 源地址或目的地址的修改将导致标识符与 IP 头部中的地址不匹配。如 [RFC2409] 中所述, IKE 实现需要丢弃此类数据包。

为了避免使用 IP 地址作为 IKE 阶段 1 和阶段 2 标识符, 可以使用 userID 和 FQDN 代替。当需要用户身份验证时, 可以使用 ID_USER_FQDN 的 ID 类型, 如 [RFC2407] 中所述。当需要机器身份验证时, 可以使用 ID_FQDN 的 ID 类型。在任何一种情况下, 如果在阶段 1 中交换证书, 则需要验证所提议的标识符作为处理最终实体证书的结果被认证。虽然在 IKE 中可以使用 USER_FQDN 或 FQDN 身份类型, 但存在无法以这种方式容纳的使用场景 (例如描述子网的安全策略数据库 (Security Policy Database, SPD) 条目)。

由于阶段 2 标识符中的源地址通常用于形成完整的 5 元组入站 SA 选择器, 因此可以在选择器中使用目的地址、协议、源端口和目的端口, 以免削弱入站 SA 处理。

d) 固定 IKE 源端口与 NAPT 之间的不兼容性。当 NAPT 后面的多个主机向同一响应方发起 IKE SA 时, 需要一种机制允许 NAPT 对来自响应方的传入 IKE 数据包进行解复用。这通常通过转换来自发起方的出站数据包上的 IKE UDP 源端口来实现。因此, 响应方必须能够接受来自 500 以外的 UDP 源端口的 IKE 流量, 并且必须回复该端口。在重新密钥期间必须小心避免不可预测的行为。如果浮动源端口不用作重新密钥的目的端口, NAT 可能无法将重新密钥数据包发送到正确的目的地。

e) 重叠 SPD 条目与 NAT 之间的不兼容性。当 NAT 后面的发起主机在阶段 2 标识符中使用其源 IP 地址时, 它们可以与同一响应方 IP 地址协商重叠的 SPD 条目。然后, 响应方可能会将数据包发送到错误的 IPsec SA。发生这种情况是因为对于响应方而言, IPsec SA 似乎是等效的, 因为它们存在于相同的端点之间, 并且可以用于传递相同的流量。

f) IPsec SPI 选择与 NAT 之间的不兼容性。由于 IPsec ESP 流量是加密的, 因此对 NAT 不透明, NAT 必须使用 IP 和 IPsec 头部的元素来解复用传入的 IPsec 流量。目的 IP 地址、安全协议 (AH/ESP) 和 IPsec SPI 的组合通常用于此目的。

然而, 由于出站和入站 SPI 是独立选择的, NAT 无法仅通过检查出站流量来确定哪个入站 SPI 对应于哪个目的主机。因此, 如果 NAT 后面的两个主机同时尝试在同一目的地创建 IPsec SA, NAT 可能会将传入的 IPsec 数据包传递到错误的目的地。

请注意, 这不是与 IPsec 本身的不兼容性, 而是与通常实现它的方式的不兼容性。对于 AH 和 ESP, 接收主机指定用于给定 SA 的 SPI, 这一选择仅对接收方有意义。目前, 目的 IP、SPI 和安全协议 (AH、ESP) 的组合唯一标识一个安全关联 (Security Association)。此外, 1-255 范围内的 SPI 值保留给 IANA, 将来可能会使用。这意味着, 当与同一外部主机或网关协商时, 同一 NAPT 后面的内部主机可以选择相同的 SPI 值, 使得一个主机的入站 SA 是 (SPI=470, Internal Dest IP=192.168.0.4) 而另一个主机的入站 SA 是 (SPI=470, Internal Dest IP=192.168.0.5)。接收 NAPT 将无法确定具有 SPI=470 的入站 IPsec 数据包应该转发到哪个内部主机。

接收主机也可能为每个单播安全关联分配唯一的 SPI。在这种情况下, 目的 IP 地址只需检查它是否是 "此主机的任何有效单播 IP", 而不是检查它是否是发送主机使用的特定目的 IP 地址。使用这种技术, 即使两个或多个主机与同一外部主机建立 SA, NA(P)T 也可以确保将数据包转发到错误内部主机的几率很低但不为零。

这种方法完全向后兼容, 仅需要特定的接收主机对其 SPI 分配和 IPsec_esp_input() 代码进行更改。然而, NA(P)T 设备可能无法在没有与解析 IKE 负载相关的问题的情况下检测到此行为。并且主机可能仍然需要使用 IANA 保留范围内的 SPI 用于指定的目的。

g) 嵌入 IP 地址与 NAT 之间的不兼容性。由于负载受到完整性保护, IPsec 数据包内包含的任何 IP 地址都无法被 NAT 转换。这使得在 NAT 中实现的应用层网关 (Application Layer Gateway, ALG) 无效。使用嵌入 IP 地址的协议包括 FTP、IRC、SNMP、LDAP、H.323、SIP、SCTP (可选) 和许多游戏。要解决此问题, 需要在主机或安全网关上安装 ALG, 这些 ALG 可以在 IPsec 封装之前和 IPsec 解封装之后对应用程序流量进行操作。

h) NA(P)T 的隐式方向性。NA(P)T 通常需要初始出站数据包流经它们, 以便创建入站映射状态。方向性禁止主动建立到 NA(P)T 后面主机的 IPsec SA。

i) 入站 SA 选择器验证。假设 IKE 协商阶段 2 选择器, 入站 SA 处理将丢弃解封装的数据包, 因为 [RFC2401] 要求数据包的源地址与 SA 选择器值匹配, 而 NA(P)T 对 ESP 数据包的处理会改变这一点。

2.2. NA(P)T Implementation Weaknesses (NA(P)T 实现缺陷)

许多 NA(P)T 中存在的实现问题包括:

j) 无法处理非 UDP/TCP 流量。一些 NA(P)Ts 丢弃非 UDP/TCP 流量, 或者当 NAT 后面只有一个主机时仅执行地址转换。此类 NAPT 无法启用 SCTP、ESP (协议 50) 或 AH (协议 51) 流量。

k) NAT 映射超时。NA(P)T 在没有流量的情况下维护 UDP 映射的时间各不相同。因此, 即使 IKE 数据包可以正确转换, 转换状态也可能被过早删除。

l) 无法处理出站分片。在 IP 数据包大小超过出站接口上的 MTU 的情况下, 大多数 NA(P)T 可以正确分片出站 IP 数据包。然而, 正确转换已经分片的出站数据包是困难的, 大多数 NAPT 无法正确处理这一点。如 [RFC3022] 第 6.3 节所述, 当两个主机向同一目的地发送分片数据包时, 分片标识符可能重叠。由于目的主机依赖分片标识符和分片偏移进行重组, 结果将是数据损坏。很少有 NA(P)T 通过支持标识符转换来防止标识符冲突。当 NAT 执行分片时, 标识符冲突不是问题, 因为分片标识符只需在源/目的 IP 地址对内唯一即可。

由于分片可以小到 68 个八位字节 [RFC791], 因此无法保证第一个分片将包含完整的 TCP 头部。因此, 寻求重新计算 TCP 校验和的 NA(P)T 可能需要修改后续分片。由于分片可以重新排序, 并且 IP 地址可以嵌入并可能在分片之间分割, NA(P)T 将需要在完成转换之前执行重组。很少有 NA(P)T 支持这一点。

m) 无法处理入站分片。由于通常只有第一个分片将包含完整的 IP/UDP/SCTP/TCP 头部, NAPT 需要能够仅基于源/目的 IP 地址和分片标识符执行转换。由于分片可以重新排序, 如果后续分片在初始分片之前到达, 则可能不知道给定分片标识符的头部, 并且头部可能在分片之间分割。因此, NAPT 可能需要在完成转换之前执行重组。很少有 NAPT 支持这一点。请注意, 对于 NAT, 源/目的 IP 地址足以确定转换, 因此不会出现这种情况。然而, IPsec 或 IKE 头部可能在分片之间分割, 因此仍可能需要重组。

2.3. Helper Incompatibilities (辅助功能不兼容性)

IPsec 与 NAT "辅助" 功能之间的不兼容性包括:

n) 互联网安全关联和密钥管理协议 (Internet Security Association and Key Management Protocol, ISAKMP) 头部检查。今天, 一些 NAT 实现尝试使用 IKE cookie 对传入的 IKE 流量进行解复用。与源端口解复用一样, IKE cookie 解复用导致重新密钥的问题, 因为阶段 1 重新密钥通常不会使用与早期流量相同的 cookie。

o) 端口 500 的特殊处理。由于某些 IKE 实现无法处理非 500 UDP 源端口, 某些 NAT 不会转换 UDP 源端口为 500 的数据包。这意味着这些 NAT 每个目的网关限制为一个 IPsec 客户端, 除非它们检查 ISAKMP 头部的详细信息以检查 cookie, 这会产生上述问题。

p) ISAKMP 负载检查。尝试解析 ISAKMP 负载的 NA(P)T 实现可能无法处理所有负载排序组合, 或支持用于 IKE 选项协商的 vendor_id 负载。