Cloud SQL Auth Proxy frente a una ruta VPN directa a la base de datos
El Auth Proxy y una ruta VPN directa resuelven mitades distintas del mismo problema. Compare primero la autorización del conector, los puertos y el inicio de sesión en la base de datos.
Hay dos formas sensatas de llegar a una instancia privada de Cloud SQL desde un portátil en la VPN. Una es una conexión directa a la dirección privada de la instancia por la ruta que ya tiene. La otra es el Cloud SQL Auth Proxy, que escucha en loopback y abre él mismo la conexión hacia Cloud SQL. No son tanto productos competidores como dos respuestas distintas a quién tiene la credencial y quién tiene la ruta. Una mala elección suele aparecer como un error de autorización que se lee como un error de red.
Esta es la comparación que pondría delante de un equipo, seguida de las comprobaciones que de verdad la deciden.
Dos caminos a la misma instancia
El camino directo usa la ruta private-services-access desde su red hacia la VPC del proyecto. Su cliente habla PostgreSQL con la dirección privada de la instancia, y la conexión vive o muere según el enrutamiento, las reglas de firewall y las credenciales de la base de datos.
El camino del proxy usa la misma ruta pero añade un proceso local. El proxy se autentica en la API de Google con las credenciales predeterminadas de la aplicación, abre una conexión a la instancia a través del conector y expone un puerto de loopback que su cliente trata como PostgreSQL. Dos saltos pasan a tres, y el del medio lleva la autorización IAM. La ruta VPN sigue siendo suya de mantener, y el proxy nunca la considera un sustituto de esa comprobación.
Qué autoriza realmente cada camino
La distinción que más importa es qué puede autorizar cada opción por usted:
| 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 |
La comprobación IAM del proxy y el inicio de sesión en la base de datos son puertas separadas, y pasar una no abre la otra. Un equipo que activa el proxy y da por hecho que la cuenta de la aplicación ya no hace falta pasará una tarde con fallos de contraseña que no tienen nada que ver con la red.
Puertos y rutas, lado a lado
El proxy necesita TCP 443 de salida para la API y TCP 3307 para la conexión a la instancia, ambos descritos en la descripción general de Auth Proxy. Su ruta VPN cubre el segundo; el primero normalmente sale por el camino habitual.
Una conexión directa necesita que el puerto PostgreSQL de la instancia sea alcanzable por la ruta privada, que es otra conversación de firewall. Si su equipo de red solo permite 443 de salida desde las subredes de clientes, el proxy encaja sin cambiar ninguna regla y el camino directo no. Ese único hecho decide la elección más a menudo que cualquier preferencia arquitectónica.
Ninguno de los dos caminos exige que la instancia tenga una dirección pública, y ninguno justifica añadir una.
Donde el proxy no ayuda
El proxy no arregla una ruta que falta. Si la ruta private-services-access no existe, o la VPN no la transporta, el conector falla mientras el listener local sigue ahí escuchando, y esa es la parte confusa.
Tampoco protege el tramo entre su aplicación y el proxy. En un portátil ese tramo es loopback y está bien. Si ata el listener a una dirección wildcard para que un compañero llegue a él, ha construido una pasarela de base de datos sin autenticación y la ha llamado comodidad. Manténgalo en loopback y deje que el compañero obtenga su propia credencial.
Y no hace intercambiables Private Service Connect y private services access. Una instancia PSC necesita su propia disposición de DNS y la invocación --psc en lugar de la forma --private-ip.
Elegir y luego verificar de cualquier manera
Elija el proxy cuando quiera IAM en el camino, credenciales de corta duración y ningún cambio de firewall de entrada.
Elija la ruta directa cuando un cliente compatible ya tenga credenciales sólidas de base de datos y el equipo de red esté cómodo abriendo el puerto. En cualquier caso, verifique con una consulta real en lugar de con una conexión correcta: conéctese, ejecute una lectura contra una tabla conocida y compruebe qué ve el servidor de su sesión.
Después de reconectar la VPN, trate una credencial caducada, una ruta privada que falta y un rechazo de inicio de sesión en la base de datos como tres fallos distintos. Solo uno es un problema de red, y solo uno debería llevar alguna vez a cambiar una regla de firewall.