Cloud Run a VPN local: configuración da saída directa de VPC

O túnel está activo, unha VM chega ao servidor local e o servizo de Cloud Run esgota o tempo no mesmo host. Ese é o punto de partida habitual desta tarefa, e o túnel raramente é o que falla. Unha revisión de Cloud Run non se sitúa na súa VPC por defecto, e cando o fai, usa os seus propios enderezos de orixe en lugar da subrede de VM que xa encamiñou. O runbook seguinte conecta o servizo, encamiña o seu rango de orixe real e despois demostra o camiño desde a revisión que atendeu a solicitude. Execúteo nesa orde, porque omitir o primeiro paso é a razón pola que tantos destes casos rematan nun cambio de VPN que non corrixe nada.

Conecte a revisión antes de depurar o túnel

Cloud Run admite saída directa de VPC, que coloca o tráfico do servizo nunha subrede da súa VPC sen un conector de Serverless VPC Access. Para un servizo existente, a actualización ten este aspecto:

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

Substitúa os marcadores de posición, revise que fai o despregamento co tráfico en vivo e elixa unha subrede na rexión do servizo con suficiente capacidade de enderezos e os permisos de rede correctos.

Elixa o modo de saída que coincida co destino

private-ranges-only envía os destinos que clasifica como privados a través da VPC. Non significa «calquera cousa accesible pola VPN», e esa fenda aparece cando o servizo local está nun rango que a configuración non clasifica así. Se o destino non está cuberto, all-traffic é o outro modo documentado, e envía todo a través da VPC, incluídas as dependencias públicas do servizo. Elixa con coñecemento e escriba a consecuencia no rexistro de cambios.

Un servizo que xa usa un conector require unha migración, non un interruptor, así que planifíquea en lugar de configurar ambos.

Encamiñe a orixe de Cloud Run, non unha orixe de VM

A saída directa de VPC asigna enderezos efémeros da subrede seleccionada, e o lado local debe devolver o tráfico a ese rango. Unha ruta de retorno ou unha autorización de firewall escrita para outra subrede de VM parecerá correcta no diagrama e fallará na práctica. Tome o CIDR da subrede da VPC e non da memoria, e despois confirme que a ACL criptográfica ou a táboa de rutas do dispositivo remoto o inclúe.

Con encamiñamento dinámico, verifique que anuncia realmente Cloud Router e que importa a VPC, incluída calquera política de anuncio personalizada. Unha ruta que existe na consola pero non está seleccionada para este destino é o mesmo que ningunha ruta.

Tres condicións que deben cumprirse todas

Un camiño funcional necesita todo o seguinte, e cada condición falla á súa maneira:

• Unha ruta na VPC cara ao prefixo local a través da conexión de Cloud VPN prevista.
• Unha ruta inversa en local para a subrede de Cloud Run.
• Un alcance de protección de firewall e IPsec que permita a orixe, o destino e o porto.

Unha ruta que falta adoita parecer un tempo de espera esgotado sen evidencia no lado remoto. Un problema de ruta inversa parece unha solicitude que chega e unha resposta que desaparece. Un problema de firewall ou de selector pode parecer un rexeitamento ou unha perda silenciosa, segundo o dispositivo. Determinar cal das tres ten reduce moito o seguinte comando.

Non inclúa un único enderezo temporal de Cloud Run na lista de permitidos. Use o rango da subrede e un deseño de autorización axeitado para a aplicación.

Probe a revisión que atendeu a solicitude

Inspeccione a configuración de rede despregada e a asignación de tráfico antes de probar, porque unha actualización pode crear unha revisión nova mentres as solicitudes aínda chegan a unha anterior. Despois realice a mesma operación que realiza a solicitude do usuario, desde esa revisión. Se o destino é un nome de host privado, comprobe a súa resolución nese ambiente e o enderezo que produciu, xa que a resposta do DNS corporativo do seu portátil non demostra nada sobre o espazo de nomes do servizo. Manteña a verificación do nome de host TLS e a autenticación propia da aplicación remota.

Espere os atrasos de conexión de inicio de Direct VPC documentados e dea ao cliente unha estratexia de dispoñibilidade ou reintento en lugar de diagnosticar cada inicio en frío como un túnel roto.

Reversión e que non fai isto

Para reverter, devolva a configuración de rede e de saída do servizo aos seus valores anteriores e confirme que a revisión anterior segue atendendo tráfico. Conserve o comando gcloud no rexistro de cambios, porque o reverso dun cambio parcial non é evidente seis semanas despois. Quitar a conexión de VPC devolve o servizo á súa ruta de saída anterior, que pode ser exactamente o que desexa durante un incidente.

Este deseño cobre as conexións que Cloud Run inicia e as súas respostas. Non dá á rede local un socket dirixible dentro do servizo, porque a exposición entrante é unha decisión de ingress.