Cloud Run vers un VPN local : configurer la sortie directe VPC

Le tunnel est actif, une VM joint le serveur local, et le service Cloud Run expire sur le même hôte. C'est le point de départ habituel de cette tâche, et le tunnel est rarement ce qui ne va pas. Une révision Cloud Run ne se trouve pas dans votre VPC par défaut, et une fois qu'elle y est, elle utilise ses propres adresses source plutôt que le sous-réseau de VM que vous avez déjà routé. Le runbook ci-dessous rattache le service, route sa plage source réelle, puis prouve le chemin depuis la révision qui a servi la requête. Exécutez-le dans cet ordre, car sauter la première étape est la raison pour laquelle tant de ces cas se terminent par un changement de VPN qui ne corrige rien.

Rattachez la révision avant de déboguer le tunnel

Cloud Run prend en charge la sortie directe VPC, qui place le trafic du service sur un sous-réseau de votre VPC sans connecteur Serverless VPC Access. Pour un service existant, la mise à jour ressemble à ceci :

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

Remplacez les espaces réservés, examinez ce que le déploiement fait au trafic en direct, et choisissez un sous-réseau dans la région du service avec assez de capacité d'adresses et les bonnes autorisations réseau.

Choisissez le mode de sortie adapté à la destination

private-ranges-only envoie les destinations qu'il classe comme privées via le VPC. Cela ne signifie pas « tout ce qui est joignable par le VPN », et cet écart apparaît lorsque le service local se trouve dans une plage que le réglage ne classe pas ainsi. Si la destination n'est pas couverte, all-traffic est l'autre mode documenté, et il envoie tout via le VPC, y compris les dépendances publiques du service. Choisissez délibérément et inscrivez la conséquence dans le journal des changements.

Un service qui utilise déjà un connecteur relève d'une migration, pas d'un commutateur : planifiez-la au lieu de configurer les deux.

Routez la source Cloud Run, pas une source de VM

La sortie directe VPC alloue des adresses éphémères depuis le sous-réseau choisi, et le côté local doit renvoyer le trafic vers cette plage. Une route de retour ou une autorisation de pare-feu écrite pour un autre sous-réseau de VM semblera correcte sur le schéma et échouera en pratique. Prenez le CIDR du sous-réseau dans le VPC et non de mémoire, puis confirmez que l'ACL cryptographique ou la table de routage de l'équipement distant l'inclut.

Avec le routage dynamique, vérifiez ce que Cloud Router annonce réellement et ce que le VPC importe, y compris toute politique d'annonce personnalisée. Une route qui existe dans la console mais n'est pas sélectionnée pour cette destination équivaut à aucune route.

Trois conditions qui doivent toutes être réunies

Un chemin fonctionnel exige tout ce qui suit, et chacune échoue à sa manière :

• Une route dans le VPC vers le préfixe local via la connexion Cloud VPN prévue.
• Une route inverse en local pour le sous-réseau Cloud Run.
• Une portée de protection du pare-feu et IPsec autorisant la source, la destination et le port.

Une route manquante ressemble généralement à un délai d'attente sans preuve côté distant. Un problème de route inverse ressemble à une requête qui arrive et à une réponse qui disparaît. Un problème de pare-feu ou de sélecteur peut ressembler à un refus ou à un abandon silencieux, selon l'équipement. Déterminer laquelle des trois vous avez réduit considérablement la prochaine commande.

Ne mettez pas une seule adresse Cloud Run temporaire dans la liste d'autorisation. Utilisez la plage du sous-réseau et une conception d'autorisation adaptée à l'application.

Testez la révision qui a servi la requête

Inspectez les paramètres réseau déployés et la répartition du trafic avant de tester, car une mise à jour peut créer une nouvelle révision alors que des requêtes atteignent encore une version plus ancienne. Exécutez ensuite la même opération que la requête de l'utilisateur, depuis cette révision. Si la destination est un nom d'hôte privé, vérifiez sa résolution dans cet environnement et l'adresse obtenue, car la réponse DNS d'entreprise de votre ordinateur portable ne prouve rien sur l'espace de noms du service. Conservez la vérification du nom d'hôte TLS et l'authentification propre à l'application distante.

Attendez-vous aux délais de connexion au démarrage de Direct VPC documentés, et donnez au client une stratégie de disponibilité ou de nouvelle tentative au lieu de diagnostiquer chaque démarrage à froid comme un tunnel cassé.

Retour arrière et ce que cela ne fait pas

Pour revenir en arrière, restaurez les paramètres réseau et de sortie du service à leurs valeurs précédentes et confirmez que la révision antérieure sert toujours le trafic. Conservez la commande gcloud dans le journal des changements, car l'inverse d'un changement partiel n'est pas évident six semaines plus tard. Retirer le rattachement VPC ramène le service à son chemin de sortie précédent, ce qui peut être exactement ce que vous voulez pendant un incident.

Cette conception couvre les connexions que Cloud Run initie et leurs réponses. Elle ne donne pas au réseau local une socket adressable à l'intérieur du service, car l'exposition entrante est une décision d'ingress.