谷歌云赠金号 GCP实名号专有网络搭建

最近不少人问我：在做“GCP实名号专有网络搭建”时，到底该先做什么、再做什么、以及最容易翻车的点在哪。坦白说，GCP 的网络能力确实强，但它不太像“搭积木”，更像“开飞机”。你能把每个开关都拨对，但如果顺序乱了、参数没想清楚，飞机照样不飞。

所以这篇文章我就按“从零开始到能用且可维护”的节奏，把专有网络（VPC）搭建讲明白：你该怎么规划、怎么创建子网、怎么设置路由和防火墙、怎么把网络边界做得像个人话、还要如何排查那些让你怀疑人生的网络问题。

一、先搞清楚：什么是“专有网络”？你为什么需要它？

在 GCP 里，专有网络通常指的是你自己创建并管理的 VPC（Virtual Private Cloud）。它和“默认网络”不一样：默认网络通常是“你不管它，它也能跑”，但你想要更清晰的隔离、更可控的防火墙、更适配业务的子网划分与路由策略，那就得自己来搭专有网络。

如果你的目标是：

• 不同环境（开发/测试/生产）隔离开来；
• 业务网络与管理网络分开；
• 只允许特定来源访问（比如 VPN、堡垒机、内部服务）；
• 尽量避免“到处开端口”的灾难；
• 后续扩展（加更多网段、加多区域、加私网访问）不至于大动干戈；

那你就有充分理由搭建专有网络。

至于你提到的“实名号”，这里我的理解是：你是在一个更规范的生产环境场景下做部署，往往对安全边界、访问控制、资源归属和合规性更敏感。网络这块你越早把框架定好，后面越省心。别等到所有应用都上线了才想起“当初怎么没做隔离”。

二、规划是王道：搭 VPC 之前先把“地图”画出来

网络搭建的坑往往发生在你还没动手之前：子网划分随意、IP 规划不考虑增长、路由策略不清楚、管理通道和业务通道混在一起。

1）先决定你的网络规模

你要做的是单区域还是多区域？每个区域会部署多少实例？是否需要跨区域互通？是否要给未来的业务预留空间？

如果你还不确定，给你一个比较“人类友好”的经验：先按最可能的部署形态做第一版，保留扩展余地。IP 不够比功能不全更要命，因为改 IP 的时候你要动的不只是网络资源，可能还有应用配置、DNS、访问策略。

2）IP 段规划：宁可多想一步，也别临时抱佛脚

典型做法是把地址空间按用途分段：

• 谷歌云赠金号 业务子网（App subnet）：例如 10.10.0.0/20；
• 管理子网（Mgmt subnet）：例如 10.10.16.0/20；
• 可选的服务子网（Data/Services subnet）：例如 10.10.32.0/20；

为什么管理子网建议单独分？因为管理访问的策略通常最严：只允许从堡垒机、VPN 网段访问某些端口。如果你把管理服务和业务服务混在同一网段，后续做策略会很麻烦，心态也会更容易爆炸。

3）区域与子网：别把“子网”当成“随便选选就行”

GCP 的子网是区域级资源（Regional subnet），你可以选择在某个 region 创建。每个子网关联一个区域。

如果你有单区域业务，就简单：只在一个 region 创建需要的子网。

如果你要跨区域部署，建议你在每个 region 都按同样的子网结构创建（尽量保持命名和规划一致），否则后面你会在排查问题时发现自己像在找迷宫的出口。

三、创建 VPC：从“可以用”到“可维护”

接下来就是动手建 VPC。

1）创建自定义 VPC

在 GCP 控制台里进入 VPC 网络相关页面，创建一个自定义 VPC（Custom VPC）。建议你：

• 给 VPC 起一个清晰的名字，比如：prod-vpc、test-vpc；
• 选择是否需要自动创建路由（自动模式/自定义路由模式）；
• 考虑未来是否要接入自建网络/其他云（此时路由策略要更严谨）。

谷歌云赠金号 经验上，如果你刚开始不想把自己拖进路由地狱，默认先使用“自动模式”是可以的。等你确定了网络复杂度，再切换到“自定义模式”并实现更细粒度控制。

2）创建子网（Subnetwork）

在 VPC 下创建子网，分别为业务和管理配置不同的 IP 范围。

要注意两点：

• 子网必须在具体 region 创建，且 IP 范围不能与其他子网重叠；
• 子网大小要覆盖你的实例数量增长，别刚开始用 /24，后面扩到 /21 还要推翻重来。

四、路由策略：别让“默认通了”变成“到处通了”

路由是网络的骨架。GCP 在 VPC 中会有默认路由行为，具体取决于你使用的路由模式（自动/自定义）以及是否启用了相关功能。

你需要关注：

• 到 Internet 的默认路径（通常经由 Internet Gateway 或 NAT 方案）；
• 私网出口（例如 Cloud NAT，或与外部网络的互连）；
• 跨网段互通（比如你要连接本地网络 VPN / 专线，或 VPC 间互通）。

如果你的业务希望“实例没有公网 IP，只能走私网出口”，常见组合是：子网里不给实例公网，使用 Cloud NAT 让它们访问外网。

Cloud NAT：让出网变得体面

如果你把实例放在私网子网里，不给它们外网直连权限，它们想更新系统、拉取镜像、访问外部 API 就需要 NAT。

Cloud NAT 的价值在于：你能控制出网，让出网地址可控，并且避免把公网暴露面拉得太大。

简单来说：NAT 是“出门可以，但走门槛要检查”。

五、防火墙：你以为你在做安全，其实你在做“玄学放行”

防火墙规则是你对网络行为的“法律条文”。你要么写清楚“哪些能访问哪里”，要么等着后面出现“明明没开端口却能通”或“明明开了端口却连不上”的反复折磨。

1）分层思路：先做基础，再做业务

建议防火墙规则按层级建：

• 基础规则：ICMP（如果需要）、DNS（如果你需要私有解析）、NTP（如果涉及时间同步）等；
• 谷歌云赠金号 管理规则：只允许堡垒机或 VPN 网段访问管理端口（比如 22、3389 或自定义管理端口）；
• 业务规则：仅允许必要的端口和协议访问（比如 HTTP/HTTPS、数据库端口、内部服务端口）；
• 限制规则：对不需要的方向一律不放行（默认拒绝更符合安全直觉）。

2）优先使用标签/服务账户进行规则绑定

很多人防火墙规则写着写着就变成“对所有实例开放”。你当然可以这样做，但你最终会发现：安全不是愿望，是规则。

更推荐的做法是：

• 给不同用途的实例打网络标签（network tags）；
• 防火墙规则绑定这些标签；
• 让业务实例和管理实例在策略上天生就被隔离。

这样你后面扩容，只要给新实例打同样的标签，规则自然继承，不需要你每次都手动“重新立法”。

3）常见端口：别只会开 0.0.0.0/0

你可能会问：那能不能直接开个 22 让自己随便 SSH？可以，但安全风险巨大。

更靠谱的是：

• 只允许堡垒机（或 VPN 网段）访问管理端口；
• 如果你没有堡垒机，用 IAP（Identity-Aware Proxy）方式进行受控访问（这是另一条安全道路，视你的架构而定）。

如果你做的是生产环境，“安全策略最少改两次”的原则建议你牢记：你最好第一次就别犯低级错误。

六、专有网络里实例怎么放：公网、私网、以及访问路径怎么设计

谷歌云赠金号 很多网络搭建卡住的点并不是你不会点按钮，而是你不清楚“访问路径”。你要访问它？它要访问外网？用户要怎么进来？数据库要怎么连？

1）应用实例：通常放私网子网

常见策略是：

• Web/业务实例：私网运行；
• 对外入口：使用负载均衡或其他入口服务，并把访问控制做好；
• 出网：通过 Cloud NAT；
• 管理：走堡垒机或受控通道。

2）数据库：更严格的策略

数据库实例建议：

• 放在更私密的子网（甚至是只允许业务子网访问的子网）；
• 防火墙只允许业务实例的来源 IP 或来源标签；
• 尽量不要开放到公网。

如果你只是临时验证，开放也不是完全不能。但当你把东西当成“生产网络”时，越早严起来越省后悔。

七、DNS 与解析：让服务发现不靠“猜”

很多团队的“网络问题”，其实是“解析问题”。你以为端口没通，其实你连的是错误的 IP；或者你以为 IP 不对，其实是域名解析到不该去的地方。

如果你在专有网络里使用内部域名，建议考虑：

• 内部 DNS（自建解析或使用 GCP 相关能力）；
• 记录（A/AAAA/CNAME）规划；
• 不同环境的域名隔离（dev/test/prod）。

别把所有环境用同一套 DNS 规则，否则你会遇到“测试环境突然影响生产”的经典剧情。剧情好看，但你不想当主角。

八、监控与日志：网络搭好只是开始，得能看见

网络的可用性要靠观测。你至少要知道：

• 防火墙命中（或未命中）了哪些规则；
• 实例的网络连通性如何；
• 是否有异常流量（比如某端口被扫描）；
• NAT 是否正常工作（出网失败时通常会伴随日志异常）。

建议你把关键路径的日志打通：比如入口服务的访问日志、实例的系统日志、以及 VPC 流量日志（如适用）。网络问题最怕的是“出事了你还不知道怎么出事的”。

九、常见踩坑清单：提前帮你躲开那些“为什么不通”

下面是我见过最多的网络坑，按出现概率排序（不是官方数据，但读者朋友表示“命中率很离谱”）。

1）子网 IP 段冲突

谷歌云赠金号 最经典的翻车。尤其当你未来要做 VPC Peering 或与本地网络互联，冲突会让你在迁移阶段非常痛苦。建议你一开始就规划全局 IP 段，不要“想到哪里就规划哪里”。

2）防火墙规则太宽或太窄

太宽：安全风险；太窄：服务连不上。

排查时你要记住：防火墙规则不仅看“你加了没”，还看“优先级/方向/目标标签”。很多“连不上”的原因是规则没匹配到目标实例。

3）路由没配对或误以为默认生效

尤其是你启用了自定义路由或接入了互连。你以为“默认就会走到正确目的地”，但现实是：路由表里没有匹配项或匹配项不符合预期。

4）实例没有公网 IP 却以为可以直接访问外网

这几乎是“每个团队至少中一次”的问题。没有公网 IP，你直接 curl 外网当然失败。你需要 Cloud NAT 或其他出网方案。

5）管理端口对不上：你开的是 22，但你的服务跑在 2222

这是我最喜欢吐槽的坑：防火墙开了 22，结果你连的却是 2222。网络没错，错的是你自己配置文件里端口写死了。

十、排查网络问题的实战流程：别先急，照步骤来

当你发现“连不上”，不要立刻开始狂改配置。你应该按顺序排：

1）先确认连通性是不是“完全不通”还是“部分不通”

例如：

• ping / traceroute 是否有反馈？
• TCP 端口是否能建立连接？
• DNS 是否能解析？

2）确认目标实例是否在正确的子网/区域

有些时候你改了策略，但实例根本不在你以为的地方。GCP 的资源位置（region/zone）可不是装饰品。

3）检查防火墙规则是否匹配到目标

重点看：目标标签、来源（source ranges）、协议与端口、方向（ingress/egress）。

4）检查路由与出网方式

如果是出网失败，看 Cloud NAT 是否配置了正确的子网与 IP 范围；如果是跨网络互通，查看路由表与互连设置。

5）最后才怀疑应用

网络排查经常能把锅“甩回去”：端口其实没放行，应用只是在努力地等待一个永远不会来的请求。

十一、一个“可参考的落地方案”（示例思路，不是唯一答案）

为了让你更有画面，我给一个典型、相对通用的方案结构。你可以按自己的业务调整。

示例：生产环境 VPC

• VPC：prod-vpc（自定义 VPC）
• Region：us-central1（单区域示例）
• 子网：
• prod-app-subnet（10.10.0.0/20）
• prod-mgmt-subnet（10.10.16.0/20）
• 实例：
• 业务实例：放入 prod-app-subnet，标记 tag=app-prod
• 堡垒机或管理通道实例：放入 prod-mgmt-subnet，标记 tag=mgmt-prod（如果你使用）
• 数据库：同样放在 app 或单独再分子网，标记 tag=db-prod
• 出网：
• 业务/数据库不配公网 IP
• 启用 Cloud NAT，覆盖 prod-app-subnet（以及需要出网的子网）
• 防火墙：
• 仅允许来自负载均衡/入口服务的 HTTP/HTTPS 到 app 实例（按 tag=app-prod）
• 仅允许来自堡垒机或 VPN 网段访问管理端口到 mgmt 或 app 管理接口
• 仅允许来自 app 实例（tag=app-prod）的流量访问 db 端口（tag=db-prod）

这个架构的优点是：你把“谁能访问谁”写得很明确。你会发现排错时不需要猜，因为每一步都可对应到具体规则与目标标签。

十二、收尾建议：把网络当产品，不要当临时配置

最后给你三个小建议，确保你搭完不是“能跑”，而是“跑得久还好维护”。

1）命名与文档要跟上

VPC 名字、子网名字、标签命名、规则描述都要规范。你未来看你自己写的规则，如果像看别人代码一样费劲，那就说明不够好。

2）规则尽量“可推导”

尽量让新实例复制现有模式就能继承规则。比如都打 tag=app-prod，防火墙就按 tag 统一管。你会省掉大量重复劳动。

3）先从最小可用开始，再逐步加能力

网络是会演进的。不要一上来就做所有高级互连、所有复杂路由、所有花哨策略。先把主干跑通，然后再增强隔离、增强观测、增强安全策略。

总之，“GCP实名号专有网络搭建”这事儿的核心不在于你会不会点按钮，而在于你能不能在一开始就把边界想清楚。想清楚了，你搭建会顺滑很多；想不清楚，后面排查会让你怀疑网络是否真的存在。

如果你愿意，我也可以根据你的实际情况（例如：单区域还是多区域、是否需要 VPN/专线、是否有私网访问需求、业务大概端口和访问路径）给你把子网规划、防火墙规则和出网方案做成一份更贴近你场景的“落地清单”。你只要告诉我你的目标架构轮廓就行，剩下的我来替你把坑提前填上。