App Engine puede llegar a su base de datos VPN: qué debe coincidir

La afirmación de que App Engine Standard no puede llegar a una base de datos privada a través de Cloud VPN es un residuo de una generación anterior de la plataforma. Las instancias Standard no reciben una dirección nativa de VPC como algunos otros entornos de ejecución, pero pueden enviar salida a través de un conector de Serverless VPC Access que vive en su red. Una vez existe ese camino, Cloud VPN y el cortafuegos remoto ven el tráfico del conector como cualquier otra fuente. Lo que falla rara vez es la capacidad en sí. Es una de las tres configuraciones que nunca se alinearon.

De dónde venía la respuesta antigua

Antes de que existieran los conectores, la respuesta práctica era realmente que Standard solo podía hablar con puntos finales públicos, y los equipos se pasaban a una VM de proxy o a otro entorno de ejecución para evitarlo. La plataforma cambió y el folclore no. Muchos consejos en línea todavía reflejan la época en la que no había ninguna opción de salida.

La corrección es más estrecha de lo que suena. Standard puede llegar a la red privada, pero solo mediante una integración de salida compatible, y solo para los destinos que esa integración captura realmente.

Elija primero la ruta de salida

Un conector asociado al servicio es lo que pone su tráfico dentro de la VPC. La documentación del conector enumera el requisito regional y la configuración de salida; el conector debe existir en la región del servicio y ser utilizable por la identidad que despliega.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only envía los destinos privados a la VPC y deja todo lo demás en la ruta normal de internet, que suele ser lo que necesita una conexión de base de datos. all-traffic empuja el tráfico saliente a través de la VPC de forma amplia, así que las llamadas normales a internet también heredan la postura de NAT y cortafuegos de la VPC.

Editar el archivo localmente no cambia nada hasta que despliegue. Una versión en ejecución conserva la configuración con la que se creó.

La dirección de origen es el conector, no su portátil

Aquí se va la mayor parte del tiempo de depuración. La puerta de enlace VPN remota y el cortafuegos de la base de datos deben admitir el rango asignado al conector dentro de la VPC, no la dirección de su oficina ni la dirección de salida pública del servicio. Busque ese rango en la consola antes de escribir una sola regla.

Hay dos lugares más que deben coincidir. La tabla de rutas de la VPC necesita una ruta hacia la red remota de la base de datos, y el lado remoto necesita una ruta de retorno para el rango del conector. Si el túnel usa selectores de tráfico, confirme que el rango del conector queda dentro del ámbito negociado. Una ruta que solo existe en la dirección de remoto a local es un fallo habitual, y deja pasar pings sin completar nunca un handshake TCP.

Un túnel que solo admite una subred de VM descartará los paquetes del conector sin un mensaje de error útil, y por eso el tiempo de espera de la base de datos parece un problema de credenciales.

El DNS viaja por un camino diferente

Un nombre de host de base de datos privada debe resolverse dentro de la red a la que llega el conector, mediante el emparejamiento de Cloud DNS o una zona de reenvío que la VPC pueda usar. Resolverlo en su estación de trabajo no demuestra nada sobre el servicio desplegado, porque su portátil no usa ese resolutor.

Si el nombre se resuelve a una dirección pública desde dentro de la VPC, está a punto de depurar el cortafuegos equivocado.

URL Fetch no usa el conector

La configuración de salida cubre los sockets salientes normales del entorno de ejecución, y el servicio heredado URL Fetch no forma parte de ese camino. Una solicitud emitida mediante urlfetch ignora el conector diga lo que diga la configuración. Cuando la llamada que falla está dentro de una biblioteca antigua que aún usa URL Fetch, la solución es mover esa llamada al cliente HTTP estándar.

Para un controlador de base de datos esto rara vez es el problema, pero es la razón clásica por la que un punto final funciona y otro no desde el mismo servicio.

Verifique con una consulta estrecha

Despliegue y luego ejecute una única operación de base de datos permitida desde la versión desplegada mientras observa el lado remoto. La dirección de origen que registre la base de datos o la puerta de enlace VPN debería ser la del conector. Si no lo es, la solicitud nunca entró en la VPC y ninguna cantidad de configuración del túnel lo arreglará. Compárela con el rango que buscó en la consola; una discrepancia suele significar que un segundo conector está sirviendo la versión.

Una consulta correcta desde una VM dentro de la VPC establece que la ruta existe. No establece que el servicio la haya elegido.