Google Cloud Compute Engine 防火墙规则怎么配置，如何只开放必要端口

在 Google Cloud Compute Engine 中，虚拟机能否接受网络连接，不只是由操作系统里的 Windows Defender Firewall 或 Linux 防火墙决定。VPC 网络本身也提供分布式防火墙能力，规则可以控制进入和离开虚拟机的网络流量。

Google Cloud 推荐按照最小权限原则配置防火墙，也就是业务需要什么流量就允许什么流量，没有必要开放的端口不要开放。尤其是 SSH、RDP、数据库和管理接口，不应该为了“方便测试”长期暴露给整个互联网。

先理解 Google Cloud 防火墙怎么工作

VPC 防火墙规则是在网络层定义的，但最终作用于VPC中的虚拟机实例。它可以根据流量方向、来源、目标、协议和端口等条件匹配流量。Google Cloud 的 VPC 防火墙是有状态的，允许一个连接通过后，该连接对应的返回流量也会被连接跟踪机制允许，不需要再创建一条相反方向的规则。

这里有一个容易混淆的地方：不能简单地说“Google Cloud 默认拒绝所有流量”。VPC存在隐含的Ingress拒绝规则，但具体网络可能还有已经创建的显式允许规则。例如默认网络通常带有允许内部通信以及SSH、RDP等流量的规则。自定义VPC的行为则不同，实例之间的内部通信也需要相应的Ingress允许规则。

因此，在修改防火墙之前，第一步不是直接创建新规则，而是先查看当前VPC究竟已经有哪些规则。

可以使用：

```bash
gcloud compute firewall-rules list
```

如果只想查看指定VPC的规则，可以进一步过滤网络名称。

防火墙规则最重要的几个参数

配置一条VPC防火墙规则时，需要理解几个核心条件。

首先是方向。Ingress控制进入实例的流量，Egress控制实例向外发送的流量。两者是不同方向的规则，不能把一条Ingress规则理解成同时控制进出流量。

其次是优先级。Google Cloud 防火墙并不是按照“谁后创建谁覆盖谁”的简单逻辑工作。规则存在明确的优先级，而且现代 Google Cloud 还存在组织级、文件夹级以及网络级的防火墙策略，不同层级可能参与规则评估。具体评估顺序取决于网络所采用的防火墙策略执行顺序。

因此，修改规则时应该先检查现有策略，而不能只看自己刚刚创建的几条VPC firewall rules。

第三是来源和目标。对于Ingress规则，可以限制来源IP地址范围，也可以根据目标实例的网络标签、服务账号等条件限制规则作用范围。Google Cloud 官方也建议，对于允许规则，应尽可能把规则限制到特定虚拟机，而不是让规则覆盖整个VPC。

第四是协议和端口。Web服务器通常只需要TCP 80和443；Linux SSH通常使用TCP 22；Windows RDP通常使用TCP 3389，但这些端口都只是常见默认值，实际应用可以配置成其他端口。

Web服务器应该怎么开放

假设一台Compute Engine虚拟机运行网站，外部用户只需要访问HTTP和HTTPS。

通常可以建立Ingress允许规则，只开放TCP 80和443。

如果网站已经全部使用HTTPS，甚至可以根据业务情况只保留443，而不开放80。是否保留80取决于网站是否需要HTTP跳转到HTTPS。

来源地址是否使用 `0.0.0.0/0`，则取决于服务性质。

公共网站必须接受互联网用户访问时，80或443使用 `0.0.0.0/0` 是正常的，因为用户来源IP无法预先限定。但这并不意味着应该把22、3389、3306、6379等管理和数据库端口同样开放给 `0.0.0.0/0`。

这就是“最小开放”的核心：公共服务开放公共端口，管理服务和内部服务尽可能限制来源。

SSH不要随便开放给全世界

Linux服务器的SSH默认端口通常是22。

最简单的做法是允许TCP 22来自 `0.0.0.0/0`，但这会让SSH服务直接暴露在互联网环境中，虽然并不等于服务器必然被攻破，却会增加扫描、暴力破解和漏洞攻击的暴露面。

更合理的方法是把来源限制为固定办公IP、VPN地址或者其他可信网络。

如果使用Google Cloud提供的IAP进行SSH访问，则还可以采用基于IAP的访问方式，而不必让SSH端口直接面向整个互联网。Google Cloud官方也提供通过IAP进行Compute Engine远程访问的方案。

因此，“开放22端口”并不是SSH配置的全部。真正重要的是谁可以连接到22端口。

数据库端口最好只允许应用服务器访问

例如MySQL通常使用3306，PostgreSQL通常使用5432。

如果数据库和Web应用部署在不同的Compute Engine实例上，数据库服务器没有理由接受来自整个互联网的3306或5432连接。

更合理的设计是，只允许应用服务器所在的实例或受信任的内部网络访问数据库端口。例如：

应用服务器 → TCP 3306 → 数据库服务器

互联网用户 → TCP 3306 → 数据库服务器

后者应该被阻止。

如果数据库服务本身只需要内部通信，那么更没有必要给数据库虚拟机配置公共访问路径。

内部服务也应该按端口限制

微服务、API服务器或者其他内部服务可能使用8080、8443等端口。

这里同样不应该简单地创建一条规则，允许VPC中所有实例访问所有TCP端口。

如果服务A只需要访问服务B的8080端口，就允许相应来源访问B的8080，而不是开放整个TCP端口范围。

这样做的好处是，即使VPC中另一台虚拟机遭到入侵，攻击者能够横向访问的网络范围也会受到限制。

网络标签和服务账号怎么选择

Google Cloud防火墙可以通过网络标签等方式把规则应用到特定实例，也可以使用服务账号等条件进一步限定目标。

例如，可以让一组Web服务器使用相同的目标标识，让80和443规则只作用于这些服务器，而不是整个VPC。

对于规模较大的环境，还可以使用更现代的防火墙策略和标签机制进行更细粒度的控制。Google Cloud目前同时提供VPC firewall rules、网络防火墙策略以及组织和文件夹级的层级防火墙策略，不同规模的环境应该采用相应的管理方式。

不要为了“安全”创建大量互相冲突的规则

防火墙规则越多不一定越安全。

如果管理员创建大量重复规则、不同优先级的Allow和Deny规则，却没有清楚记录每条规则的用途，出现连接故障时反而更难排查。

比较合理的做法是按照业务角色组织规则，例如Web入口、SSH管理、应用内部通信、数据库访问，然后明确每条规则的来源、目标、端口和用途。

对于企业环境，还可以利用防火墙策略集中管理多个网络和项目。组织级和文件夹级的层级防火墙策略可以在更高层级限制某些流量，低层级规则不能简单地绕过上层已经生效的限制。

如何检查防火墙规则是否生效

当某个端口无法连接时，不要马上修改规则。

首先确认虚拟机是否运行、目标IP是否正确，以及服务程序是否真的监听目标端口。

例如Linux服务器可以使用：

```bash
ss -lntp
```

检查TCP监听端口。

然后检查Google Cloud防火墙规则：

```bash
gcloud compute firewall-rules list
```

再检查规则的网络、方向、优先级、来源范围、目标条件和协议端口是否符合实际流量。

如果Google Cloud防火墙允许流量，但服务器依然无法连接，还应该检查操作系统自己的防火墙以及应用程序监听地址。例如Linux上的ufw、firewalld、iptables/nftables，以及Windows Defender Firewall，都可能在VPC防火墙之后继续阻止连接。

日志可以帮助判断规则是否匹配

对于需要进一步分析的环境，可以启用VPC防火墙规则日志。Google Cloud的防火墙日志可以记录网络流量与规则匹配情况，并通过Cloud Logging进行查询和分析。

VPC Flow Logs则是另一个层面的网络分析工具，可以帮助观察网络流量模式。两者用途并不完全相同，因此不能简单地把Firewall Logs和VPC Flow Logs当成同一种日志。

不要把压力测试当成防火墙配置的基本验证

防火墙规则的基本验证并不需要一上来就使用JMeter或Locust进行压力测试。

如果只是验证TCP 443是否开放，首先应该进行简单的连通性测试，再确认服务器上的应用是否监听对应端口。

只有当系统已经进入实际业务运行阶段，需要验证高并发下的应用性能时，压力测试才有意义。防火墙是否允许某个端口，与Web应用在高并发下能承受多少连接，是两个不同的问题。

同样，`tcpdump`是非常有价值的底层排查工具，但它主要用于观察主机实际收到和发送的网络数据包。它不能代替Google Cloud防火墙规则本身的配置检查。

VPC Service Controls也不是普通的VM端口防火墙

原文最后把VPC Service Controls与Compute Engine防火墙放在一起，容易让读者产生误解。

VPC Service Controls主要用于围绕Google Cloud服务和数据建立服务边界，防止数据从受保护服务环境中被不当访问或外泄。它并不是用来代替Compute Engine的TCP/UDP端口防火墙。

因此，一个典型的Compute Engine安全架构可能同时涉及VPC防火墙、操作系统防火墙、IAM、IAP、负载均衡器以及其他安全服务，但它们解决的是不同层面的问题。

对于普通Compute Engine服务器，最实用的原则其实很简单：先确认服务器到底需要哪些网络连接，再为每种连接建立最小范围的允许规则。网站通常只需要对外提供必要的Web端口，SSH和RDP应该限制管理来源，数据库端口应该尽量只允许应用服务器访问，内部服务则按照实际调用关系开放。

Google Cloud防火墙真正需要避免的并不是“规则数量太少”，而是管理员不知道自己开放了什么、为什么开放以及谁能够访问。把端口、来源、目标和业务用途对应起来，再定期清理已经不再需要的规则，比单纯增加大量安全产品更加重要。