Google Cloud Global Account Google Cloud Firewall Rules Configuration Guide

Introduction

Google Cloud 的防火墙规则用来控制网络流量：允许还是拒绝、允许哪些源、访问哪些目标、用哪些协议与端口。它并不是“建一个规则就结束”的工作，因为同一条流量可能同时受到多层配置的影响，包括 VPC 防火墙规则、路由、实例网络栈、以及是否通过负载均衡或代理转发等。配置得越细，越需要把规则的方向、优先级、匹配条件和验证方法说清楚。

这份指南用更落地的方式带你完成一套可运行的配置：先理解防火墙规则模型，再按步骤创建规则、验证效果，最后给出常见场景与排错清单。你不需要记住所有术语，但需要学会“如何判断这条流量为什么被允许或拒绝”。

1. 防火墙规则的核心概念

1) 规则的组成要素

每条防火墙规则通常由以下部分构成：

• 方向（Direction）：入站（Ingress）或出站（Egress）。入站是到达目标实例的流量，出站是从实例发出的流量。
• 动作（Action）：允许（Allow）或拒绝（Deny）。
• 优先级（Priority）：当多条规则都匹配同一流量时，优先级数值越小越优先。
• 目标（Targets）：规则适用哪些资源。常见做法是按网络标签（Network tags）选择实例，或用服务账户（Service accounts）选择实例。
• 源/目的（Source / Destination）：入站时通常是源 IP 段；出站时通常是目标 IP 段。
• 协议与端口（Protocols and Ports）：例如 tcp/udp/icmp 以及端口范围。

Google Cloud Global Account 理解这些字段后，你会发现配置并不神秘：你是在“描述流量特征 + 匹配范围 + 决策”。

2) 入站与出站不要混淆

很多第一次配置的人会把“我要允许外部访问我服务器的 22 端口”理解成出站规则。实际上这是典型的入站场景：外部客户端的流量要进入你的实例，因此你应创建 Ingress 规则，指定 目标实例、端口、以及 允许的源 IP。

反过来，如果你要限制实例对外访问某些地址或端口，比如只允许应用访问特定数据库网络，也多半是 Egress 规则。

3) 默认行为与“最小权限”思维

防火墙规则经常让人踩坑的一点是：你以为“没有写拒绝就是允许”，但现实是要看你使用的默认网络策略、以及其他规则是否已经放行。一个实用的原则是从最小权限开始：先只放通你必须的端口与源范围，再逐步验证后扩展。

同时你要记得：当存在多条匹配规则时，优先级决定最终动作。不要假设规则的创建顺序就是执行顺序。

2. 准备工作：选择网络与实例

1) 明确你要控制的是哪个 VPC

Google Cloud 中防火墙规则是作用在 VPC 网络上的。你需要确认：

• 你的实例位于哪个 VPC（以及是否有多个 VPC）。
• 实例是否使用默认网络标签或你计划自定义的标签。
• 实例是否在同一地区/同一项目，但注意防火墙规则通常按项目与网络来管理。

2) 用网络标签组织目标

如果你打算对某类实例统一开放特定端口，网络标签是最常用的方式。例如你给所有 Web 服务器加标签 web-servers。之后防火墙规则只要针对这个标签即可。

这样做的好处是：你可以在不中断规则的前提下新增实例，直接给它贴上相同标签，它就会自动纳入控制范围。

Google Cloud Global Account 3) 确认实例的系统层面也允许

防火墙规则并不等同于操作系统防火墙。即使云端规则允许了端口，实例内部如果没有启动对应服务或系统防火墙仍在拦截，连接依然会失败。因此在验证时要把两个层面都考虑进去：

• 云端：入站/出站是否允许。
• 实例：服务是否监听、OS 防火墙是否放行。

Google Cloud Global Account 3. 创建防火墙规则的逐步流程

步骤 1：规划规则集合

Google Cloud Global Account 在开始创建之前，先写下你要实现的目标。例如：

• 允许来自公司办公网（假设是 203.0.113.0/24）访问 Web 服务器的 443。
• 只允许堡垒机（假设是 198.51.100.10/32）访问 SSH（22）。
• 限制实例的出站访问，仅允许到公司内网（10.0.0.0/16）的 5432（PostgreSQL）。

规划阶段的价值在于避免“创建一堆宽泛规则，最后再说排错”。防火墙最怕宽泛。

步骤 2：设定优先级

优先级通常用来解决“冲突”。你可以采用一个清晰的策略，比如把“拒绝规则”设为更高优先级（数值更小），把“允许规则”设为较低优先级；或反过来采用分层编号。但无论你采用哪种方案，都要保持一致。

举例：如果你有一条规则允许所有 web-servers 的 443，同时又有一条更具体的拒绝规则禁止某个 IP 段，那么拒绝规则应当更优先，否则允许规则可能把冲突吞掉。

步骤 3：选择 Targets

你需要决定规则作用到哪些实例。两种常见方式：

• 按网络标签（Network tags）：适合同类实例。
• 按服务账户（Service accounts）：适合以身份区分的访问策略。

大多数基础入门场景用网络标签更直观。确认标签名后，确保实例上确实绑定了相同标签。

步骤 4：指定源/目的 IP 段

对入站规则，源 IP 段决定“谁能访问”。建议尽量使用更小的网段，而不是 0.0.0.0/0。对管理接口（SSH、RDP 等）更应如此。

当你必须面向公开互联网时，可以考虑把源限制到你实际的入口，例如云负载均衡的前端 IP 范围，或 WAF/代理的地址范围（前提是你能拿到稳定的源信息）。

步骤 5：定义协议与端口

端口范围要准确。比如允许 443 就只写 443，不要写成 1-65535。对于需要多端口的服务，可以写多个端口或端口范围（取决于你的策略）。

另外要注意 ICMP：有些场景你可能只需要 ping（ICMP），但要明确它是哪个类型与代码（如果平台提供更细颗粒度）。

步骤 6：验证规则的匹配范围

创建完成后，先做“逻辑验证”。你可以用下面问题检查：

• 这条规则是否会匹配到目标实例？（Targets 是否正确）
• 这条规则是否匹配到源 IP？（Source range 是否正确）
• 协议与端口是否匹配？（tcp/udp/icmp，端口是否一致）
• 是否存在其他更高优先级规则也匹配？（Priority 冲突）

如果这四个点对不上，连接测试即使失败也并不奇怪。

4. 典型场景：从配置到验证

场景 A：允许 HTTPS 访问 Web 服务器

目标：让外部用户通过 443 访问应用。

• 规则类型：Ingress
• Google Cloud Global Account 动作：Allow
• Targets：web-servers 标签
• 协议：tcp
• 端口：443
• 源 IP：如果是公开访问，用 0.0.0.0/0（但尽量评估风险）；如果是通过固定入口则用更具体的前端范围。

Google Cloud Global Account 验证方法建议按顺序：

1. 确认 Web 服务在实例上已启动并监听 443。
2. 从外部客户端发起连接（例如浏览器或 curl 类工具）。
3. 如果失败，先检查是否还有拒绝规则优先级更高。

场景 B：只允许堡垒机访问 SSH

目标：SSH 只能从堡垒机进入。

• 规则类型：Ingress
• 动作：Allow
• Targets：ssh-enabled 标签（只给需要被运维的实例贴标签）
• 协议：tcp
• 端口：22
• 源 IP：堡垒机的公网地址或固定出口地址（如 198.51.100.10/32）

建议加上一个安全边界：

• 对 SSH 不要开放到全网。
• 如果你还存在“默认允许内部网段”的规则，确认它不会绕开你的限制。

场景 C：限制数据库出站访问

目标：实例只能向特定内网数据库访问 5432。

• 规则类型：Egress
• 动作：Allow
• Google Cloud Global Account Targets：要发起访问的实例（用标签或服务账户定位）
• 协议：tcp
• 端口：5432
• 目的 IP 段：数据库所在网段（例如 10.0.0.0/16 或更具体子网）

随后你可能还需要配置拒绝规则来形成“只允许这些，其他都不行”的效果。关键点是：你要定义清楚“未匹配的默认行为是什么”，并用优先级让你的安全策略落到实处。

5. 排错思路：连接失败时你应该怎么查

1) 先判断失败属于哪一层

连接问题常见来源：

• 云端防火墙拒绝（方向不对、targets 不对、端口不对、优先级冲突、源/目的 IP 不匹配）。
• 实例内部服务未监听或应用未启动。
• 实例内部系统防火墙仍阻止。
• 路由问题导致流量没到达正确目标。

你可以通过从实例内部做本地测试（例如本地 curl 到本机监听端口）来快速排除一部分情况。

2) 认真核对方向：Ingress vs Egress

这是最常见错误之一。很多失败来自你以为在控制“我允许别人访问”，但实际你写的是出站；或者你想限制“实例对外访问”，却创建了入站规则。把方向写到纸上会更清晰。

3) 检查优先级冲突

如果你有多条规则可能匹配同一流量，系统会选优先级更高的那条。排错时建议你：

• 列出所有可能匹配的规则（同一方向、targets 覆盖目标、协议/端口匹配、源/目的范围包含实际 IP）。
• 比较它们的优先级。
• 确认最终动作是 Allow 还是 Deny。

当你找到了“最终动作”，问题就会明显。

4) 把源/目的 IP 做成可验证的事实

很多人写防火墙规则时用“看起来合理”的网段，但实际连接来自 NAT 或者代理出口地址不同。验证时要确认：

• Google Cloud Global Account 你实际连接发起方的公网出口 IP 是什么。
• 如果通过负载均衡或跳板，云端看到的源地址是不是你预期的。

Google Cloud Global Account 只要源 IP 不匹配，规则就不会命中。

5) 端口与协议要一一对应

例如你为 tcp/443 开了规则，但应用实际使用 udp/443，连接就会失败。或你以为开放了 8443，却实际测试的是 443。把端口写在测试命令里，让自己别靠记忆。

6) 验证实例是否真的打上了标签

Targets 常见失效原因是标签没绑定或绑定到错误实例组。你可以把“标签状态检查”当作排错的第一步：只要标签不对，后面的规则都可能是无效的。

6. 安全最佳实践：让规则更可控

1) 避免过宽的源范围

开放 0.0.0.0/0 并非一定不行，但至少要建立边界：只开放必要端口，配合应用层认证，并在需要时用额外保护层（如 WAF、CDN 或专用入口）。如果你能把源范围收窄，就优先收窄。

2) 把规则按职责分组

你可以用命名与优先级策略把“Web 入站”“运维 SSH”“数据库出站”区分开。这样当规模变大时，你不会在几十条规则里迷路。

3) 对管理接口保持克制

SSH、RDP、Kubernetes API 等管理端口尽量走专用路径。至少确保：

• 只允许固定来源 IP。
• 优先级与冲突规则明确。
• 需要时使用堡垒机。

4) 使用“可验证”的变更流程

配置防火墙规则尽量不要“先改再祈祷”。更稳的做法是：

• 每次只改一小块策略。
• 在改完后立刻进行连接测试。
• 保留变更前后的差异记录，便于回滚和复盘。

7. 常见问题清单

为什么明明写了 Allow 但仍然连不上？

通常原因包括：方向写错、targets 没匹配、端口协议不一致、源 IP 不一致、或者存在更高优先级的 Deny 规则覆盖了结果。

如何判断是云端规则问题还是实例问题？

你可以先从实例内部验证服务监听，再从实例外部验证网络到达。若实例内部正常但外部失败，更可能是云端防火墙或路由问题；若实例内部也失败，优先看服务与系统防火墙。

我改了规则为什么不生效？

检查你是否改到了正确的 VPC、正确的项目环境，以及目标实例是否真的满足 targets 条件。同时确认优先级是否被其他规则覆盖。

是否要为每个端口都写一条规则？

不一定。端口范围允许时可以合并，但要避免把端口写得过宽。一个实际经验是：把同类服务的端口按合理范围聚合，并确保仍然清晰可控。

Conclusion

Google Cloud 的防火墙规则并不难掌握，但要配置得稳，需要把“方向、优先级、targets、源/目的、协议与端口”这些字段当作一个整体来理解。最有效的学习方式不是一次性堆满规则，而是从一个明确目标出发：写规则、验证连接、再迭代优化。只要你在每次排错时都能回答“这条流量命中了哪些规则，最终动作是什么”，问题就会越来越少。

当你把规则变成可验证的策略，你就不仅是在“让它跑起来”，而是在让系统更安全、更可维护。