通过

排查 Azure NAT 网关连接问题

  • 项目

本文提供有关如何排查和解决 NAT 网关的常见出站连接问题的指南。 本文还提供了有关设计应用程序以高效使用出站连接的最佳做法。

NAT 网关上的数据路径可用性下降，连接失败

方案

可以看到 NAT 网关的数据路径可用性下降，这与连接失败相吻合。

可能的原因

  • 源网络地址转换 (SNAT) 端口耗尽。

  • 同时 SNAT 连接限制。

  • 连接超时。

对步骤进行故障排除

SNAT 端口耗尽或达到同时连接限制的可能解决方案

  • 将公共 IP 地址添加到 NAT 网关（总共 16 个）以扩展出站连接。 每个公共 IP 提供 64,512 个 SNAT 端口，支持 NAT 网关的每个唯一目标终结点最多 50,000 个同时连接。

  • 跨多个子网分布应用程序环境，并为每个子网提供一个 NAT 网关资源。

  • 通过将 TCP 空闲超时计时器减少到较低值，释放 SNAT 端口库存。 TCP 空闲超时计时器不能设置为小于 4 分钟。

  • 考虑使用异步轮询模式以释放连接资源供其他操作使用。

  • 使用专用链接通过 Azure 主干连接到 Azure PaaS 服务。 专用链接为到 Internet 的出站连接释放 SNAT 端口。

  • 如果调查没有结论，请提出支持案例以进行进一步的故障排除。

注意

必须了解发生 SNAT 端口消耗的原因。 确保为可缩放、可靠的方案使用适当的模式。 只有在万不得已时，才能在不了解需求原因的情况下将更多 SNAT 端口添加到方案。 如果不知道你的场景为何给 SNAT 端口库存施加压力，那么通过添加更多 IP 地址来添加更多 SNAT 端口，只会延缓在应用程序缩放时出现相同的耗尽故障。 其他低效的做法和对立模式可能会被掩盖。 有关详细信息，请参阅有效使用出站连接的最佳做法。

TCP 连接超时的可能解决方案

使用 TCP keepalives 或应用程序层 keepalives 刷新空闲流并重置空闲超时计时器。 有关示例，请参阅.NET 示例。

只需从连接的一端启用 TCP keepalive，使连接从两端保持活动状态。 从连接的一端发送 TCP keepalive 时，另一端会自动发送确认 (ACK) 数据包。 然后，在连接的两侧重置空闲超时计时器。

注意

增大 TCP 空闲超时是最终手段，可能无法解决问题的根本原因。 较长的超时可以在超时时间过去时造成延迟和不必要的失败。

用户数据报协议 (UDP) 连接超时的可能解决方案

UDP 空闲超时计时器设置为 4 分钟，不可配置。 为连接流中的两个方向启用 UDP keepalives，以保持长时间的连接。 启用 UDP keepalive 后，它仅对连接中的一个方向处于活动状态。 该连接仍可在连接的另一端处于空闲状态并超时。 若要防止 UDP 连接进入空闲超时，应为连接流中的两个方向启用 UDP Keepalive。

也可使用应用程序层 keepalive 来刷新空闲流和重置空闲超时。 检查服务器端对于特定于应用程序的 keepalive 存在哪些选项。

NAT 网关上的数据路径可用性下降，但没有连接失败

方案

NAT 网关的数据路径可用性下降，但未观察到失败的连接。

可能的原因

数据路径可用性的暂时性下降由数据路径中的干扰引起。

故障排除步骤

如果你发现数据路径可用性下降，但对出站连接没有任何影响，则可能是由于 NAT 网关在数据路径中拾取了瞬态噪声。

为数据路径可用性设置警报或使用Azure 资源运行状况以针对 NAT 网关运行状况事件发出警报。

未与 Internet 建立出站连接

方案

在 NAT 网关上没有观察到出站连接。

可能的原因

  • NAT 网关配置错误。

  • Internet 流量从 NAT 网关重定向，并通过 VPN 或 ExpressRoute 强制隧道到虚拟设备或本地目标。

  • 网络安全组 (NSG) 规则配置为阻止 Internet 流量。

  • NAT 网关数据路径可用性已降级。

  • 域名系统 (DNS) 配置错误。

故障排除步骤

  • 检查 NAT 网关是否配置了至少一个公共 IP 地址或前缀，并将其附加到子网。 NAT 网关在附加公共 IP 和子网之前无法运行。 有关详细信息，请参阅NAT 网关配置基础知识。

  • 检查附加到 NAT 网关的子网的路由表。 任何强制隧道到网络虚拟设备 (NVA)、ExpressRoute 或 VPN 网关的 0.0.0.0/0 流量都将优先于 NAT 网关。 有关详细信息，请参阅Azure 如何选择路由。

  • 检查虚拟机上是否为阻止 Internet 访问的网络接口配置了任何 NSG 规则。

  • 检查 NAT 网关的数据路径可用性是否处于降级状态。 如果 NAT 网关处于降级状态，请参阅连接失败故障排除指南。

  • 如果 DNS 未正确解析，请检查 DNS 设置。

出站连接丢失的可能解决方案

  • 将公共 IP 地址或前缀附加到 NAT 网关。 此外，请确保 NAT 网关已附加到同一虚拟网络中的子网。 验证 NAT 网关是否可以连接出站。

  • 在对虚拟网络的流量路由进行任何更改之前，请仔细考虑流量路由要求。 向虚拟设备或虚拟网络网关发送 0.0.0.0/0 流量的用户定义路由 (UDR) 会替代 NAT 网关。 请参阅自定义路由，详细了解自定义路由如何影响网络流量的路由。

    要了解在子网路由表上更新流量路由的选项，请参阅：

  • 更新 NSG 安全规则，阻止任何 VM 的 Internet 访问。 有关详细信息，请参阅管理网络安全组。

  • DNS 无法正确解析的原因有很多。 请参阅 DNS 故障排除指南，以便调查 DNS 解析失败的原因。

NAT 网关公共 IP 不用于连接出站

方案

NAT 网关部署在 Azure 虚拟网络中，但意外的 IP 地址用于出站连接。

可能的原因

  • NAT 网关配置错误。

  • 与其他 Azure 出站连接方法（例如 Azure 负载均衡器或虚拟机上的实例级公共 IP）的活动连接。 活动连接流继续使用建立连接时分配的旧公共 IP 地址。 部署 NAT 网关后，新连接会立即开始使用 NAT 网关。

  • 专用 IP 用于按服务终结点或专用链接连接到 Azure 服务。

  • 与存储帐户的连接来自要从其建立连接的虚拟机所在的区域。

  • Internet 流量正从 NAT 网关重定向，并强制隧道连接到 NVA 或防火墙。

如何进行故障排除

  • 检查 NAT 网关是否至少具有一个关联的公共 IP 地址或前缀，以及至少一个子网。

  • 验证部署 NAT 网关后任何先前的出站连接方法（例如公共负载均衡器）是否仍然处于活动状态。

  • 检查与其他 Azure 服务建立的连接是否来自 Azure 虚拟网络中的专用 IP 地址。

  • 检查是否已启用专用链接或服务终结点以连接到其他 Azure 服务。

  • 建立存储连接时，请确保虚拟机与 Azure 存储位于同一区域。

  • 验证用于连接的公共 IP 地址是否源自 Azure 虚拟网络中的其他 Azure 服务，例如网络虚拟设备 (NVA)。

用于不用于连接出站的 NAT 网关公共 IP 的可能解决方案

  • 将公共 IP 地址或前缀附加到 NAT 网关。 确保 NAT 网关已附加到同一虚拟网络中的子网。 验证 NAT 网关是否可以连接出站。

  • 通过以下方法测试和解决其他出站连接方法中保持旧 SNAT IP 地址的 VM 的问题：

    • 确保建立新连接，并且现有连接不会在 OS 中重复使用，或者浏览器正在缓存连接。 例如，在 PowerShell 中使用卷曲时，请确保指定了“-DisableKeepalive”参数以强制建立新连接 。 如果使用的是浏览器，则可能还会将连接汇集在池中。

    • 无需重启已配置到 NAT 网关的子网中的虚拟机。 但是，如果虚拟机重启，则连接状态会刷新。 刷新连接状态后，所有连接都会开始使用 NAT 网关资源的 IP 地址。 此行为是重启虚拟机的后果之一，而不表示需要重启。

    • 如果调查没有结论，请提出支持案例以进行进一步的故障排除。

  • 将 0.0.0.0/0 流量定向到 NVA 的自定义路由将优先于 NAT 网关，以便将流量路由到 Internet。 要让 NAT 网关将流量路由到 Internet 而不是 NVA，请删除发送到虚拟设备的 0.0.0.0/0 流量的自定义路由。 0.0.0.0/0 流量使用到 Internet 的默认路由继续，且改用 NAT 网关。

重要

在对流量路由方式进行任何更改之前，请仔细考虑云体系结构的路由要求。

  • 在 Azure 存储帐户所在的同一区域中部署的服务将使用专用 Azure IP 地址进行通信。 不能基于特定的 Azure 服务的公共出站 IP 地址范围来限制对其的访问。 有关详细信息，请参阅IP 网络规则限制。
  • 专用链接和服务终结点使用虚拟网络中虚拟机实例的专用 IP 地址连接到 Azure 平台服务，而不是 NAT 网关的公共 IP。 使用专用链接通过 Azure 主干（而不是使用 NAT 网关通过 Internet）连接到其他 Azure 服务。

注意

关于对 Azure 托管服务的专用访问，建议首选专用链接而不是服务终结点。

公共 Internet 目标中发生连接失败

方案

与 Internet 目标的 NAT 网关连接失败或超时。

可能的原因

  • 目标上的防火墙或其他流量管理组件。

  • 目标端施加的 API 速率限制。

  • 巨流量 DDoS 攻击缓解措施或传输层流量造型。

  • 目标终结点使用碎片数据包进行响应。

如何进行故障排除

  • 验证与同一区域或其他位置的终结点的连接，以进行比较。

  • 从源和目标端执行数据包捕获。

  • 查看源和目标的数据包计数（如果可用），以确定进行了多少次连接尝试。

  • 查看丢弃的数据包，以了解 NAT 网关丢弃了多少个数据包。

  • 分析数据包。 具有分段 IP 协议数据包的 TCP 数据包表示 IP 碎片。 NAT 网关不支持 IP 碎片，因此具有碎片数据包的连接会失败。

  • 确保 NAT 网关公共 IP 被列为具有防火墙或其他流量管理组件的合作伙伴目标所允许的 IP。

Internet 目标连接失败的可能解决方案

  • 验证 NAT 网关公共 IP 是否列为目标所允许的 IP。

  • 如果要创建高流量或事务速率测试，请观察降低速率是否会减少故障的发生。

  • 如果降低连接速率会减少故障的发生，请检查目标是否达到其 API 速率限制或其他限制。

FTP 服务器上主动或被动模式的连接失败

方案

使用具有主动或被动 FTP 模式的 NAT 网关时，FTP 服务器上出现连接失败。

可能的原因

  • 已启用主动 FTP 模式。

  • 已启用被动 FTP 模式，NAT 网关正在使用多个公共 IP 地址。

主动 FTP 模式的可能解决方案

FTP 在客户端和服务器之间使用两个单独的通道，即命令通道和数据通道。 每个通道在单独的 TCP 连接上进行通信，一个用于发送命令，另一个用于传输数据。

在活动 FTP 模式下，客户端建立命令通道，服务器建立数据通道。

NAT 网关与主动 FTP 模式不兼容。 活动 FTP 使用 FTP 客户端中的 PORT 命令，该命令告知 FTP 服务器要在数据通道上使用哪个 IP 地址和端口来连接回客户端。 PORT 命令使用不可更改的客户端专用 IP 地址。 基于 Internet 的通信的客户端流量由 NAT 网关进行 SNA 控制，因此 FTP 服务器会将 PORT 命令视为无效。

主动 FTP 模式的替代解决方案是改用被动 FTP 模式。 但是，为了在被动 FTP 模式下使用 NAT 网关，必须注意一些事项。

被动 FTP 模式的可能解决方案

在被动 FTP 模式下，客户端在命令通道和数据通道上建立连接。 客户端请求服务器在端口上应答，而不是尝试重新与客户端建立连接。

出站被动 FTP 不适用于具有多个公共 IP 的 NAT 网关，具体取决于你的 FTP 服务器配置。 当具有多个公共 IP 的 NAT 网关发送出站流量时，它会随机选择一个公共 IP 作为源 IP。 当数据和控制通道使用不同的源 IP 地址时，FTP 会失败，具体取决于你的 FTP 服务器配置。

为防止可能的被动 FTP 连接失败，请执行以下步骤：

  1. 检查 NAT 网关是否连接到单个公共 IP 地址，而不是多个 IP 地址或前缀。

  2. 确保允许来自 NAT 网关的被动端口范围通过位于目标终结点上的任何防火墙。

注意

减少 NAT 网关上的公共 IP 地址数量会减少可用于建立出站连接的 SNAT 端口清单，并可能增加 SNAT 端口耗尽的风险。 从 NAT 网关中删除公共 IP 地址之前，请考虑 SNAT 连接需求。 不建议更改 FTP 服务器设置以接受来自不同源 IP 地址的控制和数据平面流量。

端口 25 上的出站连接被阻止

方案

无法使用端口 25 上的 NAT 网关为简单邮件传输协议 (SMTP) 流量连接出站。

原因

对于已部署的 VM，Azure 平台会阻止 TCP 端口 25 上的出站 SMTP 连接。 此块是为了确保为 Microsoft 合作伙伴和客户提供更好的安全性，保护 Azure 平台，并且符合行业标准。

使用经过身份验证的 SMTP 中继服务从 Azure VM 或 Azure 应用服务发送电子邮件。 有关详细信息，请参阅排查出站 SMTP 连接问题。

更多故障排除指南

额外的网络捕获

如果调查不确定，请提出支持案例，以便进一步进行故障排除，并收集以下信息，以便更快地解决问题。 在 NAT 网关配置的子网中选择单个虚拟机，然后执行以下测试：

  • 使用来自虚拟网络中后端 VM 之一的 ps ping 测试探测端口响应并记录结果（示例：ps ping 10.0.0.4:3389）。

  • 如果这些 ping 测试未收到响应，请在运行 PsPing 时，在后端虚拟机和虚拟网络测试虚拟机上同时运行 netsh 跟踪，并停止 netsh 跟踪。

出站连接最佳做法

Azure 会非常严谨地监视和运行其基础结构。 但是，在部署的应用程序中暂时性失败可能仍会发生，且无法保证传输内容不会丢失。 NAT 网关是从 Azure 部署建立高度可靠且可复原的出站连接的首选选项。 如需优化应用程序连接效率，请参阅本文后面的指南。

使用连接池

利用连接池时，可以避免为对同一地址和端口的调用而打开新的网络连接。 可以在应用程序中实现连接池方案，其中在一组固定的连接中内部分布请求，并且在可能的情况下，重复使用这些请求。 此设置会限制正在使用的 SNAT 端口的数量，并创建更加可预测的环境。 连接池有助于降低延迟和资源利用率，并最终提高应用程序的性能。

要详细了解 HTTP 连接池，请参阅使用 HttpClientFactory 的 HTTP 连接池。

重复使用连接

将应用程序配置为重复使用连接，而不是为每个请求生成单独的原子 TCP 连接。 连接重用会产生性能更高的 TCP 事务，并与 HTTP/1.1 之类的协议尤其相关，在这些协议中，默认设置是重复使用连接。 此重用适用于使用 HTTP 作为其传输的其他协议，例如 REST。

使用主动性较低的重试逻辑

当 SNAT 端口耗尽或应用程序发生故障时，无衰减或回退逻辑的积极重试或暴力重试会使耗尽状况再次发生或一直持续。 使用主动性较低的重试逻辑，可以降低对 SNAT 端口的需求。

根据配置的空闲超时，如果重试过于频繁，则连接没有足够的时间关闭和释放 SNAT 端口以供重复使用。

有关其他指导和示例，请参阅重试模式。

使用 keepalive 重置出站空闲超时

有关 keepalives 的详细信息，请参阅TCP 空闲超时。

如果可能，应使用专用链接直接从虚拟网络连接到 Azure 平台服务，以减少对 SNAT 端口的需求。 减少对 SNAT 端口的需求有助于降低 SNAT 端口耗尽的风险。

若要创建专用链接，请参阅以下快速入门指南以开始使用：

后续步骤

我们始终努力提高客户体验。

若要详细了解 NAT 网关，请参阅：