App Engine peut atteindre votre base de données VPN : ce qui doit concorder

L'affirmation selon laquelle App Engine Standard ne peut pas atteindre une base de données privée via Cloud VPN est un vestige d'une génération antérieure de la plateforme. Les instances Standard ne reçoivent pas d'adresse native VPC comme certains autres environnements d'exécution, mais elles peuvent envoyer de l'egress via un connecteur Serverless VPC Access qui vit dans votre réseau. Une fois ce chemin établi, Cloud VPN et le pare-feu distant voient le trafic du connecteur comme n'importe quelle autre source. Ce qui échoue est rarement la capacité elle-même. C'est l'un des trois réglages qui n'ont jamais été alignés.

D'où venait l'ancienne réponse

Avant l'existence des connecteurs, la réponse pratique était réellement que Standard ne pouvait parler qu'à des points de terminaison publics, et les équipes passaient à une VM proxy ou à un autre environnement d'exécution pour contourner cela. La plateforme a changé, le folklore non. Beaucoup de conseils en ligne reflètent encore l'époque où aucune option d'egress n'existait.

La correction est plus étroite qu'il n'y paraît. Standard peut atteindre le réseau privé, mais uniquement via une intégration d'egress prise en charge, et uniquement pour les destinations que cette intégration capture réellement.

Choisissez d'abord le chemin d'egress

C'est un connecteur attaché au service qui place son trafic dans le VPC. La documentation du connecteur énumère le prérequis régional et les réglages d'egress ; le connecteur doit exister dans la région du service et être utilisable par l'identité qui déploie.

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

private-ranges-only envoie les destinations privées dans le VPC et laisse tout le reste sur le chemin internet normal, ce dont une connexion à une base de données a généralement besoin. all-traffic pousse le trafic sortant à travers le VPC de façon large, si bien que les appels internet ordinaires héritent aussi de la posture NAT et pare-feu du VPC.

Modifier le fichier localement ne change rien tant que vous ne déployez pas. Une version en cours d'exécution conserve la configuration avec laquelle elle a été créée.

L'adresse source est le connecteur, pas votre ordinateur portable

C'est là que passe l'essentiel du temps de débogage. La passerelle VPN distante et le pare-feu de la base de données doivent admettre la plage allouée au connecteur à l'intérieur du VPC, pas l'adresse de votre bureau ni l'adresse d'egress publique du service. Recherchez cette plage dans la console avant d'écrire la moindre règle.

Deux autres endroits doivent concorder. La table de routage du VPC a besoin d'une route vers le réseau distant de la base de données, et le côté distant a besoin d'une route de retour pour la plage du connecteur. Si le tunnel utilise des sélecteurs de trafic, confirmez que la plage du connecteur se trouve dans la portée négociée. Une route qui n'existe que dans le sens distant vers local est un oubli courant, et elle laisse passer les pings sans jamais terminer une poignée de main TCP.

Un tunnel qui n'admet qu'un sous-réseau de VM rejettera les paquets du connecteur sans message d'erreur utile, ce qui explique pourquoi le délai d'attente de la base de données ressemble à un problème d'identifiants.

Le DNS voyage par un autre chemin

Un nom d'hôte de base de données privée doit se résoudre à l'intérieur du réseau que le connecteur atteint, via l'appairage Cloud DNS ou une zone de transfert que le VPC peut utiliser. Le résoudre sur votre poste de travail ne prouve rien sur le service déployé, car votre ordinateur portable n'utilise pas ce résolveur.

Si le nom se résout en une adresse publique depuis l'intérieur du VPC, vous êtes sur le point de déboguer le mauvais pare-feu.

URL Fetch n'utilise pas le connecteur

Le réglage d'egress couvre les sockets sortants normaux de l'environnement d'exécution, et le service URL Fetch hérité ne fait pas partie de ce chemin. Une requête émise via urlfetch ignore le connecteur quoi que dise la configuration. Lorsque l'appel qui échoue se trouve dans une bibliothèque plus ancienne qui utilise encore URL Fetch, la correction consiste à déplacer cet appel vers le client HTTP standard.

Pour un pilote de base de données, c'est rarement le problème, mais c'est la raison classique pour laquelle un point de terminaison fonctionne et un autre non depuis le même service.

Vérifiez avec une requête étroite

Déployez, puis exécutez une seule opération de base de données autorisée depuis la version déployée en observant le côté distant. L'adresse source journalisée par la base de données ou la passerelle VPN doit être celle du connecteur. Si ce n'est pas le cas, la requête n'est jamais entrée dans le VPC et aucune configuration de tunnel n'y remédiera. Comparez-la à la plage que vous avez recherchée dans la console ; une divergence signifie généralement qu'un second connecteur sert la version.

Une requête réussie depuis une VM à l'intérieur du VPC établit que la route existe. Elle n'établit pas que le service l'a choisie.