Google Cloud Cloud NAT 是什么，没有公网 IP 的服务器如何访问互联网

在Google Cloud中，一台虚拟机如果没有外部IPv4地址，并不意味着它与互联网完全隔绝。企业经常会把数据库、内部API、应用服务器、Kubernetes节点以及其他基础设施放在没有公网IP的私有网络中，但这些服务器仍然可能需要访问互联网，例如下载操作系统更新、安装软件包、调用第三方API、访问Google API或者连接外部服务。Cloud NAT解决的就是这类出站连接问题。

Cloud NAT是Google Cloud提供的托管网络地址转换服务。它允许VPC网络中的资源在没有外部IPv4地址的情况下建立到互联网的出站连接，同时不会因为配置Cloud NAT而让这些资源自动获得一个可以被互联网主动访问的公网地址。对于典型的私有VM来说，流量可以从实例经过VPC网络到达Cloud NAT，再由Cloud NAT使用配置的公网IP进行源地址转换，然后进入互联网。

这里首先需要纠正一个很常见的理解。Cloud NAT并不是一台用户可以登录进去配置的Linux NAT服务器，也不是VPC里面某个子网中的虚拟机。它属于Google Cloud的托管网络服务。用户通过Cloud NAT配置要服务哪些子网、使用哪些外部IP、需要进行哪些NAT处理等参数，而底层的NAT基础设施由Google负责运行和扩展。

典型的数据流可以这样理解：一台没有外部IPv4地址的VM，例如内部地址为10.1.2.3，它需要访问一个公网HTTPS服务。应用产生的连接首先由VPC路由决定如何到达目标地址。如果目标是互联网，并且该网络具备适当的默认路由，Cloud NAT可以为符合条件的出站流量建立NAT映射。Cloud NAT把内部源地址和源端口映射到NAT使用的外部IPv4地址和相应端口，然后把数据发送到互联网。互联网服务器看到的是Cloud NAT使用的外部IP，而不是10.1.2.3。返回数据到达Cloud NAT以后，再根据NAT状态映射回原来的内部实例。

因此，Cloud NAT的核心价值并不是“给私有服务器一个公网IP”，而是让没有外部IP的资源能够发起出站连接。这个区别非常重要。一个内部VM通过Cloud NAT访问外部网站时，外部网站看到的是NAT出口地址，但互联网中的其他主机不能仅仅因为这个NAT映射存在，就主动向这台VM建立一个新的入站连接。

Google Cloud的Cloud NAT通常与Cloud Router一起配置。这里也容易产生一个概念误区：Cloud Router并不是说所有互联网流量都必须先经过一台传统意义上的虚拟路由器。Google Cloud的网络控制面会根据配置和VPC路由决定流量路径，而Cloud Router主要负责动态路由协议相关功能以及Cloud NAT配置所依赖的区域网络组件。Google的Cloud NAT文档明确要求使用Cloud Router来配置和管理Cloud NAT的相关NAT网关。

创建Cloud NAT之前，需要先确认VPC、子网、区域以及实例的网络设计。Cloud NAT是区域性的，一个Cloud NAT配置与特定区域中的VPC子网关联。如果企业在us-central1部署应用，同时在northamerica-northeast1部署另一套应用，就应该分别检查两个区域的Cloud NAT配置，而不能认为创建一个NAT以后整个全球VPC中的所有VM都会自动获得互联网出口。

其次需要检查VPC路由。Cloud NAT并不会替用户创造一个完整的互联网路由环境。私有VM通常需要存在能够指向互联网的默认路由，例如目标为0.0.0.0/0的默认路由，并且网络路径需要允许流量到达Google Cloud的互联网出口。Google Cloud VPC的默认网络通常已经存在相应的默认互联网路由，但如果企业删除了默认路由、采用了自定义路由或者通过Network Connectivity Center等复杂架构改变了网络路径，就需要重新检查实际路由。

防火墙规则也必须单独考虑。Cloud NAT不是VPC防火墙的替代品。VPC防火墙规则决定哪些网络流量可以进入或离开实例，而Cloud NAT负责符合条件的出站连接进行地址转换。两者承担的职责不同。比如一台私有VM需要访问外部TCP 443，那么既需要网络路径能够到达Cloud NAT，也需要相应的出站防火墙策略允许该流量。如果企业使用了严格的VPC firewall policy或者层级防火墙策略，则还需要检查组织、文件夹、项目和VPC层面的实际规则。

Cloud NAT还支持为多个VM提供共享的互联网出口。这也是它非常适合企业私有子网的原因。假设一个应用集群有几十台没有外部IP的VM，它们都需要访问操作系统镜像仓库和第三方API，那么可以让这些实例通过Cloud NAT访问互联网，而不需要为每台VM单独分配外部IPv4地址。

不过，“一个NAT可以服务多少台VM”不能简单用一个固定数字回答。实际设计要考虑连接数量、每个VM的连接需求、NAT IP数量以及端口分配。Cloud NAT需要维护内部地址和外部地址之间的端口映射，因此大规模系统必须关注NAT IP地址和端口资源是否足够。Google Cloud提供了自动分配NAT IP等机制，可以根据配置和资源需求扩展NAT地址，而不是要求管理员手工为每一台VM准备一个公网IP。

对于连接数量特别大的系统，NAT端口耗尽是比“带宽不够”更值得排查的问题之一。例如大量短连接、微服务之间频繁访问外部API、容器环境中大量工作负载共享少量出口地址，都可能产生大量NAT状态。排查时应该关注Cloud NAT的监控指标和日志，而不是看到连接失败以后立即认为互联网线路出了问题。

Cloud NAT还有一个经常被忽略的特点，就是它不是传统意义上的“所有流量都经过NAT”。Google Cloud中的不同资源可能拥有自己的出站机制。某些Google Cloud托管服务、特殊网络资源以及具有其他互联网出口能力的资源，其流量路径与普通没有外部IP的Compute Engine VM并不完全相同。因此，在排查网络问题时，必须先确认具体资源类型和实际出站路径，而不能把“没有公网IP”简单等同于“必须使用Cloud NAT”。

对于Compute Engine，最典型的场景是一台只有内部IP的VM需要访问互联网。比如企业不希望Web服务器、应用服务器和数据库服务器直接拥有公网IP，但系统仍然需要从Ubuntu或Debian软件仓库下载更新。这时候可以让这些VM放在私有子网，通过Cloud NAT统一访问外部网络。

这种设计的一个重要安全优势，是减少直接暴露在互联网中的资源数量。公网IP本身并不等于服务器一定不安全，但没有公网IP的内部服务器不会因为拥有一个可直接路由到互联网的地址而天然成为互联网扫描和连接的直接目标。企业可以把公网入口集中到负载均衡器、WAF、VPN或者其他专门的边界服务，而让内部应用服务器保持私有地址。

但也不能把Cloud NAT描述成完整的安全边界。Cloud NAT并不负责替企业决定“哪些域名可以访问”“哪些应用可以访问互联网”或者“哪些端口应该允许”。如果企业要求服务器只能访问特定第三方API，那么通常还需要结合VPC防火墙、代理服务器、DNS策略、应用层访问控制或者其他网络安全产品实现更细粒度的出口控制。

Cloud NAT也不能替代VPN。如果本地数据中心需要访问Google Cloud中的私有VM，通常应该使用HA VPN、Cloud Interconnect等混合云连接方案；Cloud NAT解决的是另一类问题，也就是私有资源向互联网发起出站连接。把VPN和NAT混为一谈，会导致网络拓扑设计出现明显偏差。

同样，Cloud NAT也不能替代公网负载均衡器。如果企业部署一个Web应用，希望互联网用户主动访问这个应用，那么应该考虑Google Cloud的外部负载均衡等入口服务，而不是给内部VM配置Cloud NAT以后期待互联网用户通过NAT找到服务器。Cloud NAT主要解决的是出站连接，互联网主动建立到私有VM的新连接并不是它的用途。

Cloud NAT还需要考虑IPv4和IPv6。传统Cloud NAT主要解决IPv4私网资源访问IPv4互联网时的地址转换问题。如果企业使用IPv6架构，就不能简单套用“IPv6私有地址通过NAT访问互联网”的IPv4思路。IPv6的地址和路由模型与IPv4 NAT存在明显区别，实际设计应该根据资源类型和Google Cloud当前支持的IPv6网络能力单独规划。

成本也是设计Cloud NAT时需要考虑的因素，但不能简单用“Cloud NAT比公网IP便宜”作为结论。Google Cloud的网络成本通常涉及NAT处理、外部IPv4地址、网络数据传输以及相关资源本身产生的费用，具体金额还取决于区域、流量方向、NAT配置和其他网络服务。因此，正确的成本分析应该把整个互联网出口链路计算进去，而不是只比较一个公网IP的小时价格。

监控方面，生产环境应该关注NAT分配的外部IP数量、端口使用情况、连接数量、丢弃或失败的流量以及实际出站流量。对于偶发连接失败，最好结合Cloud NAT日志、VPC Flow Logs、VM自身连接状态以及目标服务日志一起判断。只有这样才能区分到底是NAT端口资源不足、防火墙拒绝、路由问题、DNS解析失败，还是外部服务本身拒绝连接。

Cloud NAT还有一个工程上的重要特点：它只负责连接建立后的地址转换和状态维护，并不是一个可以让管理员自由登录、安装软件、调整Linux内核参数的传统网络设备。因此，如果企业过去习惯管理机房里的iptables、SNAT规则和防火墙设备，那么迁移到Google Cloud以后需要改变思路。管理员管理的是网络策略和云资源配置，而不是维护一台承担NAT功能的服务器。

一个典型的私有应用架构可以是这样的：外部用户通过Google Cloud负载均衡器进入应用层，应用服务器和数据库服务器只使用内部IP；应用服务器需要访问互联网时，通过Cloud NAT建立出站连接；企业员工访问内部系统时，通过VPN或者其他私有连接进入VPC；如果数据中心需要与Google Cloud长期交换大量数据，则进一步考虑Cloud Interconnect。不同服务负责不同方向和不同类型的网络连接，网络边界也会因此更加清晰。

对于小型项目，Cloud NAT的价值尤其明显。开发人员不需要给每台服务器配置公网IP，只要把需要访问互联网的私有VM放进正确的VPC和子网，配置Cloud NAT以及相应的防火墙和路由，就可以让服务器正常下载软件和访问外部服务。对于大型企业，Cloud NAT则更多承担统一互联网出口的角色，同时配合日志、监控、安全策略和地址规划进行集中管理。

因此，理解Cloud NAT最简单的方式不是把它想成“Google Cloud里的一个虚拟路由器”，而是把它看成私有资源访问公网IPv4服务时使用的托管NAT能力。服务器可以没有公网IP，但仍然能够主动访问互联网；互联网服务器看到的是NAT出口地址；外部网络不能因为这个出站映射就直接把私有VM当成公网服务器访问。

在实际架构中，公网入口、私网出站、跨云连接和内部网络应该分别设计。负载均衡器解决互联网用户如何进入应用，Cloud NAT解决私有资源如何访问互联网，HA VPN解决网络之间的加密连接，Cloud Interconnect解决大规模专用网络互联。把这些服务按照各自的职责组合起来，才能构建出既方便运维，又不会把大量内部服务器直接暴露在公网中的Google Cloud网络架构。