Se connecter à un Redis Memorystore en local, sans IP publique
Publié le 15 août 2026
Une instance Memorystore n'a pas d'adresse publique : elle n'existe que dans un VPC, et l'on ne s'y connecte en local qu'en passant par une machine de ce réseau. Le tunnel IAP seul ne suffit pas, car il ne sait viser qu'un port de la VM elle-même, pas un hôte tiers. Le chemin réel vers un Redis Memorystore tient en deux bonds, dans une seule commande.
Pourquoi n'y a-t-il pas d'adresse publique ?
Ce n'est pas un oubli. Google ne bâtit de passerelle publique authentifiée, comme le proxy Cloud SQL ou celui de Cloud Run, que devant les protocoles capables de porter une vraie authentification. Redis n'en fait pas partie : son AUTH est un mot de passe simple et optionnel, et Google a donc choisi l'isolation réseau comme seule sécurité. L'instance ne répond qu'aux machines de son réseau autorisé, et rien d'autre ne l'atteint.
Le rebond par une VM de ce réseau n'est donc pas un contournement : c'est la méthode que Google prévoit pour un poste de travail. La documentation de Memorystore, consultée le 17 août 2026, documente exactement ce transfert de port par une VM du réseau autorisé.
Que sait faire le tunnel IAP, et où s'arrête-t-il ?
IAP est la porte de Google pour joindre une VM sans adresse publique : gcloud compute start-iap-tunnel ouvre un port local qui débouche sur un port de la VM. Sa limite est nette : il ne sait viser qu'un port de la VM elle-même, jamais un hôte tiers du réseau. Un Redis vit à une autre adresse du VPC, et le tunnel IAP seul s'arrête donc un bond trop tôt.
La réponse n'est pas de renoncer à IAP, c'est de le composer avec un ssh -L : IAP porte la session SSH jusqu'à la VM, et la VM porte le second bond, de son réseau vers l'adresse privée du Redis.
La commande à deux bonds, morceau par morceau
Il faut d'abord l'adresse privée de l'instance. Le listing la donne dans son champ host, avec le réseau autorisé, authorizedNetwork, qui resservira plus bas ; --region=- est le joker de l'API, toutes les régions d'un coup :
gcloud redis instances list --region=- --format=jsonPuis la commande entière, à garder telle quelle :
gcloud compute ssh <vm-rebond> --zone <zone> --project <projet> \
--tunnel-through-iap -- -N -L 127.0.0.1:6379:<ip-redis>:6379gcloud compute ssh ouvre une session SSH vers la VM et gère l'identité à votre place : pas de clé à produire ni à poser. --tunnel-through-iap fait passer cette session par IAP, et c'est le premier bond : aucun besoin d'adresse publique, ni sur la VM ni ailleurs. Tout ce qui suit -- part au client ssh : -N n'ouvre pas de shell, et -L 127.0.0.1:6379:<ip-redis>:6379 demande à la VM le second bond, de son réseau vers l'adresse privée du Redis. Tant que la commande tourne, votre client Redis parle à 127.0.0.1:6379 comme si l'instance écoutait sur votre machine.
Les trois erreurs qu'elle produit, et ce qu'elles veulent dire
| L'erreur | D'où elle vient | Le geste |
|---|---|---|
| La commande échoue avant d'ouvrir le port local | IAP refuse le premier bond : le rôle IAP-secured Tunnel User, roles/iap.tunnelResourceAccessor, manque, ou le pare-feu du projet ne laisse pas entrer la plage d'IAP, 35.235.240.0/20 | Les deux se règlent côté projet : la documentation d'IAP, consultée le 17 août 2026, donne la règle de pare-feu exacte |
channel 2: open failed: connect failed: Connection refused | Le premier bond est ouvert ; c'est le second qui échoue : mauvaise adresse, ou une VM qui n'est pas sur le réseau autorisé de l'instance | Comparer l'<ip-redis> de la commande au champ host du listing, et le réseau de la VM à authorizedNetwork |
bind: Address already in use | Le port local 6379 est déjà pris : un Redis installé en local, ou un tunnel précédent oublié | Changer la partie gauche du -L, 127.0.0.1:16379 par exemple, et y pointer le client |
La deuxième ligne est la plus trompeuse : le message vient du serveur SSH, pas de votre machine, et l'article qui lui est consacré explique comment le lire. La troisième a aussi le sien, parce qu'un tunnel oublié qui tient encore son port est la panne la plus banale du genre.
Kestro fait ce double bond en une bascule : il liste vos instances Redis, devine la VM de rebond dans le réseau autorisé, et compose exactement cette commande, comme il compose déjà celle du proxy Cloud SQL. Et la commande ci-dessus suffit si vous n'avez pas envie d'un outil de plus : gardée dans un alias, c'est le même chemin.
Ce qui reste
Le tunnel vit ce que vit la commande : terminal fermé ou machine mise en veille, et le chemin disparaît, parfois sans que rien ne le signale. Un projet sans aucune VM n'offre aucun rebond ; en créer une pour cela est une décision d'infrastructure, pas une astuce de dépannage, et elle n'est pas traitée ici. Si l'instance impose AUTH ou le chiffrement en transit, la porte réseau ne dispense ni du mot de passe ni du TLS : les deux ont leur section dans la documentation citée plus haut. Enfin, Memcached partage la même topologie ; le même chemin vaut pour lui, en changeant le port.