Présentation
Généralement, les problèmes de connexion relèvent de l'un des trois domaines suivants :
- Connexion – parvenez-vous à accéder à votre instance via le réseau ?
- Autorisation – êtes-vous autorisé à vous connecter à l'instance ?
- Authentification – la base de données accepte-t-elle vos identifiants de base de données ?
Chacun de ces éléments peut être subdivisé en différentes pistes d'analyse. La section suivante présente des exemples de questions que vous pouvez vous poser afin de mieux cerner le problème :
Checklist des problèmes de connexion
- Connexion…
- Adresse IP privée
- Avez-vous activé l'
Service Networking API
pour votre projet ? - Utilisez-vous un VPC partagé ?
- Votre utilisateur ou votre compte de service dispose-t-il des autorisations IAM requises pour gérer une connexion d'accès privée aux services ?
- La connexion d'accès privée aux services est-elle configurée pour votre projet ?
- Avez-vous alloué une plage d'adresses IP à la connexion privée ?
- Vos plages d'adresses IP allouées contiennent-elles au moins un espace /24 pour chaque région dans laquelle vous prévoyez de créer des instances postgres ?
- Si vous spécifiez une plage d'adresses IP allouée pour vos instances postgres, la plage contient-elle au moins un espace /24 pour chaque région dans laquelle vous prévoyez de créer des instances postgres dans cette plage ?
- La connexion privée est-elle créée ?
- Si la connexion privée a été modifiée, les éléments vpc-peerings ont-ils été mis à jour ?
- Les journaux VPC indiquent-ils des erreurs ?
- L'adresse IP de votre machine source est-elle une adresse non-RFC 1918 ?
- Adresse IP publique
- Votre adresse IP source est-elle répertoriée en tant que réseau autorisé ?
- Des certificats SSL/TLS sont-ils requis ?
- Votre utilisateur ou votre compte de service dispose-t-il des autorisations IAM requises pour se connecter à une instance Cloud SQL ?
- Autoriser
- Proxy d'authentification Cloud SQL
- Le proxy d'authentification Cloud SQL est-il à jour ?
- Le proxy d'authentification Cloud SQL est-il en cours d'exécution ?
- Le nom de connexion de l'instance est-il correctement formé dans la commande de connexion proxy d'authentification Cloud SQL ?
- Avez-vous vérifié la sortie du proxy d'authentification Cloud SQL ? Dirigez la sortie vers un fichier, ou surveillez le terminal Cloud Shell dans lequel vous avez démarré le proxy d'authentification Cloud SQL.
- Votre utilisateur ou votre compte de service dispose-t-il des autorisations IAM requises pour se connecter à une instance Cloud SQL ?
- Avez-vous activé l'
Cloud SQL Admin API
pour votre projet ? - Si vous avez mis en place des règles de pare-feu pour le trafic sortant, assurez-vous qu'elles autorisent les connexions au port 3307 sur l'instance Cloud SQL cible.
- Si vous vous connectez à l'aide de sockets de domaine UNIX, vérifiez qu'ils ont bien été créés en répertoriant le contenu du répertoire spécifié avec l'option -dir lors du démarrage du proxy d'authentification Cloud SQL.
- Connecteurs Cloud SQL et code propre à un langage
- La chaîne de connexion est-elle correctement formée ?
- Avez-vous comparé votre code avec l'exemple de code correspondant à votre langage de programmation ?
- Utilisez-vous un environnement d'exécution ou un framework pour lequel vous n'avez pas d'exemple de code ?
- Si c'est le cas, vous êtes-vous tourné vers la communauté pour trouver des documents de référence pertinents ?
- Certificats SSL/TLS autogérés
- Le certificat du client est-il installé sur la machine source ?
- Le certificat du client est-il bien orthographié dans les arguments de connexion ?
- Le certificat du client est-il toujours valide ?
- Recevez-vous des erreurs lors de la connexion à l'aide de SSL ?
- Le certificat du serveur est-il toujours valide ?
- Réseaux autorisés
- L'adresse IP source est-elle incluse ?
- Utilisez-vous une adresse IP non-RFC 1918 ?
- Utilisez-vous une adresse IP non compatible ?
- Échecs de connexion
- Êtes-vous autorisé à vous connecter ?
- Rencontrez-vous des erreurs de limite de connexion ?
- Votre application ferme-t-elle les connexions correctement ?
- Authentification
- Authentification native à la base de données (nom d'utilisateur/mot de passe)
- Rencontrez-vous des erreurs
access denied
? - Le nom d'utilisateur et le mot de passe sont-ils corrects ?
- Authentification à la base de données IAM
- Avez-vous activé l'option
cloudsql.iam_authentication
sur votre instance ? - Avez-vous ajouté une liaison de règle sur le compte ?
- Utilisez-vous le proxy d'authentification Cloud SQL avec un jeton
-enable_iam_login
ou un jeton Oauth 2.0 comme mot de passe de base de données ? - Si vous utilisez un compte de service, utilisez-vous le nom d'adresse e-mail abrégé ?
- Apprenez-en davantage sur l'authentification IAM pour les bases de données dans PostgreSQL.
Messages d'erreur
Pour en savoir plus sur les messages d'erreur liés à l'API, consultez la page de référence Messages d'erreur.
Résoudre des problèmes de connectivité supplémentaires
Pour d'autres problèmes, consultez la section Connectivité sur la page de dépannage.
Problèmes de connexion courants
Vérifier que l'application ferme correctement les connexions
Si vous constatez des erreurs contenant "Aborted connection nnnn to db:
", cela indique généralement que votre application ne met pas fin aux connexions de manière appropriée. Des problèmes de réseau peuvent également provoquer cette erreur. Elle n'indique pas forcément des problèmes avec votre instance Cloud SQL. Vous êtes également invité à exécuter tcpdump
pour inspecter les paquets afin d'identifier la source du problème.
Pour obtenir des exemples de bonnes pratiques en matière de gestion des connexions, consultez la page Gérer les connexions à la base de données.
Vérifier la date d'expiration des certificats
Si votre instance est configurée pour utiliser SSL, accédez à la page "Instances Cloud SQL" dans Google Cloud Console et ouvrez l'instance. Accédez à la page Connexions, sélectionnez l'onglet Sécurité et vérifiez que le certificat de serveur est valide. S'il a expiré, vous devez ajouter un nouveau certificat et effectuer une rotation pour le mettre en application.
Vérifier que vous êtes autorisé à vous connecter
En cas d'échec de connexion, vérifiez que vous êtes autorisé à vous connecter :
- Si vous ne parvenez pas à vous connecter à l'aide d'une adresse IP, par exemple, vous vous connectez depuis votre environnement sur site avec le client psql. Assurez-vous que l'adresse IP à laquelle vous vous connectez est autorisée à se connecter à l'instance Cloud SQL.
Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. De cette manière, tous les clients privés peuvent accéder à la base de données sans passer par le proxy d'authentification Cloud SQL. Les plages d'adresses non-RFC 1918 doivent être configurées en tant que réseaux autorisés.
Par défaut, Cloud SQL n'apprend pas les routes de sous-réseau non-RFC 1918 à partir de votre VPC. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :
gcloud compute networks peerings update cloudsql-postgres-googleapis-com \ --network=NETWORK \ --export-subnet-routes-with-public-ip \ --project=PROJECT_ID
Voici votre adresse IP actuelle.
- Essayez la commande
gcloud sql connect
pour vous connecter à votre instance. Cette commande autorise votre adresse IP pour une courte période. Vous pouvez l'exécuter dans un environnement où gcloud CLI et le client psql sont installés. Vous pouvez également exécuter cette commande dans Cloud Shell, disponible dans la console Google Cloud et sur lequel gcloud CLI et le client psql sont préinstallés. Cloud Shell fournit une instance Compute Engine qui vous permet de vous connecter à Cloud SQL. - Permettez temporairement à toutes les adresses IP de se connecter à une instance en autorisant
0.0.0.0/0
.
Vérifier votre mode de connexion
Si vous recevez un message d'erreur du type :FATAL: database `user` does not exist.
La commande gcloud sql connect --user
ne fonctionne qu'avec l'utilisateur par défaut (postgres
). La solution consiste à vous connecter à l'aide de l'utilisateur par défaut, puis à utiliser la commande psql "\c"
pour vous reconnecter en tant qu'autre utilisateur.
Déterminer le mode de lancement des connexions
Pour afficher des informations sur vos connexions actuelles, connectez-vous à votre base de données et exécutez la commande suivante :
SELECT * from pg_stat_activity ;
Les connexions qui affichent une adresse IP, telle que 1.2.3.4
, se connectent via une adresse IP.
Les connexions avec cloudsqlproxy~1.2.3.4
utilisent le proxy d'authentification Cloud SQL, sinon elles proviennent d'App Engine. Les connexions à partir de localhost
peuvent être utilisées par certains processus Cloud SQL internes.
Limites de connexion
Les instances Cloud SQL ne sont pas limitées en nombre de requêtes par seconde. Toutefois, il existe des limites spécifiques liées aux connexions, à la taille et à App Engine. Consultez la section Quotas et limites pour en savoir plus.
Les connexions aux bases de données consomment des ressources sur le serveur et sur l'application de connexion. Suivez toujours les bonnes pratiques en matière de gestion des connexions afin de réduire au maximum l'encombrement de votre application et les risques de dépassement des limites de connexion Cloud SQL. Pour en savoir plus, consultez la page Gérer les connexions à la base de données.
Afficher les connexions et les threads
Pour afficher les processus en cours d'exécution sur votre base de données, utilisez la table pg_stat_activity :
select * from pg_stat_activity;
Délai avant expiration des connexions (depuis Compute Engine)
Les connexions à une instance Compute Engine expirent après 10 minutes d'inactivité, ce qui peut affecter les connexions inutilisées à longue durée de vie entre votre instance Compute Engine et votre instance Cloud SQL. Pour plus d'informations, consultez la section Mise en réseau et pare-feu dans la documentation Compute Engine.
Pour maintenir des connexions non utilisées à longue durée de vie, vous pouvez définir la valeur TCP keepalive. Les commandes suivantes définissent la valeur de TCP keepalive sur une minute et rendent la configuration permanente dans tous les redémarrages d'instance.
Affichez la valeur tcp_keepalive_time actuelle.
cat /proc/sys/net/ipv4/tcp_keepalive_time
Définissez le paramètre tcp_keepalive_time sur 60 secondes et de manière permanente à chaque redémarrage.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
Appliquez la modification.
sudo /sbin/sysctl --load=/etc/sysctl.conf
Affichez la valeur tcp_keepalive_time pour vérifier que la modification a été appliquée.
cat /proc/sys/net/ipv4/tcp_keepalive_time
Outils pour le débogage de la connectivité
tcpdump
tcpdump
est un outil permettant de capturer des paquets. Nous vous encourageons vivement à exécuter tcpdump
pour capturer et inspecter les paquets entre votre hôte et les instances Cloud SQL lorsque vous déboguez les problèmes de connectivité.
Localiser votre adresse IP locale
Si vous ne connaissez pas l'adresse locale de votre hôte, exécutez la commande ip -br address show
. Sous Linux, cette commande affiche l'interface réseau, l'état de l'interface, l'adresse IP locale et les adresses MAC. Exemple : eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64
.
Vous pouvez également exécuter ipconfig
ou ifconfig
pour afficher l'état de vos interfaces réseau.
Effectuer des tests avec Tests de connectivité
Le module Tests de connectivité se présente comme un outil de diagnostic qui vous permet de vérifier la connectivité entre les points de terminaison de votre réseau. Il analyse votre configuration et, dans certains cas, procède à la vérification de l'exécution. Il est désormais compatible avec Cloud SQL. Suivez ces instructions pour exécuter des tests avec vos instances Cloud SQL.
Tester votre connexion
Vous pouvez utiliser le client psql pour tester votre capacité à vous connecter depuis votre environnement local. Pour en savoir plus, consultez les pages Connecter un client psql à l'aide d'adresses IP et Connecter un client psql à l'aide du proxy d'authentification Cloud SQL.
Déterminer l'adresse IP de votre application
Pour déterminer l'adresse IP d'un ordinateur exécutant votre application et autoriser l'accès à votre instance Cloud SQL à partir de cette adresse, utilisez l'une des options suivantes :
- Si l'ordinateur n'est pas situé derrière un proxy ou un pare-feu, vous devez vous y connecter et utiliser le site Quelle est mon adresse IP ? pour déterminer son adresse IP.
- Si l'ordinateur est situé derrière un proxy ou un pare-feu, vous devez vous y connecter, et utiliser un outil ou un service (tel que whatismyipaddress.com) pour identifier son adresse IP réelle.
Ports locaux ouverts
Pour vérifier que votre hôte écoute bien sur les ports que vous pensez, exécutez la commande ss -tunlp4
. Cela vous indique quels ports sont ouverts et à l'écoute.
Par exemple, si une base de données PostgreSQL est en cours d'exécution, le port 5432 doit être opérationnel et à l'écoute. Pour SSH, vous devriez voir apparaître le port 22.
Ensemble de l'activité sur les ports locaux
Exécutez la commande netstat
pour afficher l'ensemble de l'activité des ports locaux. Par exemple, netstat -lt
affiche tous les ports actuellement actifs.
Se connecter à l'instance Cloud SQL à l'aide de SSL
Pour vérifier que vous pouvez vous connecter à votre instance Cloud SQL à l'aide de TCP
, exécutez la commande telnet
. Telnet tente de se connecter à l'adresse IP et au port que vous lui indiquez.
telnet 35.193.198.159 5432
.
En cas de réussite, les éléments suivants s'affichent :
Trying 35.193.198.159...
Connected to 35.193.198.159.
.
En cas d'échec, telnet
s'interrompt jusqu'à ce que vous forciez sa fermeture :
Trying 35.193.198.159...
^C.
.
Authentification client
L'authentification du client est contrôlée par un fichier de configuration nommé pg_hba.conf
(HBA signifie "authentification basée sur l'hôte").
Assurez-vous que la section des connexions de réplication du fichier pg_hba.conf
de la base de données source est mise à jour pour accepter les connexions de la plage d'adresses IP du VPC Cloud SQL.
Cloud Logging
Cloud SQL et Cloud SQL utilisent Cloud Logging. Consultez la documentation de Cloud Logging pour obtenir des informations complètes et accéder à des exemples de requêtes Cloud SQL.
Afficher les journaux
Vous pouvez afficher les journaux des instances Cloud SQL et d'autres projets Google Cloud tels que des instances Cloud VPN ou Compute Engine. Pour afficher les journaux correspondant aux entrées de journal de votre instance Cloud SQL, procédez comme suit :
Console
-
Dans la console Google Cloud, accédez à la page Cloud Logging.
- Sélectionnez un projet Cloud SQL existant en haut de la page.
- Dans le générateur de requêtes, ajoutez les éléments suivants :
- Ressource : sélectionnez Base de données Cloud SQL. Dans la boîte de dialogue, sélectionnez une instance Cloud SQL.
- Noms des journaux : faites défiler la page jusqu'à la section Cloud SQL et sélectionnez les fichiers journaux correspondant à votre instance. Par exemple :
- cloudsql.googleapis.com/postgres.log
- Gravité : sélectionnez un niveau de journalisation.
- Période : sélectionnez une valeur prédéfinie ou créez une période personnalisée.
gcloud
Exécutez la commande gcloud logging
pour afficher les entrées de journal. Dans l'exemple ci-dessous, remplacez PROJECT_ID
.
L'option limit
est un paramètre facultatif qui indique le nombre maximal d'entrées à renvoyer.
gcloud logging read "projects/PROJECT_ID/logs/cloudsql.googleapis.com/postgres.log" \ --limit=10
Adresses IP privées
Les connexions à une instance Cloud SQL à l'aide d'une adresse IP privée sont automatiquement autorisées pour les plages d'adresses RFC 1918. Les plages d'adresses non-RFC 1918 doivent être configurées dans Cloud SQL en tant que réseaux autorisés. Vous devez mettre à jour l'appairage de réseaux vers Cloud SQL pour exporter les routes non-RFC 1918. Exemple :
gcloud compute networks peerings update cloudsql-postgres-googleapis-com
--network=NETWORK
--export-subnet-routes-with-public-ip
--project=PROJECT_ID
Dépannage du VPN
Consultez la page Dépannage de Cloud VPN.