本文介绍 Azure NAT 网关的最佳做法。 本指南基于卓越体系结构的五大支柱：成本优化、卓越运营、性能效率、可靠性和安全性。
作为本指南的先决条件，你应该了解 Azure NAT 网关的工作知识，并了解其各自的功能。 有关详细信息，请参阅 Azure NAT 网关文档。
成本优化
通过 Azure 专用链接或服务终结点（包括存储）配置对平台即服务 (PaaS) 解决方案的访问，这样就不必使用 NAT 网关。 专用链接或服务终结点不需要遍历 NAT 网关来访问 PaaS 服务。 与使用 NAT 网关的成本相比，这种方法降低了每千兆字节 (GB) 处理数据的成本。 专用链接和服务终结点还提供安全优势。
性能效率
每个 NAT 网关资源最多提供 50 千兆位/秒 (Gbps) 的吞吐量。 可以将部署拆分成多个子网，然后就可以为每个子网或子网组分配一个 NAT 网关，以便进行横向扩展。
每个 NAT 网关公共 IP 地址提供 64,512 个源网络地址转换 (SNAT) 端口。 最多可以为 NAT 网关分配 16 个 IP 地址，包括单个标准公共 IP 地址、公共 IP 前缀，或两者兼而有之。 对于每个分配到同一目标终结点的出站 IP 地址，NAT 网关可以分别支持多达 50,000 个传输控制协议 (TCP) 和用户数据报协议 (UDP) 的并发流。
SNAT 耗尽
请考虑采用以下指南，帮助防止 SNAT 耗尽：
NAT 网关资源的 TCP 空闲超时默认为 4 分钟。 最多可以配置 120 分钟的超时。 如果将此设置更改为比默认值更大的值，则 NAT 网关绑定到流的时间会更长，可能导致在 SNAT 端口库存方面出现不必要的压力。
原子请求（每个连接一个请求）限制了规模，降低了性能，并降低了可靠性。 你可以重用 HTTP 或 HTTPS 连接来减少连接数和关联的 SNAT 端口，而不是原子请求。 重用连接时，应用程序可以更好地缩放。 由于使用传输层安全性 (TLS) 时可以减少握手次数、开销和加密操作的成本，因此应用程序的性能将会提高。
如果不缓存 DNS 解析程序的结果，域名系统 (DNS) 查找可能会在卷中引入许多单独的流。 使用 DNS 缓存来减少流量并减少 SNAT 端口的数量。 DNS 是一种命名系统，可将域名映射到连接到 Internet 或专用网络的资源的 IP 地址。
UDP 流（例如 DNS 查找）在空闲超时期间使用 SNAT 端口。 UDP 空闲超时计时器固定为 4 分钟。
使用连接池来调整连接卷。
若要清理流，切勿以静默方式丢弃 TCP 流，且不要依赖 TCP 计时器。 如果不让 TCP 显式关闭连接，则 TCP 连接将保持打开状态。 中间系统和终结点将使此连接处于使用状态，进而使 SNAT 端口对其他连接不可用。 此反模式可能会触发应用程序故障和 SNAT 耗尽。
除非知道其含义，否则不要更改与 OS 级别别的 TCP 关闭相关的计时器值。 如果某个连接的终结点不符合预期时，TCP 堆栈会恢复，但应用程序的性能可能会受负面影响。 如果需要更改计时器值，则通常存在基础设计问题。 如果基础应用程序具有其他反模式，并且你更改了计时器值，则可能还会加速 SNAT 耗尽。
查看以下指南以提高服务的缩放和可靠性：
考虑将 TCP 空闲超时降低到较低值的效果。 4 分钟的默认空闲超时可以提前释放 SNAT 端口库存。
考虑对长时间运行的操作使用异步轮询模式，以释放连接资源供其他操作使用。
考虑为生存期较长的流（例如重复使用的 TCP 连接）使用 TCP Keepalive 或应用层 Keepalive，以防止中间系统超时。只有在不得已的情况下才应增加空闲超时，这不一定可以解决根本原因。 较长的超时可以在超时时间过去时降低失败的频率。 同时也会造成延迟和不必要的失败。 可以从连接的一端启用 TCP keepalive，使连接从两端保持活动状态。
考虑为生存期较长的 UDP 流使用 UDP Keepalive，以防止中间系统超时。在连接的一端启用 UDP keepalive 时，仅连接的一端保持活动状态。 必须在连接的两端启用 UDP keepalive，才能使连接处于活动状态。
考虑使用正常重试模式，以避免在发生暂时性故障或故障恢复期间出现频繁重试和突发。 对于反模式（原子连接），必须为每个 HTTP 操作创建新的 TCP 连接。 原子连接会浪费资源，并且会阻止应用程序正常缩放。
若要提高事务速度并降低应用程序的资源成本，请始终将多个操作管道传输到同一连接。 当应用程序使用传输层加密（例如，TLS）时，新的连接处理会增加成本。 有关更多最佳做法模式，请参阅 Azure 云设计模式。
卓越运营
可以将 NAT 网关与 Azure Kubernetes 服务 (AKS) 配合使用，但 AKS 中不包括 NAT 网关管理。 如果将 NAT 网关分配给容器网络接口 (CNI) 子网，那么将使 AKS Pod 通过 NAT 网关传出流量。
当跨地区或区域使用多个 NAT 网关时，请使用 Azure 公共 IP 前缀或自带 IP (BYOIP) 前缀使出站 IP 资产可管理。 不能将大于 16 个 IP 地址（/28 前缀大小）的 IP 前缀大小分配给 NAT 网关。
使用 Azure Monitor 警报来监视 SNAT 端口使用情况、处理或丢弃的数据包以及传输的数据量，并就其发出警报。 使用网络安全组 (NSG) 流日志监视来自配置了 NAT 网关的子网中的虚拟机 (VM) 实例的出站流量。
当使用 NAT 网关配置子网时，NAT 网关将替换该子网上所有 VM 到公共 Internet 的所有其他出站连接。 无论出站规则如何，NAT 网关都优先于负载均衡器。 网关还优先于直接分配给 VM 的公共 IP 地址。 Azure 会跟踪流的方向，并防止非对称路由。 将正确地转换入站发起的流量（例如负载均衡器前端 IP），并且将通过 NAT 网关与出站发起的流量分开转换。 这种隔离性使得入站和出站服务能够无缝共存。
建议将 NAT 网关作为默认设置，以便为虚拟网络启用出站连接。 与 Azure 中的其他出站连接技术相比，NAT 网关提供效率和操作简单性。 NAT 网关按需分配 SNAT 端口，并使用更高效的算法来防止 SNAT 端口重用冲突。 不要依赖资产的默认出站连接（一种反模式）。 而是改为使用 NAT 网关资源显式定义配置。
可靠性
NAT 网关资源在一个可用性区域中高度可用，并且跨越多个容错域。 可以将 NAT 网关部署到无区域，Azure 自动选择一个区域来放置 NAT 网关或将 NAT 网关隔离到特定可用性区域。
若要提供可用性区域隔离，每个子网都必须只能有特定区域内的资源。 若要实现此方法，可以：
- 为部署 VM 的每个可用性区域部署子网。
- 将区域 VM 与匹配的区域 NAT 网关协调。
- 生成单独的区域堆栈。
在下图中，在可用性区域 1 中的 VM 与同样仅在可用性区域 1 中的其他资源一起出现在子网上。 在可用性区域 1 中配置 NAT 网关，用于为该子网提供服务。
虚拟网络和子网跨区域中的所有可用性区域。 无需按可用性区域来划分它们以容纳区域性资源。
安全性
使用 NAT 网关时，单个 VM 或其他计算资源不需要公共 IP 地址并且可以保持完全专用。 此类无公共 IP 地址的资源仍可访问虚拟网络之外的外部源。 还可以关联公共 IP 前缀，以确保将一组连续的 IP 用于出站连接。 可以基于此可预测 IP 列表配置目标防火墙规则。
一种常见的方法是设计具有非 Microsoft 防火墙或代理服务器的仅限出站网络虚拟设备 (NVA) 方案。 当将 NAT 网关部署到具有 NVA 虚拟机规模集的子网时，这些 NVA 将使用一个或多个 NAT 网关地址而不是负载均衡器的 IP 或单个 IP 进行出站连接。 要将此方案与 Azure 防火墙结合使用，请参阅将 Azure 防火墙与 Azure 标准负载均衡器集成。
可以使用 Microsoft Defender for Cloud 警报功能监视 NAT 网关中的任何可疑出站连接。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Ethan Haslett | 高级云解决方案架构师
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。