Cloud Run para VPN local: configurar a saída direta de VPC

Um túnel Cloud VPN não coloca o Cloud Run na rede. Ligue o serviço à sub-rede correta, encaminhe o intervalo de origem e depois teste essa revisão.

O túnel está ativo, uma VM chega ao servidor local e o serviço Cloud Run expira no mesmo host. Esse é o ponto de partida normal desta tarefa, e o túnel raramente é o que está errado. Uma revisão do Cloud Run não fica na sua VPC por padrão, e quando fica, usa os próprios endereços de origem em vez da sub-rede de VM que você já encaminhou. O runbook abaixo liga o serviço, encaminha o intervalo de origem real e depois prova o caminho a partir da revisão que atendeu a solicitação. Execute-o nessa ordem, porque pular a primeira etapa é a razão pela qual tantos desses casos terminam numa mudança de VPN que não corrige nada.

Ligue a revisão antes de depurar o túnel

O Cloud Run suporta saída direta de VPC, que coloca o tráfego do serviço numa sub-rede da sua VPC sem um conector do Serverless VPC Access. Para um serviço existente, a atualização tem este aspecto:

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

Substitua os marcadores de posição, reveja o que a implantação faz com o tráfego em tempo real e escolha uma sub-rede na região do serviço com capacidade de endereços suficiente e as permissões de rede corretas.

Escolha o modo de saída que corresponde ao destino

private-ranges-only envia os destinos que classifica como privados através da VPC. Isso não significa «tudo o que é alcançável pela VPN», e essa lacuna aparece quando o serviço local está num intervalo que a configuração não classifica assim. Se o destino não estiver coberto, all-traffic é o outro modo documentado, e envia tudo através da VPC, incluindo as dependências públicas do serviço. Escolha deliberadamente e escreva a consequência no registro de alterações.

Um serviço que já usa um conector requer uma migração, não um interruptor, por isso planeje-a em vez de configurar ambos.

Encaminhe a origem do Cloud Run, não uma origem de VM

A saída direta de VPC atribui endereços efêmeros da sub-rede selecionada, e o lado local tem de devolver o tráfego para esse intervalo. Uma rota de retorno ou uma autorização de firewall escrita para outra sub-rede de VM parecerá correta no diagrama e falhará na prática. Retire o CIDR da sub-rede da VPC e não da memória, e depois confirme que a ACL criptográfica ou a tabela de rotas do dispositivo remoto o inclui.

Com encaminhamento dinâmico, verifique o que o Cloud Router anuncia realmente e o que a VPC importa, incluindo qualquer política de anúncio personalizada. Uma rota que existe no console mas não está selecionada para este destino é o mesmo que nenhuma rota.

Três condições que têm de se verificar todas

Um caminho funcional precisa de tudo o seguinte, e cada condição falha à sua maneira:

  • Uma rota na VPC para o prefixo local através da conexão Cloud VPN prevista.
  • Uma rota inversa no local para a sub-rede do Cloud Run.
  • Um escopo de proteção de firewall e IPsec que permita a origem, o destino e a porta.

Uma rota em falta parece normalmente um tempo de espera esgotado sem evidência do lado remoto. Um problema de rota inversa parece uma solicitação que chega e uma resposta que desaparece. Um problema de firewall ou de seletor pode parecer uma recusa ou uma queda silenciosa, dependendo do dispositivo. Determinar qual dos três você tem reduz muito o próximo comando.

Não coloque um único endereço temporário do Cloud Run na lista de permitidos. Use o intervalo da sub-rede e um desenho de autorização adequado à aplicação.

Teste a revisão que atendeu a solicitação

Inspecione as configurações de rede implementadas e a distribuição do tráfego antes de testar, porque uma atualização pode criar uma nova revisão enquanto as solicitações ainda chegam a uma mais antiga. Depois execute a mesma operação que a solicitação do usuário executa, a partir dessa revisão. Se o destino for um nome de host privado, verifique a resolução nesse ambiente e o endereço produzido, porque a resposta do DNS corporativo do seu notebook não prova nada sobre o espaço de nomes do serviço. Mantenha a verificação do nome de host TLS e a autenticação própria da aplicação remota.

Espere os atrasos de conexão na inicialização do Direct VPC documentados, e dê ao cliente uma estratégia de prontidão ou nova tentativa em vez de diagnosticar cada inicialização a frio como um túnel quebrado.

Reversão e o que isto não faz

Para reverter, reponha as configurações de rede e de saída do serviço nos valores anteriores e confirme que a revisão anterior continua a servir tráfego. Guarde o comando gcloud no registro de alterações, porque o inverso de uma alteração parcial não é óbvio seis semanas depois. Remover a conexão com a VPC devolve o serviço ao caminho de saída anterior, o que pode ser exatamente o que você quer durante um incidente.

Este desenho cobre as conexões que o Cloud Run inicia e as respetivas respostas. Não dá à rede local um socket endereçável dentro do serviço, porque a exposição para dentro é uma decisão de ingress.

Artigos relacionados