App Engine pode chegar á súa base de datos VPN: que debe coincidir

A afirmación de que App Engine Standard non pode chegar a unha base de datos privada a través de Cloud VPN é un resto dunha xeración anterior da plataforma. As instancias Standard non reciben un enderezo nativo de VPC como algúns outros contornos de execución, pero poden enviar saída a través dun conector de Serverless VPC Access que vive na súa rede. Unha vez existe ese camiño, Cloud VPN e a devasa remota ven o tráfico do conector como calquera outra orixe. O que falla raramente é a capacidade en si. É unha das tres configuracións que nunca se aliñaron.

De onde viña a resposta antiga

Antes de que existisen os conectores, a resposta práctica era realmente que Standard só podía falar con puntos finais públicos, e os equipos pasaban a unha VM de proxy ou a outro contorno de execución para evitalo. A plataforma cambiou e o folclore non. Moitos consellos en liña aínda reflicten a época na que non había ningunha opción de saída.

A corrección é máis estreita do que soa. Standard pode chegar á rede privada, pero só mediante unha integración de saída compatible, e só para os destinos que esa integración captura realmente.

Escolla primeiro a ruta de saída

Un conector asociado ao servizo é o que pon o seu tráfico dentro da VPC. A documentación do conector enumera o requisito rexional e a configuración de saída; o conector debe existir na rexión do servizo e ser utilizable pola identidade que despregar.

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

private-ranges-only envía os destinos privados á VPC e deixa todo o demais na ruta normal de internet, que adoita ser o que necesita unha conexión de base de datos. all-traffic empuxa o tráfico saínte a través da VPC de forma ampla, así que as chamadas normais a internet tamén herdan a postura de NAT e devasa da VPC.

Editar o ficheiro localmente non cambia nada ata que despregue. Unha versión en execución conserva a configuración coa que se creou.

O enderezo de orixe é o conector, non o seu portátil

Aquí vai a maior parte do tempo de depuración. A pasarela VPN remota e a devasa da base de datos deben admitir o rango asignado ao conector dentro da VPC, non o enderezo da súa oficina nin o enderezo de saída pública do servizo. Busque ese rango na consola antes de escribir unha soa regra.

Hai dous lugares máis que deben coincidir. A táboa de rutas da VPC necesita unha ruta cara á rede remota da base de datos, e o lado remoto necesita unha ruta de retorno para o rango do conector. Se o túnel usa selectores de tráfico, confirme que o rango do conector queda dentro do ámbito negociado. Unha ruta que só existe na dirección de remoto a local é un fallo habitual, e deixa pasar pings sen completar nunca un handshake TCP.

Un túnel que só admite unha subrede de VM descartará os paquetes do conector sen unha mensaxe de erro útil, e por iso o tempo de espera da base de datos parece un problema de credenciais.

O DNS viaxa por un camiño diferente

Un nome de host de base de datos privada debe resolverse dentro da rede á que chega o conector, mediante o emparellamento de Cloud DNS ou unha zona de reenvío que a VPC poida usar. Resolvelo na súa estación de traballo non demostra nada sobre o servizo despregado, porque o seu portátil non usa ese resolutor.

Se o nome se resolve nun enderezo público desde dentro da VPC, está a piques de depurar a devasa equivocada.

URL Fetch non usa o conector

A configuración de saída cobre os sockets saíntes normais do contorno de execución, e o servizo herdado URL Fetch non forma parte dese camiño. Unha solicitude emitida mediante urlfetch ignora o conector diga o que diga a configuración. Cando a chamada que falla está dentro dunha biblioteca antiga que aínda usa URL Fetch, a solución é mover esa chamada ao cliente HTTP estándar.

Para un controlador de base de datos isto raramente é o problema, pero é a razón clásica pola que un punto final funciona e outro non desde o mesmo servizo.

Verifique cunha consulta estreita

Desprege e logo execute unha única operación de base de datos permitida desde a versión despregada mentres observa o lado remoto. O enderezo de orixe que rexistre a base de datos ou a pasarela VPN debería ser o do conector. Se non o é, a solicitude nunca entrou na VPC e ningunha cantidade de configuración do túnel o arranxará. Compárea co rango que buscou na consola; unha discrepancia adoita significar que un segundo conector está a servir a versión.

Unha consulta correcta desde unha VM dentro da VPC establece que a ruta existe. Non establece que o servizo a elixise.