谷歌云代金券 GCP谷歌云服务器内网互通设置

前言：内网互通这事儿，看起来玄学，其实是流程

很多人第一次做 GCP 的内网互通，都会有一种“我明明建了两台机器，为什么对方像失联了？”的挫败感。别急，GCP 并不神秘，它只是把网络能力拆成了好几块：VPC、子网、防火墙、路由、以及（有时还要）私网访问或跨 VPC 互联。你只要把这些积木一块块拼起来，就会发现互通其实很“工程化”。

本文按“从易到难”的顺序讲：先讲同一 VPC 同一子网/不同子网内互通怎么做；再讲跨 VPC 的互通要如何连接；最后给出常见问题排错清单。为了让你读起来不打瞌睡，我会尽量用人话和类比来讲。

先搞清楚：你说的“内网互通”到底是哪种

谷歌云代金券 在开始操作前，先回答三个问题，不然很容易做着做着发现方向偏了。

问题 1：两台实例在同一个 VPC 吗？

如果是同一个 VPC，通常只需要处理防火墙、路由、以及是否被网段/子网隔离影响；如果是不同 VPC，就涉及互联（如 VPC Network Peering / 共享 VPC / Transit Gateway 那类思路）。

问题 2：两台实例是否使用了同一个区域（Region）？

GCP 的网络资源与区域关系比较复杂。VPC 是全局的，但子网是区域级的。跨区域通信在同一 VPC 内通常仍可以实现，但要注意子网、路由和防火墙规则。

问题 3：你要互通的是“TCP/UDP 的某个端口”还是“全量访问”？

GCP 的防火墙是按协议与端口放行的。你说“互通”，实际上可能只是需要放行某个服务端口，比如 80/443、22、3306、8080 等。别把“互通”理解成“啥都通”。

基础篇：同一 VPC 内，让实例互通

我们先假设：你有两个实例 A 和 B。

• 它们属于同一个 VPC（同一个网络）。
• 它们都有内网 IP（没有只配置外部访问）。
• 你要通过内网访问（例如 A 调用 B 的 8080）。

在这种前提下，GCP 通常会让它们“具备互通的可能”，但防火墙可能会拦你。下面是最常见的路径。

步骤 1：确认实例的网络与标签

去 GCE 控制台点到实例详情，找“网络接口”。确认：

• 网络：是否同一个 VPC。
• 子网：各自使用哪个子网。
• 是否有“网络标签（Network tags）”。

很多人卡在这里：防火墙规则是按网络标签匹配的。你建了放行规则，但实例标签对不上，就会“看起来都放行了，实际没放”。这就像你写了“张三可进”，结果门口名单写的是“张三（旧身份证）”。

步骤 2：检查 VPC 的防火墙规则（Firewall Rules）

谷歌云代金券 在同一个 VPC 下，防火墙规则决定了是否放行。

• 你可以在 VPC 网络 → 防火墙规则里看规则列表。
• 重点关注：方向（Ingress/Egress）、目标（Target tags / Service accounts / 目标网络）、协议（TCP/UDP/ICMP）、端口范围。

常见现象：

• 你在实例 A 上能 ping 通 B，但访问某个端口失败：说明端口未放行，或服务没监听。
• 你连 ping 都不通：说明 ICMP 未放行，或路由/策略限制。
• 你明明开了 0.0.0.0/0，结果仍不通：可能你以为规则生效了，但实例并不匹配目标条件（标签/账号/网络）。

建议做法：至少明确开一个“只给内网段放行”的规则，而不是瞎放全世界。比如目标端口只放给某个内网 CIDR。

步骤 3：路由与子网（一般情况下不用你动，但要知道它在想什么）

在同一 VPC 的默认场景里，GCP 会提供相应的默认路由能力。你通常不需要手动写静态路由。

但你要知道：当子网、专用路由或定制路由存在时，路由可能把流量“赶”向不该去的地方。你可以在 VPC 网络 → 路由里查看“下一跳”。如果你没改过路由，默认应该很简单。

步骤 4：验证连通性（别凭感觉，直接测）

建议你用实例内网执行验证。常见方法：

• 从 A 到 B：ping（若允许）/ curl / nc / telnet（取决于环境）。
• 确认 B 上服务监听：例如 B 的 8080 是否在监听。

如果你没有 nc，就用 curl。GCP 不会因为你“测得不够专业”就帮你放行——它只看网络与规则。

进阶篇：同一 VPC 但跨子网互通，是否还需要特别设置

很多人以为“跨子网就不通”，其实不一定。只要它们在同一个 VPC 内，通常可以通过默认路由互通。

关键仍是防火墙。你需要注意以下几点：

• 防火墙规则是否是针对“目标标签/服务账号”的，而不是针对来源。
• 允许方向是 Ingress（入站到目标实例）而不是 Egress（出站从源实例）。很多人以为开了出站就够了，结果目标端口仍没被放行。
• 协议端口是否匹配：例如只开了 TCP 但你实际用的是 UDP。

如果你发现跨子网不通，且防火墙看起来都开了，那么就去检查实例是否在同一 VPC、是否真的使用了同一个网络，别让“同名不同网”坑你。

跨 VPC 互通：你要“连两条河”，而不是只往水里喊

当实例 A 和实例 B 在不同 VPC 时，就需要进行网络互联。最常见的方式是 VPC Peering。

步骤 1：建立 VPC Network Peering

在两个 VPC 间建立 peering 连接。创建时通常需要：

• 选源 VPC 与目标 VPC
• 确认是否交换路由（看你的路由需求）
• 注意网段是否冲突：默认情况下，如果两个 VPC 的 CIDR 发生重叠，会导致路由不可用或无法创建。

类比：如果你把两条城市的路用桥接起来，那必须先保证每条路的“地址系统”不会打架。CIDR 冲突就是地址系统打架。

步骤 2：确保防火墙允许跨 VPC 的流量

Peering 建好了，并不代表自动“所有端口放通”。防火墙仍要配置。

你需要在目标 VPC 的防火墙规则中，放行来自源 VPC 的 IP 段访问到对应端口。比如：

• 目标实例所在 VPC：放行来自源 VPC CIDR 的 TCP 访问 8080。
• 源实例所在 VPC：如果你有特别严格的出站策略，可能也要检查出站（但大多数情况下 GCE 默认 egress 放得比较开，你可以仍然确认）。

注意方向：目标侧的 Ingress 最关键。

步骤 3：检查路由是否按预期生效

Peering 有“是否自动交换路由”的选项。如果你没有交换，可能导致某些网段无法被正确路由到对端。

你可以在两个 VPC 的路由页面里查看与 peering 相关的路由条目。

更复杂的情况：共享 VPC、组织级网络与多项目场景

很多团队不是“个人搭建小宇宙”，而是“公司内部多个项目分工协作”。这时会遇到共享 VPC（Shared VPC）或组织级策略。

Shared VPC 的核心理解

共享 VPC 允许某个宿主项目（Host project）管理网络，多个服务项目（Service projects）在同一套网络下部署实例。

谷歌云代金券 在这种场景下，你要关注：

• 实例是否真正部署在同一个共享网络中（即是否在同一 VPC）
• 防火墙规则是在哪个层级配置（Host VPC 上通常生效）
• 服务项目是否正确绑定了共享网络权限

如果你看到“我明明以为在同一 VPC，怎么就是不通”，第一反应应该是：你以为自己在同一个网络里，但其实实例属于不同网络，或使用了不同的 VPC。

组织策略（Org Policy）可能也会“暗中动手脚”

比如限制某些端口、限制外部访问，或限制 VPC 相关能力。对于内网互通通常影响较少，但遇到“不符合预期”的策略时，别只盯防火墙，也查一查 org policy。

私网访问常见误区：你以为在用“内网互通”，其实在绕公网

如果你的目标是让实例访问 GCP 服务（例如 Google APIs、Cloud SQL Private IP、某些托管服务），你还可能涉及“私网访问（Private Service Connect / Private Google Access）”。

但这与“两个计算实例互通”是不同问题。

简单区分：

• 两个 GCE 实例互通：主要看 VPC、防火墙、路由（以及跨 VPC peering）。
• 实例访问 Google API/托管服务：可能要开 Private Google Access，或配置私网路径。

很多踩坑来自把这两件事混在一起：你以为是实例互通没配好，结果是你访问的其实是需要私网访问的目标服务。

端口与协议：别让“能 ping”蒙蔽你

在排查时，经常出现这样的尴尬：

• 你 ping 通了，但业务访问失败。
• 你端口（如 22）通了，但 HTTP 访问失败。

原因通常是：ICMP（ping）与 TCP/UDP 端口放行不是同一个规则。你需要分别确认：

• 是否允许 ICMP（若你依赖 ping）。
• 是否允许 TCP/UDP 的具体端口。
• 服务是否监听在正确端口、绑定正确网卡（0.0.0.0 vs 127.0.0.1）。

有时候网络没问题，是应用没绑定对。就像房间门开了，你却只把接待员摆在窗口里，外卖员再努力也递不进去。

排错清单：从“最可能”到“最折磨”的顺序查

下面是一份比较实用的排错顺序。你可以按顺序打勾，不要每一步都“全盘重来”。

1）先确认网络身份：VPC、子网、实例网卡 IP

确认 A/B 是否处于期望的 VPC，确认它们的内网 IP 是否在预期 CIDR 内。

快速检查方法：

• 从实例内查看路由表与网卡配置（ip addr / ip route）。
• 确认默认网关是否合理。

2）再看防火墙：目标侧 Ingress 最关键

检查目标实例所在 VPC 的防火墙规则是否：

• 方向是 Ingress
• 目标匹配（Network tags 或 service account）
• 来源匹配（source ranges）
• 协议与端口匹配

常见坑：

• 规则写了 0.0.0.0/0 但实例并不匹配 target。
• 规则开了 8080，但业务其实用 8081。
• 你以为你配的是目标实例的规则，但实际上只在源侧改了。

3）确认路由/Peering 是否生效

如果跨 VPC：检查 peering 是否已建立、是否交换路由、是否没有 CIDR 冲突。

如果同 VPC 但子网复杂：检查路由表是否存在自定义下一跳。

4）最后才怀疑“应用层”

网络问题最常见，但应用层也经常背刺。

谷歌云代金券 检查目标服务：

• 是否在监听（listen）
• 是否绑定到正确地址
• 是否防火墙/安全组在操作系统层也限制了

例如 Linux 上可能还有 iptables/nftables 或服务本身的访问控制。

给你一个推荐的“最小可行配置”思路

你如果想快速搭通，建议按最小可行原则：

• 先把两台实例都放到同一 VPC（同子网或不同子网也行），先验证基本连通。
• 确保防火墙 Ingress 放行目标端口（比如 8080），并匹配来源 IP 段。
• 确认服务监听正确，再做跨 VPC/更复杂结构。

等通了以后再考虑安全收敛：把源地址从宽到窄、把放行范围缩小到必要的 CIDR。

常见问答：你可能正在经历的那几种“为什么”

Q1：我把防火墙关了，为什么还不通？

防火墙不是唯一因素。可能是：

• 你放行的不是目标端口
• 实例并不匹配防火墙规则的 target 条件（tags/service account）
• 应用没监听或监听在 127.0.0.1
• 跨 VPC 未做 peering 或路由未交换

Q2：我需要开放所有端口吗？

不需要。内网互通只放行必要端口更合理。安全策略要像做饭：盐不能一上来就撒一整包。你要的是“让它能吃”，不是“让它能爆炸”。

Q3：为什么我能互相 ping，但业务不通？

因为 ping 用的是 ICMP；业务是 TCP/UDP 端口。你可能只放行了 ICMP，没有放行端口。

Q4：跨 VPC peering 建了，但还是不通。

常见原因：

• 防火墙未放行来自对方 VPC 的源网段
• 路由交换未开启，导致路由缺失
• CIDR 冲突或地址规划导致无法正确路由

安全建议：内网互通也要讲“边界意识”

很多团队会在测试阶段图快，开个全放行 0.0.0.0/0，然后上线前忘了收回。你应该：

• 把规则收敛到最小端口集合
• 把 source range 限制为对方子网/CIDR
• 用 network tags 或 service account 精准匹配目标

这样你既能快乐互通，也能不至于让系统像自来水管一样对所有路人开放。

总结：把网络当成“地图”，把防火墙当成“门禁”

一句话总结“GCP 内网互通设置”：

• 先确认两边在同一个 VPC 还是不同 VPC；
• 同 VPC 主要是防火墙与实例标签/账号匹配；
• 跨 VPC 要先做 peering，再放行跨网段的端口；
• 排错遵循先网络身份与规则匹配，再路由与最后应用监听。

谷歌云代金券 当你把这四步形成肌肉记忆，你就会从“为什么不通”升级到“我知道它为什么不通”。那种掌控感非常爽，比把开水壶拧到最热还爽。

如果你愿意，可以把你的场景补充一下：A/B 的 VPC 是否相同、是否跨区域、要放行的端口、你用的是 network tags 还是 service account。你给我这些信息，我可以帮你把规则写得更贴合实际，而不是泛泛而谈。