排查 Azure NAT 网关连接问题

本文内容

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

NAT 网关配置导致 SNAT 耗尽

NAT 网关的 SNAT 耗尽问题通常与 NAT 网关上的配置有关没权限使用网络资源，例如：

NAT 网关横向扩展不足

每个公共 IP 地址提供 64,512 个 SNAT 端口，用于通过 NAT 网关建立出站连接。 NAT 网关可从这些可用的 SNAT 端口最多支持 50,000 个到同一目标终结点的并发连接。 如果由于 SNAT 端口耗尽而导致出站连接断开，则原因可能是 NAT 网关横向扩展不足，无法处理工作负载。 可能需要 NAT 网关的其他公共 IP 地址才能为出站连接提供更多 SNAT 端口。

下表描述了两种因为可伸缩性问题导致的常见出站连接失败方案，以及如何验证和缓解这些问题：

场景证据缓解操作

在使用高峰期遇到 SNAT 端口争用和 SNAT 端口耗尽的情况。

在 Azure Monitor 中运行以下指标：“SNAT 连接总数”：“总和”聚合值显示较高连接数量。 对于“SNAT 连接计数”，“失败”连接状态显示一段时间内的暂时性或持续性失败。丢弃的数据包数：“总和”聚合值显示与高连接数量和连接失败保持一致的丢弃数据包数。

根据需要添加更多公共 IP 地址或公共 IP 前缀（将最多 16 个 IP 地址分配给 NAT 网关）。 这种做法可提供更多的 SNAT 端口库存，还可以让你进一步缩放方案。

你已经为 NAT 网关分配了 16 个 IP 地址，但仍然遇到了 SNAT 端口耗尽问题。

尝试添加更多 IP 地址失败。 公共 IP 地址或公共 IP 前缀资源的 IP 地址总数超过了 16 个。

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

注意

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

TCP 空闲超时计时器设置为大于默认值

默认情况下，NAT 网关 TCP 空闲超时计时器设置为 4 分钟，但最多可配置为 120 分钟。 如果将计时器设置为比默认值更高的值，NAT 网关控制流的时间会更长，可能。

下表描述了 TCP 空闲超时计时器时间过长导致 SNAT 耗尽的常见场景，并提供了可以采取的缓解步骤：

场景证据缓解操作

你想要确保 TCP 连接长时间保持活动状态，而不出现空闲和超时。可以调高 TCP 空闲超时计时器设置。 一段时间后，你开始注意到连接失败更频繁地发生。 你怀疑你可能正在耗尽 SNAT 端口清单，因为连接占用它们的时间更长。

你在 Azure Monitor 中检查以下 NAT 网关指标，来确定 SNAT 端口是否耗尽：SNAT 连接总数：“总计”聚合显示连接量很高。 对于“SNAT 连接计数”，“失败”连接状态显示一段时间内的暂时性或持续性失败。丢弃的数据包数：“总和”聚合值显示与高连接数量和连接失败保持一致的丢弃数据包数。

可采取一些可能的步骤来解决 SNAT 端口耗尽的问题，包括：

将 TCP 空闲超时减小到较低的值，以提前释放 SNAT 端口清单。 TCP 空闲超时计时器不能设置为小于 4 分钟。

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

使用 TCP Keepalive 或应用程序层 Keepalive，以避免中间系统超时。有关示例，请参阅 .NET 示例。

使用专用链接通过 Azure 主干网连接到 Azure PaaS 服务。 使用专用链接可释放 SNAT 端口，以便与 Internet 建立出站连接。

因空闲超时而导致连接失败TCP 空闲超时

如之前部分中的 所述，应使用 TCP keepalive 来刷新空闲流并重置空闲超时。 只需从连接的一端启用 TCP keepalive，使连接从两端保持活动状态。 从连接的一端发送 TCP keepalive 时，另一端会自动发送 ACK 数据包。 然后，在连接的两侧重置空闲超时计时器。 若要了解详细信息，请参阅。

注意

增大 TCP 空闲超时是最终手段，不一定可以解决根本原因。 较长的超时可以在超时时间过去时降低失败的频率，同时也会造成延迟和不必要的失败。

UDP 空闲超时

UDP 空闲超时计时器设置为 4 分钟。 与 NAT 网关的 TCP 空闲超时计时器不同，UDP 空闲超时计时器不可配置。

下表描述了因 UDP 流量空闲超时导致连接中断的常见情况，以及缓解此问题的步骤。

场景证据缓解操作

你注意到，UDP 流量正在使需要长时间维护的连接中断。

在 Azure Monitor 中检查以下 NAT 网关指标。丢弃的数据包数：“总和”聚合值显示与高连接数量和连接失败保持一致的丢弃数据包数。

可采取的一些可能的缓解步骤：- 启用 UDP keepalive。 请记住，启用 UDP Keepalive 后，它仅在连接中的一个方向处于活动状态。 该连接仍可在连接的另一端处于空闲状态并超时。 若要防止 UDP 连接进入空闲超时，应为连接流中的两个方向启用 UDP Keepalive。 -也可使用应用程序层 keepalive 来刷新空闲流和重置空闲超时。 检查服务器端对于特定于应用程序的 keepalive 存在哪些选项。

未将 NAT 网关公共 IP 用于出站流量将 NAT 网关添加到虚拟网络后，VM 将占有保持活动连接的前一 SNAT IP

如果将 NAT 网关配置为子网，则它是通往 Internet 的默认路由。 从默认出站访问或负载均衡器迁移到 NAT 网关时，新连接将立即开始使用与 NAT 网关资源相关联的 IP 地址。 但是，如果虚拟机在切换到 NAT 网关的过程中仍保持已建立的连接，则连接会继续使用建立连接时分配的旧 SNAT IP 地址。

通过以下方式测试并解决 VM 占有旧 SNAT IP 地址的问题：

如果仍然遇到问题，请打开支持案例进行进一步的故障排除。

虚拟设备 UDR 和 ExpressRoute 替代 NAT 网关来路由出站流量

启用具有自定义 UDR 的强制隧道以通过 ExpressRoute 将流量定向到虚拟设备或 VPN 时，UDR 或 ExpressRoute 优先于 NAT 网关来定向 Internet 绑定的流量。 若要了解详细信息，请参阅。

Internet 路由配置的优先顺序如下：

虚拟设备 UDR/ExpressRoute >> NAT 网关 >> 实例级公共 IP 地址 >> 负载均衡器出站规则 >> 默认出站访问

通过以下方式测试并解决虚拟设备 UDR 或 VPN ExpressRoute 替代 NAT 网关的问题：

是否用于传送出站流量。 如果正在使用其他 IP，则原因可能与自定义 UDR 有关没权限使用网络资源，请遵循剩余的步骤来了解如何检查和删除自定义 UDR。

检查虚拟网络路由表中的 UDR，具体请参阅。

按照中所述从路由表中删除 UDR。

从路由表中删除自定义 UDR 后，现在应会首选 NAT 网关公共 IP 来将出站流量路由到 Internet。

专用 IP 用于通过专用链接连接到 Azure 服务

专用链接通过 Azure 主干网络（而不是 Internet）将 Azure 虚拟网络以专用方式连接到 Azure PaaS 服务，例如 Azure 存储、Azure SQL 或 Azure Cosmos DB。 专用链接使用虚拟网络中虚拟机实例的专用 IP 地址连接到这些 Azure 平台服务，而不是 NAT 网关的公共 IP。 因此，查看用于连接到这些 Azure 服务的源 IP 地址时，你会注意到使用了实例的专用 IP。 有关专用链接支持的所有服务，请参阅此处列出的 Azure 服务。

若要检查已设置了专用链接的专用终结点：

在 Azure 门户的搜索框中，搜索“专用链接”。

在专用链接中心，选择“专用终结点”或“专用链接”服务，查看已设置的配置。 有关详细信息，请参阅。

服务终结点还可用于将虚拟网络连接到 Azure PaaS 服务。 若要检查是否为虚拟网络配置了服务终结点：

从 Azure 门户，导航到虚拟网络，然后从设置中选择“服务终结点”。

创建的所有服务终结点会与配置它们的子网一同列出。 有关详细信息，请参阅。

注意

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

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

Internet 目标终结点上的连接失败可能由多种可能的因素造成。 可能影响连接成功的因素为：

在 Azure Monitor 中使用 NAT 网关指标诊断连接问题：

其他要检查的项：

其他暂时性出站连接问题

出站被动 FTP 可能不适用于具有多个公共 IP 的 NAT 网关，具体取决于你的 FTP 服务器配置。

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

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

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

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

额外的网络捕获

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

出站连接最佳做法

Azure 会非常严谨地监视和运行其基础结构。 但在部署的应用程序中暂时性失败可能仍会发生，且无法保证传输内容不会丢失。 NAT 网关是从 Azure 部署连接出站的首选选项，以确保高度可靠且可复原的出站连接。 除使用 NAT 网关来连接出站之外，还可以参考本文后面的指南，了解如何确保应用程序有效地使用连接。

修改应用程序以使用连接池

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