Cloud Run a VPN local: configuración de salida directa de VPC

El túnel está activo, una VM llega al servidor local y el servicio de Cloud Run agota el tiempo de espera en el mismo host. Ese es el punto de partida normal de esta tarea, y el túnel rara vez es lo que falla. Una revisión de Cloud Run no se ubica en su VPC de forma predeterminada, y cuando lo hace, usa sus propias direcciones de origen en lugar de la subred de VM que ya enrutó. El runbook siguiente conecta el servicio, enruta su rango de origen real y luego demuestra la ruta desde la revisión que atendió la solicitud. Ejecútelo en ese orden, porque omitir el primer paso es la razón por la que tantos de estos casos terminan en un cambio de VPN que no corrige nada.

Conecte la revisión antes de depurar el túnel

Cloud Run admite salida directa de VPC, que coloca el tráfico del servicio en una subred de su VPC sin un conector de Serverless VPC Access. Para un servicio existente, la actualización tiene este aspecto:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Sustituya los marcadores de posición, revise qué hace el despliegue con el tráfico en vivo y elija una subred en la región del servicio con suficiente capacidad de direcciones y los permisos de red correctos.

Elija el modo de salida que coincida con el destino

private-ranges-only envía los destinos que clasifica como privados a través de la VPC. No significa «cualquier cosa accesible por la VPN», y esa brecha aparece cuando el servicio local está en un rango que la configuración no clasifica así. Si el destino no está cubierto, all-traffic es el otro modo documentado, y envía todo a través de la VPC, incluidas las dependencias públicas del servicio. Elija a conciencia y escriba la consecuencia en el registro de cambios.

Un servicio que ya usa un conector requiere una migración, no un interruptor, así que planifíquela en lugar de configurar ambos.

Enrute el origen de Cloud Run, no un origen de VM

La salida directa de VPC asigna direcciones efímeras de la subred seleccionada, y el lado local debe devolver el tráfico a ese rango. Una ruta de retorno o una autorización de firewall escrita para otra subred de VM parecerá correcta en el diagrama y fallará en la práctica. Tome el CIDR de la subred de la VPC y no de la memoria, y luego confirme que la ACL criptográfica o la tabla de rutas del dispositivo remoto lo incluye.

Con enrutamiento dinámico, verifique qué anuncia realmente Cloud Router y qué importa la VPC, incluida cualquier política de anuncio personalizada. Una ruta que existe en la consola pero no está seleccionada para este destino es lo mismo que ninguna ruta.

Tres condiciones que deben cumplirse todas

Una ruta funcional necesita todo lo siguiente, y cada condición falla a su manera:

• Una ruta en la VPC hacia el prefijo local a través de la conexión de Cloud VPN prevista.
• Una ruta inversa en local para la subred de Cloud Run.
• Un alcance de protección de firewall e IPsec que permita el origen, el destino y el puerto.

Una ruta faltante suele parecer un tiempo de espera agotado sin evidencia en el lado remoto. Un problema de ruta inversa parece una solicitud que llega y una respuesta que desaparece. Un problema de firewall o de selector puede parecer un rechazo o una pérdida silenciosa, según el dispositivo. Determinar cuál de los tres tiene reduce mucho el siguiente comando.

No incluya una sola dirección temporal de Cloud Run en la lista de permitidos. Use el rango de la subred y un diseño de autorización adecuado para la aplicación.

Pruebe la revisión que atendió la solicitud

Inspeccione la configuración de red desplegada y la asignación de tráfico antes de probar, porque una actualización puede crear una revisión nueva mientras las solicitudes aún llegan a una anterior. Luego realice la misma operación que realiza la solicitud del usuario, desde esa revisión. Si el destino es un nombre de host privado, compruebe su resolución en ese entorno y la dirección que produjo, ya que la respuesta del DNS corporativo de su portátil no demuestra nada sobre el espacio de nombres del servicio. Mantenga la verificación del nombre de host TLS y la autenticación propia de la aplicación remota.

Espere los retrasos de conexión de inicio de Direct VPC documentados y dé al cliente una estrategia de disponibilidad o reintento en lugar de diagnosticar cada inicio en frío como un túnel roto.

Reversión y qué no hace esto

Para revertir, devuelva la configuración de red y de salida del servicio a sus valores anteriores y confirme que la revisión anterior sigue atendiendo tráfico. Conserve el comando gcloud en el registro de cambios, porque el reverso de un cambio parcial no es evidente seis semanas después. Quitar la conexión de VPC devuelve el servicio a su ruta de salida anterior, que puede ser exactamente lo que desea durante un incidente.

Este diseño cubre las conexiones que Cloud Run inicia y sus respuestas. No da a la red local un socket direccionable dentro del servicio, porque la exposición entrante es una decisión de ingress.