请问RouterOS支持NAT-T吗?

pplc

查了许多文档,都没有提及routeros到底支不支持NAT-T

yefei188

NAT-T?     抱歉！  我不清楚是什么协议

txwwy

就是IPSEC 穿越NAT的问题。这个ROS 现在没有办法解决

txwwy

由于历史的原因，部署带 Internet 协议安全的第二层隧道协议（L2TP/IPSec）的问题之一在于无法定位网络地址转换（NAT）之后的 IPSec 对话方。 Internet 服务提供商和小型办公/家庭办公（SOHO）网络通常使用 NAT 来共享单个公共 IP 地址。 虽然 NAT 有助于节省剩余的 IP 地址空间，但是它们也给诸如 IPSec 之类的端对端协议带来了问题。一种称为 IPSec NAT 穿越（NAT-T）的新技术正在由 Internet 工程任务组的IPSec 网络工作组标准化。 IPSec NAT-T 是在标题为 “UOSec 包的 UDP 封装”（draft-ietf-ipsec-udp-encaps-02.txt）和“IKE中的 NAT 穿越协商”（draft-ietf-ipsec-nat-t-ike-02.txt）的 Internet 草案中描述的。 IPSec NAT-T 对协商过程进行了修改，并且定义了发送受 IPSec 保护的数据的不同方法。在 IPSec 协商过程中，支持 IPSec NAT-T的对话双方会自动确定： 发起 IPSec 对话的一方（通常是一个客户端计算机）和响应 IPSec 对话的一方（通常是一个服务器）是否都能执行 IPSec NAT-T。  它们之间的路径中是否存在任何 NAT。 如果这两个条件同时为真，那么双方将使用 IPSec NAT-T 来通过 NAT 发送受 IPSec 保护的流量。 如果其中一方不支持 IPSec NAT-T，则执行常规的 IPSec 协商（在前两个消息之后）和 IPSec 保护。 如果双方都支持 IPSec NAT-T，但是它们之间不存在 NAT，则执行常规的 IPSec 保护。IPSec NAT-T 受Windows Server 2003、Microsoft L2TP/IPSec VPN Client（一个免费的 Web 下载组件，它支持运行 Windows 98、Windows Millennium Edition 和 Windows NT 4.0 Workstation 的计算机创建 L2TP/IPSec 连接）以及L2TP/IPSec NAT-T Update for Windows XP and Windows 2000（一个免费的 Web下载组件，它支持运行Windows 2000和Windows XP的计算机创建 L2TP/IPSec 连接）的支持。本专栏研究与通过 NAT 使用 IPSec 相关联的问题，以及这些问题如何通过 IPSec NAT-T 来得到解决，以及用于快速模式和主模式的 Internet 密钥交换（IKE）协商中的结果变更。注意： IPSec NAT-T 是仅为 ESP 流量定义的。本页内容 与通过 NAT 使用 IPSec 相关的问题   对 IPSec 的 NAT-T 修改概述  通过 NAT 使用 IPSec 的问题的 IPSec NAT-T 解决办法  使用 IPSec NAT-T 的主模式和快速模式 SA 的 IKE 协商例子  更多信息 与通过 NAT 使用 IPSec 相关的问题 与通过 NAT 使用 IPSec 相关的问题如下： NAT 无法更新上层校验和。TCP 和 UDP 报头包含一个校验和，它整合了源和目标 IP 地址和端口号的值。 当 NAT 改变了某个包的 IP 地址和（或）端口号时，它通常要更新 TCP 或 UDP 校验和。 当 TCP 或 UDP 校验和使用了 ESP 来加密时，它就无法更新这个校验和。 由于地址或端口已经被 NAT 更改，目的地的校验和检验就会失败。 虽然 UDP 校验和是可选的，但是 TCP 校验和却是必需的。  NAT 无法多路传输 IPSec 数据流。ESP 保护的 IPSec 流量没有包含可见的 TCP 或 UDP 报头。 ESP 报头位于 IP 报头和加密的 TCP 或 UDP 报头之间，并且使用 IP 协议号 50。 因此，TCP 或 UDP 端口号就无法将流量多路传输到不同的专用网主机。 ESP 报头包含一个名为 Security Parameters Index（安全参数索引，SPI）的字段。 SPI 与明文（plaintext）IP报头中的目标 IP 地址和 IPSec 安全协议（ESP 或 AH）结合起来用于识别 IPSec 安全关联（SA）。对于到 NAT 的传入流量，目标 IP 地址必须映射到一个专用 IP 地址。 对于 NAT 专用端的多个 IPSec 对话方，多个 IPSec ESP 数据流的传入流量的目标 IP 地址是同一个地址。 为了将一个 IPSec ESP 数据流与另一个区分开，目标 IP 地址和 SPI 必须得到跟踪并映射到某个专用目标 IP 地址和 SPI。由于 SPI 是一个 32 位的数字，多个专用网客户端使用相同 SPI 值的概率很低。 问题在于，您很难确定哪个传出 SPI 值对应于哪个传入 SPI 值。NAT 无法映射 SPI，因为ESP尾部包含一个消息验证散列码（hashed message authentication code，HMAC），它检验 ESP 协议数据单元（PDU）的完整性（ESP PDU 包含 ESP 报头、ESP 有效载荷和 ESP 尾部），SPI 无法在 HMAC 值失效之前改变。  无法改变 IKE UDP 端口号。IPSec 的某些实现同时使用 UDP 端口 500 来作为源和目标 UDP 端口号。 然而，对于一个位于 NAT 之后的 IPSec 对话方，NAT 会改变初始 IKE 主模式包的源地址。根据具体的实现方式，来自 500 之外的其他端口的 IKE 流量可能会被丢弃。  IKE UDP 端口映射的 NAT 超时可能导致问题。NAT 中的 UDP 映射通常会很快被删除。 发起者的 IKE 流量在 NAT 中创建了一个 UDP 端口映射，它在初始主模式和快速模式 IKE 协商期间使用。 然而，如果响应者随后向发起者发送 IKE 消息却没有提供 UDP 端口映射，那么这些消息将被 NAT 丢弃。  Identification IKE 有效载荷包含嵌入的 IP 地址。对于主模式和快速模式协商，每个 IPSec 对话方发送一个 Identification IKE 有效载荷，其中包括发送对话方的嵌入 IP 地址。 由于发送节点的源地址已经被 NAT 改变，该嵌入地址和 IKE 包中的 IP 地址不匹配。 验证 Identification IKE 有效载荷的 IP 地址的 IPSec 对话方将丢弃该包，并放弃 IKE 协商。 返回页首对 IPSec 的 NAT-T 修改概述NAT-T 对 IPSec 的修改如下： ESP 的 UDP 封装UDP 报头置于外层 IP 报头和 ESP 报头之间，用于封装 ESP PDU。 用于 UDP 封装的 ESP 流量的端口和用于 IKE 的端口相同。  修改过的 IKE 报头格式IPSec NAT-T IKE 报头包含一个新的 Non-ESP Marker 字段，它允许接收方区分 UDP 封装的 ESP PDU 和 IKE 消息。 在确定存在一个中间 NAT 之后，支持 IPSec NAT-T 的对话方开始使用新的 IKE 报头。  新的 NAT-Keepalive 包这是一个和 IKE 流量使用相同端口的 UDP 消息，它包含单个字节（0xFF），用于为发送到某个专用网主机的 IKE 和 UDP 封装的 ESP 流量刷新 NAT 中的 UDP 端口映射。  新的 Vendor ID IKE 有效载荷这个新的有效载荷包含一个众所周知的散列值，它表明这个对话方能够执行 IPSec NAT-T。  新的 NAT-Discovery (NAT-D) IKE 有效载荷这个新的有效载荷包含一个散列值，它整合了一个地址和端口号。 在主模式协商期间，IPSec 对话方包括两个 NAT-Discovery 有效载荷??一个用于目标地址和端口，另一个用于源地址和端口。 接收方使用 NAT-Discovery 有效载荷来发现 NAT 之后是否存在一个经 NAT 转换过的地址或端口号，并基于被改变的地址和端口号来确定是否有对话方位于NAT之后。  用于UDP封装的ESP传输模式和隧道模式的新的封装模式这两种新的封装模式是在快速模式协商期间指定的，用于通知 IPSec 对话方应该对 ESP PDU 使用 UDP 封装。  新的NAT-Original Address (NAT-OA) IKE 有效载荷这个新的有效载荷包含 IPSec 对话方的原始（未转换的）地址。 对于 UDP 封装的 ESP 传输模式，每个对话方在快速模式协商期间发送 NAT-OA IKE 有效载荷。 接收方将这个地址存储在用于 SA 的参数中。 返回页首通过 NAT 使用 IPSec 的问题的 IPSec NAT-T 解决办法IPSec NAT-T 通过以下方式解决了通过 NAT 使用 IPSec 的问题： 问题： NAT 无法更新上层校验和。解决办法： 通过在 NAT-OA IKE 有效载荷中发送原始地址，接收方拥有检验解密之后的上层校验和（源和目标 IP 地址和端口）所需的所有信息。  问题： NAT 无法多路传输 IPSec 数据流。解决办法： 通过使用 UDP 报头封装 ESP PDU，NAT 能够使用 UDP 端口来多路传输 IPSec 数据流。 跟踪 ESP 报头中的 SPI 就不再必要了。  问题： 无法改变 IKE UDP 端口号。解决办法： IPSec NAT-T对话方能够接受来自 500 之外的端口的 IKE 消息。 此外，为了防止 IKE 敏感（IKE-aware）的 NAT 修改 IKE 包，IPSec NAT-T 对话方在主模式协商期间把 IKE UDP 端口 500 改为 UDP 端口 4500。 为了允许IKE流量使用这个新的 UDP 端口，您可能必须配置防火墙以允许 UDP 端口 4500。  问题： Identification IKE有效载荷包含嵌入的 IP 地址。解决办法： 通过在 NAT-OA IKE 有效载荷中发送原始地址，接收方拥有了可用来在快速模式协商期间检验 Identification IKE 有效载荷内容的原始地址。 由于NAT-OA IKE 有效载荷在快速模式协商发生之前没有发送，对于验证主模式期间发送的 Identification IKE 有效载荷中的 IP 地址的 IPSec 实现，它要么一定不会执行这个验证，要么通过使用另一种机制（比如名称检验）来验证对话方。  问题： IKE UDP 端口映射的 NAT 超时可能导致问题。解决办法： 通过定期发送 NAT Keepalive 包，用于后续 IKE 协商和 UDP 封装的 ESP PDU 的 UDP 端口映射同时在 NAT 中得到刷新。 返回页首使用 IPSec NAT-T 的主模式和快速模式 SA 的 IKE 协商例子增添新的 NAT-D 和 NAT-OA 有效载荷和 UDP 通道类型将修改主模式和快速模式 IKE 协商。 例如，下表显示了快速模式协商期间，一个使用 Kerberos 身份验证的基于 Windows 的 IPSec 对话方使用 Vendor-ID 和 NAT-D IKE 有效载荷的情况。 其中用于 IPSec NAT-T 的附加 IKE 有效载荷和消息变更以粗体显示。用于 Kerberos 身份验证方法的主模式消息主模式消息 发送者 有效载荷 1 发起者 Security Association（包含提议）、Vendor ID、Vendor ID（NAT-T功能） 2 响应者 Security Association（包含一个选定的提议）、Vendor ID、Vendor ID（NAT-T 功能） 3 发起者 Key Exchange（包含 Diffie-Hellman 公开密钥）、Nonce、Kerberos Token（发起者）、NAT-D（目标地址和端口）, NAT-D（源地址和端口） 4 响应者 Key Exchange （包含 Diffie-Hellman 公开密钥）、Nonce、Kerberos Token（响应者）、NAT-D（目标地址和端口）, NAT-D（源地址和端口） 5（已加密） 发起者 Identification、Hash（发起者） 6（已加密） 响应者 Identification、Hash（响应者） 如果两个节点都支持 IPSec NAT-T，并且它们之间至少存在一个 NAT，那么它们将在快速模式协商期间使用 IPSec NAT-T 选项。 假设这两个对话方之间至少存在一个NAT，结果快速模式协商将如下表所示。快速模式消息快速模式消息 发送者 有效载荷 1 (已加密) 发起者 Security Association (包含建议，包括对“UDP 封装的隧道”或“UDP 封装的传输隧道”模式的选择)、Identification（包含安全流量描述）、Nonce、NAT-OA 2 (已加密) 响应者 Security Association（包含一个选定的建议）、Identification（包含安全流量描述）、Nonce、NAT-OA 3 (已加密) 发起者 Hash 4 (已加密) 响应者 Notification（通知） 在快速模式协商结束时，两个 IPSec 对话方都拥有彼此的原始地址，并根据需要定期发送 NAT-Keepalive 包，同时对 ESP PDU 使用 UDP 封装。

pplc

谢谢