谷歌云子账号管理谷歌云 GCP 账号内网穿透方案

谷歌云GCP / 2026-04-21 20:30:06

谷歌云 GCP 账号内网穿透方案：不求人、不翻墙、不买VPS的硬核解法

你有没有过这种深夜崩溃时刻：在GCP上搭了个测试用的Flask API，本地curl不通；想连进公司VPC里那台没公网IP的PostgreSQL，ssh直接报错“Connection refused”；甚至只是想把Jupyter Notebook临时分享给同事，结果发现防火墙规则写了八遍，still no access……别慌——这不是你的锅，是GCP故意把“内网穿透”藏在了云厂商最深的抽屉里。

谷歌云不像某些平台，给你一个“一键开通内网穿透”的按钮（当然，它也不屑于这么干）。它信奉“最小权限+显式声明”，所以穿透不是默认能力，而是你亲手组装的乐高：IAM权限、防火墙、服务代理、路由策略，缺一块就卡死。本文不讲虚的，只掏干货——四种真正能在生产环境跑通、不依赖第三方、不绕过GCP原生安全模型的方案，全部基于你已有GCP账号实测，连gcloud命令都帮你敲好换行了。

方案一：Cloud IAP TCP 转发——最优雅的“白名单隧道”

这是GCP官方钦定的内网穿透正统写法，适合需要严格访问控制的场景（比如只允许特定Google账户访问某台跳板机）。原理简单粗暴：IAP不暴露IP，只代理TCP流量，所有连接先经Google全球边缘节点鉴权，再透传到目标实例的指定端口。

前提条件：目标实例必须启用OS Login（enable-oslogin=true），且绑定的服务账号需有roles/iap.tunnelResourceAccessor权限；用户Google账号要加入项目级IAP授权组。

三步走：

开防火墙：允许来自35.235.240.0/20（IAP代理IP段）的TCP入站（端口随便，比如22）；
配IAP：在Cloud Console → Security → Identity-Aware Proxy → TCP forwarding → 开关拨到ON；
本地终端执行：
gcloud compute start-iap-tunnel INSTANCE_NAME 22 \ --local-host-port=localhost:2222 \ --zone=us-central1-a

敲完回车，本地ssh -p 2222 user@localhost即连通。注意：IAP不支持UDP，HTTP类服务得套一层ssh -D SOCKS代理——但别急，下文有更直球的方案。

方案二：Cloud NAT + 静态外部IP + 端口转发——给私有实例“借壳上市”

如果你的实例真·没有公网IP（比如VPC子网关关闭了自动分配），又不想动IAP那套身份体系，这招就是物理层面的“曲线救国”。核心思路：让NAT网关扛起出口流量，再通过静态外部IP+防火墙规则，把入站请求反向导向私有实例。

关键操作链：

创建Cloud NAT（关联子网+指定区域），并勾选“Enable logging”——不然排错时你会怀疑人生；
申请一个静态外部IP（必须是EXTERNAL类型，GLOBAL不行！）；
写防火墙规则：
目标：该静态IP
源IP：0.0.0.0/0（或限定CIDR）
协议端口：tcp:8080
目标标签：web-server（记得给实例打上这个标签！）
在实例内部启动服务时，监听0.0.0.0:8080（别只绑127.0.0.1！）

搞定后curl http://YOUR_STATIC_IP:8080直达私有实例。缺点？端口不能动态变——想同时透80和443？得配两个静态IP。但胜在稳定、无额外延迟、兼容任意协议。

方案三：全球TCP/SSL负载均衡——专治“我要对外提供HTTPS服务”

当你的内网服务需要被互联网用户稳定访问（比如前端Vue应用连后端API），Load Balancing才是GCP的王炸。它不是单纯转发，而是带健康检查、自动扩缩、DDoS防护的工业级入口。

部署逻辑链（别跳步）：

创建Instance Group（哪怕只有一台实例，也得包进去）；
配Health Check：路径设为/healthz，端口填服务实际端口（如8000）；
建Backend Service，关联实例组+健康检查；
建Target TCP Proxy（或Target SSL Proxy）；
最后挂Global Forwarding Rule，绑定静态全球IP。

全程用Console点十次不如一条命令快：
gcloud compute backend-services create my-api-backend \ --global \ --health-checks=my-health-check \ --protocol=HTTP
（注意：HTTP协议LB可自动处理SSL终止，比纯TCP省心）

等状态变HEALTHY（通常3-5分钟），你的服务就拥有了https://[global-ip]/api这个体面门面。

谷歌云子账号管理方案四：自建SSH隧道——极简主义者的最后一根烟

当以上方案都被政治审批卡住（比如IAP需Security团队签字，LB预算超限），还有个祖传手艺：用一台带公网IP的GCE实例做跳板，本地SSH反向隧道直插内网。

操作口诀：“本地监听，远程绑定，静默守护”：

在跳板机（public-instance）上执行：
sudo sysctl -w net.ipv4.ip_forward=1（开启IP转发）
在目标内网实例（private-instance）上执行：
ssh -R 0.0.0.0:8080:localhost:3000 \ -o ServerAliveInterval=60 \ -o ExitOnForwardFailure=yes \ user@public-instance-external-ip
在跳板机防火墙放行8080端口（仅限可信来源IP）

之后访问跳板机IP:8080，流量自动钻进内网实例的3000端口。优点：零配置学习成本；缺点：SSH会话断则隧道崩——加autossh保活，一行命令解决：
autossh -M 0 -N -R 0.0.0.0:8080:localhost:3000 user@public-ip

避坑指南：那些文档里不会写的血泪教训

防火墙优先级陷阱：GCP防火墙规则按“目标标签→网络→IP范围”三级匹配，但拒绝规则永远高于允许规则。删掉项目默认的default-deny-all？千万别！改用精确的allow-iap规则覆盖它。
IAP的SSH密钥同步：OS Login启用后，本地ssh-keygen生成的密钥不会自动上传。必须运行gcloud compute os-login ssh-keys add --key-file ~/.ssh/id_rsa.pub，否则IAP隧道连不上。
NAT的“出站即失联”：开了NAT后，实例仍无法响应入站请求！因为NAT只管出站。入站必须靠静态IP+防火墙，二者是平行关系，不是父子关系。
LB的证书时效：用Managed SSL证书时，GCP会自动续期，但首次部署需45分钟。别盯着Console刷新——去gcloud compute ssl-certificates list看状态更准。

结语：穿透的本质，是信任的翻译器

所谓内网穿透，在GCP语境下，从来不是技术难题，而是安全哲学的落地实践。IAP翻译的是“你是谁”，NAT翻译的是“你能去哪儿”，Load Balancing翻译的是“你怎么被访问”，而SSH隧道翻译的是“我们之间有没有第三个人”。选哪个方案，不取决于多酷炫，而取决于你的组织里——谁说了算，谁担责，以及凌晨三点报警电话打给谁。

最后送一句GCP老司机私藏口诀：
“先查IAM权限，再看防火墙日志，最后抓包看SYN是否到达实例网卡。”
——别信文档，信gcloud compute firewall-rules list --format="table(name, direction, sourceRanges, allowed[].map().firewallAllowed())"输出的真实世界。