Cloud SQL Auth Proxy 与直连 VPN 路由的对比
Auth Proxy 和直连 VPN 路由解决的是同一个问题的两个不同侧面。先比较连接器授权、端口和数据库登录。
从接入 VPN 的笔记本访问私有 Cloud SQL 实例，有两种合理做法。一种是通过已有的路由直接连接实例的私有地址；另一种是 Cloud SQL Auth Proxy，它在 loopback 上监听，并自行打开到 Cloud SQL 的连接。二者与其说是相互竞争的产品，不如说是对“谁持有凭据、谁持有路由”这个问题的两种不同回答。选错时的表现通常是一个看起来像网络错误的授权错误。
下面是我会摆到团队面前的那个对比，之后是真正决定选择的那几项检查。
通往同一个实例的两条路径
直连路径使用从你的网络进入项目 VPC 的 private-services-access 路由。客户端用 PostgreSQL 与实例的私有地址通信，连接能否存活取决于路由、firewall 规则和数据库凭据。
代理路径使用同一条路由，但增加了一个本地进程。代理用应用的 default credentials 向 Google API 认证，通过连接器打开到实例的连接，并暴露一个被客户端当作 PostgreSQL 的 loopback 端口。两跳变成三跳，中间那一跳承载 IAM 授权。VPN 路由仍然由你维护，代理从不把它视为这项检查的替代品。
每条路径实际授权的是什么
最重要的区别在于，每种方式能替你授权什么：
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
代理的 IAM 检查和数据库登录是两道彼此独立的门，通过其中一道并不会打开另一道。团队如果启用了代理就认为应用账号不再必要，会花掉半个下午处理与网络毫无关系的密码错误。
端口与路由，并排来看
代理需要出站 TCP 443 用于 API，以及 TCP 3307 用于实例连接，两者都在 Google 的 Auth Proxy 概览 中有说明。你的 VPN 路由覆盖的是后者；前者通常走常规路径出去。
直连则要求实例的 PostgreSQL 端口可通过私有路由到达，这是另一场 firewall 讨论。如果网络团队只允许客户端子网出站 443，代理无需改规则即可适用，而直连不行。这一个事实比任何架构偏好都更常决定选择。
两条路径都不要求实例拥有公网地址，也都不构成添加公网地址的理由。
代理帮不上忙的地方
代理修不好缺失的路由. 如果 private-services-access 路由不存在，或 VPN 没有承载它，连接器会失败，而本地监听者仍然坐在那里监听，这正是令人困惑的地方。
它也不保护应用与代理之间的那一段。在单台笔记本上那一段是 loopback，没有问题。如果你把监听者绑定到 wildcard 地址好让同事访问，你就造了一个没有认证的数据库网关，并把它叫作便利。让它留在 loopback 上，让同事去拿自己的凭据。
它也不会让 Private Service Connect 与 private services access 变得可以互换。PSC 实例需要自己的 DNS 安排，并且要用 --psc 调用而不是 --private-ip 形式。
先选择，然后无论哪条路径都做验证
如果你希望路径上有 IAM、使用短期凭据、并且不改动入站 firewall，就选代理。
如果受支持的客户端已经持有强数据库凭据，且网络团队愿意开放端口，就选直连。无论哪种，都要用真实查询而不是“连接成功”来验证：连上，对一张已知表执行一次读取，看看服务端对你的会话看到了什么。
VPN 重连之后，把过期凭据、缺失的私有路由和数据库登录被拒当成三种不同的故障。其中只有一种是网络问题，也只有一种应当最终导致修改 firewall 规则。