开发者远程访问 Google Cloud VPC：选对路径

开发者需要的可能是一个 SSH 会话、一个数据库端口，或者对十几个私有服务的广泛访问，而这些请求看起来都是同一个问题。其实不是。目标、协议和涉及的身份决定了哪条 Google Cloud 访问路径合适，默认选择最宽的那条会带来你本不必承担的工作。

写清目标与协议

列出工作真正需要的私有地址、端口和协议，然后标出哪些身份必须单独认证。数据库端口和私有 DNS 区域是不同需求，而 UDP 服务则完全排除下面某个选项。书面清单还能显示你没有授予什么。审查人员问的正是这部分。

在打开监听器之前就做这件事。清单之后会成为验收测试，也是区分窄隧道与碰巧能用的宽隧道的唯一可靠办法。

少量 TCP 服务用 IAP

Identity-Aware Proxy 的 TCP 转发可以在不把服务暴露到互联网的情况下，为符合条件的 VM 资源提供经过认证的隧道。日常写法是gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a，单个端口可以用gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a在本地转发。

三件事必须对齐：调用方需要 IAP 隧道访问者角色，防火墙必须允许 IAP 源地址范围，目标必须能在实例上访问到。创建隧道的授权不是数据库凭据、SSH 登录或 RDP 会话，所以把应用认证留在它该在的地方。

IAP 的 TCP 转发不是三层 VPN。它把 TCP 送到选定目标，而不是任意 IP 流量或 UDP；当应用需要跨多个服务使用私有 DNS 时，它并不合适。

更广可达性就用远程访问 VPN

当需要多个目标、协议或私有 DNS 区域时，更好的形态是在 VM 或受支持设备上显式管理的远程访问 VPN。这种部署与 Google 托管的 Cloud VPN 相互独立：客户端身份注册、软件更新、客户端路由和 VPC 回程路由都由你负责。

要规划整份清单，而不只是公网监听器。包括隧道池、回到它的 VPC 路由、转发控制、DNS 解析和按服务划分的访问策略。连得上却解析不了内部名称的 VPN，和根本连不上的 VPN 一样，会让开发者的工作流彻底失败。

Cloud VPN 是站点网关，不是笔记本配置

Google Cloud VPN 通过 IPsec 连接对端网关，其常见问题把这种站点到站点的角色与客户端到网关的访问区分开来。创建隧道并不会生成员工在笔记本上导入的配置。当有人索要 Cloud VPN 配置时，这个区别很重要。答案其实是另一个产品。

网关擅长的是给办公室网络后面的机器一条进入 VPC 的路由。它不会认证每个员工，也不授予应用权限，所以那些策略留在网络层和应用层，可以按身份执行。

验证并记录

先测试最窄的目标，再测试需要 DNS 的目标，然后测试一个必须保持拒绝的目标。每项测试都要用生产中将使用该路径的同一个客户端来跑，因为从管理员工作站测得成功，几乎说明不了开发者那台处于不同网络的笔记本的情况。

记录所选模型、它覆盖的目标、它认证的身份，以及路径不可用时的失败行为。正是这份记录，能防止下一次请求悄悄放宽隧道，而不是在已记录的设计中增加一个目标。