App Engine pot arribar a la vostra base de dades VPN: què ha de coincidir

L'afirmació que App Engine Standard no pot arribar a una base de dades privada a través de Cloud VPN és un romanent d'una generació anterior de la plataforma. Les instàncies Standard no reben una adreça nativa de VPC com alguns altres entorns d'execució, però poden enviar trànsit de sortida a través d'un connector de Serverless VPC Access que viu a la vostra xarxa. Un cop existeix aquest camí, Cloud VPN i el tallafoc remot veuen el trànsit del connector com qualsevol altra font. El que falla poques vegades és la capacitat en si. És una de les tres configuracions que mai es van alinear.

D'on venia la resposta antiga

Abans que existissin els connectors, la resposta pràctica era realment que Standard només podia parlar amb punts finals públics, i els equips es passaven a una VM de proxy o a un altre entorn d'execució per evitar-ho. La plataforma va canviar i el folklore no. Molts consells en línia encara reflecteixen l'època en què no hi havia cap opció de sortida.

La correcció és més estreta del que sembla. Standard pot arribar a la xarxa privada, però només mitjançant una integració de sortida compatible, i només per als destins que aquesta integració captura realment.

Trieu primer el camí de sortida

Un connector adjunt al servei és el que posa el seu trànsit dins del VPC. La documentació del connector llista el requisit regional i la configuració de sortida; el connector ha d'existir a la regió del servei i ser utilitzable per la identitat que desplega.

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

private-ranges-only envia els destins privats dins del VPC i deixa la resta pel camí normal d'internet, que normalment és el que necessita una connexió de base de dades. all-traffic empeny el trànsit de sortida a través del VPC de manera àmplia, de manera que les trucades ordinàries a internet també hereten la postura de NAT i tallafoc del VPC.

Editar el fitxer localment no canvia res fins que desplegueu. Una versió en execució conserva la configuració amb què es va crear.

L'adreça d'origen és el connector, no el vostre portàtil

Aquí se'n va la major part del temps de depuració. La passarel·la VPN remota i el tallafoc de la base de dades han d'admetre el rang assignat al connector dins del VPC, no l'adreça de la vostra oficina ni l'adreça de sortida pública del servei. Busqueu aquest rang a la consola abans d'escriure ni una sola regla.

Hi ha dos llocs més que han de coincidir. La taula de rutes del VPC necessita una ruta cap a la xarxa remota de la base de dades, i el costat remot necessita una ruta de retorn per al rang del connector. Si el túnel utilitza selectors de trànsit, confirmeu que el rang del connector queda dins de l'abast negociat. Una ruta que només existeix en la direcció de remot a local és un error habitual, i deixa passar pings sense completar mai un handshake TCP.

Un túnel que només admet una subxarxa de VM descartarà els paquets del connector sense cap missatge d'error útil, i per això el temps d'espera de la base de dades sembla un problema de credencials.

El DNS viatja per un camí diferent

Un nom d'amfitrió de base de dades privada s'ha de resoldre dins de la xarxa a què arriba el connector, mitjançant l'agermanament de Cloud DNS o una zona de reenviament que el VPC pugui utilitzar. Resoldre'l a la vostra estació de treball no demostra res sobre el servei desplegat, perquè el vostre portàtil no utilitza aquest resolutor.

Si el nom es resol a una adreça pública des de dins del VPC, esteu a punt de depurar el tallafoc equivocat.

URL Fetch no utilitza el connector

La configuració de sortida cobreix els sockets de sortida normals de l'entorn d'execució, i el servei URL Fetch heretat no forma part d'aquest camí. Una sol·licitud emesa mitjançant urlfetch ignora el connector faci el que faci la configuració. Quan la trucada que falla és dins d'una biblioteca antiga que encara utilitza URL Fetch, la solució és moure aquesta trucada al client HTTP estàndard.

Per a un controlador de base de dades això poques vegades és el problema, però és el motiu clàssic pel qual un punt final funciona i un altre no des del mateix servei.

Verifiqueu amb una consulta estreta

Desplegueu i després executeu una única operació de base de dades permesa des de la versió desplegada mentre observeu el costat remot. L'adreça d'origen que registri la base de dades o la passarel·la VPN hauria de ser la del connector. Si no ho és, la sol·licitud no va entrar mai al VPC i cap quantitat de configuració del túnel ho arreglarà. Compareu-la amb el rang que vau buscar a la consola; una discrepància normalment significa que un segon connector està servint la versió.

Una consulta correcta des d'una VM dins del VPC estableix que la ruta existeix. No estableix que el servei l'hagi triada.