O App Engine pode chegar à sua base de dados VPN: o que tem de coincidir

A afirmação de que o App Engine Standard não consegue chegar a uma base de dados privada através do Cloud VPN é um resquício de uma geração anterior da plataforma. As instâncias Standard não recebem um endereço nativo de VPC como alguns outros ambientes de execução, mas podem enviar egress através de um conector Serverless VPC Access que vive na sua rede. Assim que esse caminho existe, o Cloud VPN e a firewall remota veem o tráfego do conector como qualquer outra origem. O que falha raramente é a própria capacidade. É uma de três definições que nunca foram alinhadas.

De onde veio a resposta antiga

Antes de existirem conectores, a resposta prática era mesmo que o Standard só podia falar com pontos finais públicos, e as equipas passavam para uma VM de proxy ou outro ambiente de execução para contornar isso. A plataforma mudou, o folclore não. Muitos conselhos online ainda refletem a época em que não havia qualquer opção de egress.

A correção é mais estreita do que parece. O Standard pode chegar à rede privada, mas apenas através de uma integração de egress suportada, e apenas para os destinos que essa integração captura realmente.

Escolha primeiro o caminho de egress

É um conector ligado ao serviço que coloca o seu tráfego na VPC. A documentação do conector lista o pré-requisito regional e as definições de egress; o conector tem de existir na região do serviço e ser utilizável pela identidade que implementa.

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

private-ranges-only envia destinos privados para a VPC e deixa tudo o resto no caminho normal da internet, que é normalmente o que uma ligação a uma base de dados precisa. all-traffic empurra o tráfego de saída pela VPC de forma ampla, pelo que as chamadas normais à internet também herdam a postura de NAT e firewall da VPC.

Editar o ficheiro localmente não muda nada até implementar. Uma versão em execução mantém a configuração com que foi criada.

O endereço de origem é o conector, não o seu portátil

É aqui que passa a maior parte do tempo de depuração. O gateway VPN remoto e a firewall da base de dados têm de admitir o intervalo atribuído ao conector dentro da VPC, não o endereço do seu escritório nem o endereço de egress público do serviço. Procure esse intervalo na consola antes de escrever uma única regra.

Mais dois locais têm de concordar. A tabela de rotas da VPC precisa de uma rota para a rede remota da base de dados, e o lado remoto precisa de uma rota de retorno para o intervalo do conector. Se o túnel usar seletores de tráfego, confirme que o intervalo do conector está dentro do âmbito negociado. Uma rota que só existe na direção remoto-para-local é uma falha comum, e deixa passar pings sem nunca concluir um handshake TCP.

Um túnel que só admite uma sub-rede de VM descarta os pacotes do conector sem uma mensagem de erro útil, e é por isso que o tempo limite da base de dados parece um problema de credenciais.

O DNS viaja por um caminho diferente

Um nome de anfitrião de base de dados privada tem de ser resolvido dentro da rede que o conector alcança, através de peering do Cloud DNS ou de uma zona de encaminhamento que a VPC possa usar. Resolvê-lo na sua estação de trabalho não prova nada sobre o serviço implementado, porque o seu portátil não usa esse resolvedor.

Se o nome se resolver num endereço público a partir de dentro da VPC, está prestes a depurar a firewall errada.

O URL Fetch não usa o conector

A definição de egress cobre os sockets de saída normais do ambiente de execução, e o serviço legado URL Fetch não faz parte desse caminho. Um pedido emitido via urlfetch ignora o conector, diga o que disser a configuração. Quando a chamada que falha está numa biblioteca mais antiga que ainda usa URL Fetch, a correção é mover essa chamada para o cliente HTTP padrão.

Para um controlador de base de dados isto raramente é o problema, mas é a razão clássica pela qual um ponto final funciona e outro não a partir do mesmo serviço.

Verifique com uma consulta estreita

Implemente e depois execute uma única operação de base de dados permitida a partir da versão implementada, observando o lado remoto. O endereço de origem registado pela base de dados ou pelo gateway VPN deve ser o do conector. Se não for, o pedido nunca entrou na VPC e nenhuma configuração de túnel o corrige. Compare-o com o intervalo que procurou na consola; uma discrepância significa normalmente que um segundo conector está a servir a versão.

Uma consulta bem-sucedida a partir de uma VM dentro da VPC estabelece que a rota existe. Não estabelece que o serviço a escolheu.