Résoudre les problèmes de connexion vers le sud

Cette page explique comment résoudre les problèmes de connexion sortante pour les instances Looker (Google Cloud Core) qui utilisent une configuration d'adresse IP privée avec Private Service Connect.

Si vous rencontrez un échec avec votre connexion Private Service Connect sortante, utilisez l'arborescence de décision suivante pour commencer le dépannage.

Pour en savoir plus, consultez la documentation Accès sortant de Looker (Google Cloud Core) aux services externes à l'aide de Private Service Connect.

Résoudre les erreurs de connexion

Même si l'état de la connexion Private Service Connect est Accepted, vous pouvez toujours rencontrer des erreurs de connexion lorsque Looker (Google Cloud Core) tente d'accéder à votre service.

Problèmes de résolution du nom d'hôte

Si vous recevez une erreur "Unknown host" (Hôte inconnu) dans l'interface utilisateur Looker (Google Cloud Core) lorsque vous testez une connexion à une base de données ou lorsque Looker (Google Cloud Core) tente de se connecter à votre service, cela peut indiquer que la résolution DNS a échoué pour le nom d'hôte que vous avez configuré pour la connexion Private Service Connect sortante.

Dans ce cas, procédez comme suit :

  • Vérifiez que le nom d'hôte configuré dans Looker (Google Cloud Core) pour le service est correct et qu'il correspond au nom d'hôte pour lequel un enregistrement DNS doit exister.
  • Vérifiez que votre équilibreur de charge et votre service de backend sont opérationnels.
  • Testez la connectivité à partir d'une VM de votre VPC producteur pour vous assurer que le service de backend est accessible via la règle de transfert de l'équilibreur de charge. Vous pouvez créer une VM temporaire dans le même VPC et la même région que votre équilibreur de charge, puis utiliser un outil tel que curl ou telnet pour tester la connectivité à l'adresse IP et au port du service.

Si les problèmes de résolution du nom d'hôte persistent, contactez l'assistance Cloud Customer Care pour obtenir de l'aide.

Délai d'inactivité de la connexion

Si les connexions de Looker (Google Cloud Core) à votre service expirent, cela peut être dû à des règles de pare-feu dans votre VPC producteur qui bloquent le trafic provenant du sous-réseau NAT Private Service Connect, ou à d'autres problèmes de réseau.

Vérifier la configuration Private Service Connect sortante

Pour vérifier que la connexion entre l'instance Looker (Google Cloud Core) et votre réseau est correctement établie, procédez comme suit :

Vérifier l'état du point de terminaison Private Service Connect de l'instance Looker (Google Cloud Core)

Pour vérifier l'état de la connexion sortante du rattachement de service à partir de la configuration de l'instance Looker (Google Cloud Core) :

  1. Dans la Google Cloud console, accédez à la page Looker.
  2. Cliquez sur le nom de l'instance pour laquelle vous souhaitez vérifier la connexion.
  3. Dans la section Mise en réseau, sous Rattachement de service, recherchez le point de terminaison que vous dépannez.
  4. Vérifiez que l'état est Accepted.

Si l'état est Pending, cela peut être dû à l'une des raisons suivantes :

  • La préférence de connexion du rattachement de service n'est pas définie sur "Accepter automatiquement toutes les connexions" et la connexion n'a pas été approuvée manuellement.
  • Le projet de l'instance Looker (Google Cloud Core) ne figure pas dans la liste d'autorisation du rattachement de service.

Pour résoudre un état Pending, vérifiez la configuration de votre rattachement de service et assurez-vous que la préférence de connexion est définie sur Automatically accept all connections ou que le projet Looker (Google Cloud Core) a été explicitement autorisé.

Si le domaine ou l'URI du rattachement est incorrect, exécutez à nouveau la commande gcloud looker instances update avec les valeurs correctes. Cette commande écrase tous les rattachements existants. Par conséquent, tous les rattachements sélectionnés doivent être inclus. Pour en savoir plus, consultez Modifier les paramètres d'une instance Looker (Google Cloud Core).

Vérifier la configuration du rattachement de service du producteur

Vous devez également vérifier la configuration du rattachement de service dans votre projet producteur pour vous assurer qu'il est correctement configuré pour recevoir les connexions de Looker (Google Cloud Core).

Dans la Google Cloud console, accédez à Services réseau > Private Service Connect, puis cliquez sur l'onglet Services publiés. Cliquez sur le rattachement de service utilisé pour la connexion afin d'afficher ses détails.

Vérifiez que les exigences suivantes sont remplies :

  • Le rattachement de service est configuré avec une règle de transfert cible valide et un sous-réseau NAT Private Service Connect dédié.
  • La préférence de connexion est définie sur Accept automatically. Si la préférence de connexion est Accept for selected networks ou Accept for selected projects, assurez-vous que la connexion provenant du projet Looker (Google Cloud Core) a été approuvée.
  • Le service cible pointe vers la règle de transfert appropriée.
  • Le sous-réseau NAT est correctement configuré et dispose d'un espace IP suffisant.
  • L'URI du rattachement de service fourni à l'instance Looker (Google Cloud Core) est correct.

Vous pouvez mettre à jour la configuration du rattachement de service à l'aide de la Google Cloud console ou en exécutant la gcloud compute service-attachments update commande.

Vérifier les règles de pare-feu

Le trafic provenant de Looker (Google Cloud Core) entre dans votre VPC via le sous-réseau NAT Private Service Connect. Vous devez disposer de règles de pare-feu qui autorisent ce trafic à atteindre les backends de l'équilibreur de charge.

Pour vérifier vos règles de pare-feu :

  1. Identifiez la plage d'adresses IP du sous-réseau NAT Private Service Connect configuré sur votre rattachement de service.
  2. Dans la Google Cloud console, accédez à la page Pare-feu de votre VPC producteur.
  3. Vérifiez qu'il existe une règle de pare-feu d'entrée qui autorise le trafic TCP provenant du sous-réseau NAT Private Service Connect vers les backends de votre équilibreur de charge sur le port utilisé par votre service. La règle doit répondre aux critères suivants :
    • Filtre source : les plages d'adresses IP sources incluent la plage de sous-réseaux NAT Private Service Connect.
    • Cibles : la règle s'applique aux backends de l'équilibreur de charge interne (par exemple, via des tags réseau).
    • Protocoles et ports : la règle autorise le trafic TCP sur le port du service cible.

Si aucune règle de ce type n'existe ou si une règle de priorité plus élevée refuse ce trafic, créez une règle de pare-feu d'entrée pour autoriser le trafic provenant du sous-réseau NAT Private Service Connect.

Vérifier la configuration de l'équilibreur de charge et du groupe de points de terminaison du réseau

Votre service est exposé à Looker (Google Cloud Core) via un équilibreur de charge interne et un groupe de points de terminaison du réseau (NEG) qui pointe vers votre service. Vérifiez que ces composants sont opérationnels et correctement configurés.

Pour vérifier la configuration du NEG :

  1. Dans la Google Cloud console, accédez à Services réseau > Équilibrage de charge.
  2. Cliquez sur votre équilibreur de charge, puis sur le service de backend pour afficher ses détails.
  3. Dans les détails du service de backend, cliquez sur le nom du groupe de points de terminaison du réseau.
  4. Vérifiez le type de groupe de points de terminaison du réseau:
    • Pour les services sur site ou multicloud accessibles via Cloud VPN ou Cloud Interconnect, le type doit être NEG de connectivité hybride (NON_GCP_PRIVATE_IP_PORT).
    • Pour les services Internet publics, tels que les fournisseurs Git, le type doit être un NEG Internet (INTERNET_FQDN_PORT).
  5. Dans la section Points de terminaison du réseau, vérifiez que l'adresse IP et le port (pour les NEG hybrides) ou le nom de domaine complet et le port (pour les NEG Internet) correspondent correctement à votre service cible.

Si le NEG est mal configuré, vous devrez peut-être le mettre à jour ou en créer un.

Vérifier la résolution et le routage DNS

Si vous ne parvenez pas à vous connecter à partir de Looker (Google Cloud Core), mais que d'autres étapes de dépannage ne montrent aucun problème, testez la connectivité à partir du VPC producteur pour isoler le problème :

  1. Créez une VM Compute Engine temporaire dans le même VPC et le même sous-réseau que votre équilibreur de charge interne.
  2. À partir de cette VM, utilisez des outils tels que telnet ou nc pour tester la connectivité à l'adresse IP de la règle de transfert de l'équilibreur de charge sur le port de votre service. Par exemple : telnet LOAD_BALANCER_IP TARGET_PORT.

Si vous parvenez à vous connecter à partir de la VM, le problème se situe probablement sur le chemin d'accès entre Looker (Google Cloud Core) et votre VPC. Vérifiez à nouveau la configuration de votre rattachement de service et de votre instance Looker (Google Cloud Core).

Si vous ne parvenez pas à vous connecter à partir de la VM, le problème se situe probablement dans votre VPC producteur. Vérifiez la règle de transfert de l'équilibreur de charge, l'état du service de backend et les règles de pare-feu dans votre VPC.

Examiner les problèmes de connexion à un service spécifique

Certains services cibles ont des exigences ou des dépendances uniques lorsqu'ils sont connectés via Private Service Connect.

Snowflake : points de terminaison de stockage secondaires

Le pilote JDBC Snowflake télécharge souvent des ensembles de résultats ou des métadonnées à partir d'un emplacement de stockage cloud intermédiaire (tel qu'Amazon S3 ou Azure Blob Storage), plutôt qu'à partir de l'hôte de la base de données principale. Si Looker (Google Cloud Core) ne parvient pas à atteindre ces points de terminaison secondaires, les connexions ou les requêtes peuvent échouer, en particulier pour les ensembles de résultats volumineux.

Pour résoudre ce problème, procédez comme suit :

  1. Recherchez dans vos journaux Looker (Google Cloud Core) les erreurs de délai avant expiration qui font référence à des domaines de stockage externes, tels que s3.amazonaws.com ou blob.core.windows.net.
  2. Identifiez le nom de domaine complet exact du point de terminaison de stockage requis par votre instance Snowflake. Vous trouverez ces informations dans vos journaux Snowflake ou en contactant l'assistance Snowflake.
  3. Chaque nom de domaine complet externe doit être configuré en tant que connexion sortante distincte. Créez une configuration Private Service Connect (NEG Internet, équilibreur de charge et rattachement de service) pour le nom de domaine complet du point de terminaison de stockage.
  4. Ajoutez le nouveau rattachement de service à la configuration de votre instance Looker (Google Cloud Core).

Fournisseurs Git publics : sortie vers Internet

Les instances Looker (Google Cloud Core) avec une configuration d'adresse IP privée ne disposent pas d'une route par défaut vers l'Internet public. Pour vous connecter à des fournisseurs Git publics tels que GitHub ou GitLab, vous devez configurer explicitement un chemin de sortie.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez si vous essayez de vous connecter à un fournisseur Git public à partir d'une instance d'adresse IP privée. Les échecs de connexion se manifestent souvent sous la forme de délais avant expiration génériques ou d'erreurs de handshake SSL.
  2. Créez une connexion Private Service Connect sortante à l'aide d'un NEG Internet.
  3. Assurez-vous que le NEG Internet est configuré pour le port approprié (par exemple, le port 22 pour SSH ou le port 443 pour HTTPS).
  4. Si vous disposez d'une règle de remplacement DNS dans votre VPC qui crée une boucle de routage avec un NEG Internet basé sur un nom de domaine complet, envisagez d'utiliser un NEG Internet basé sur une adresse IP (INTERNET_IP_PORT) à la place.

Action Hub et Marketplace

Les Marketplace et Action Hub Looker (Google Cloud Core) par défaut hébergés par Google sont des services Internet publics et ne sont pas accessibles par défaut à partir d'instances d'adresse IP privée.

  • Action Hub : pour utiliser Action Hub avec une instance d'adresse IP privée, vous devez déployer un serveur Action Hub privé auto-hébergé et vous y connecter à l'aide d'une connexion Private Service Connect sortante.
  • Marketplace : pour vous connecter à Marketplace Looker, vous pouvez activer la connexion à Marketplace dans la configuration des connexions sortantes de votre instance. Une fois activé, Looker (Google Cloud Core) utilise un proxy Web sécurisé pour se connecter directement à la Marketplace et github.com. Pour en savoir plus, consultez Se connecter à Marketplace Looker. Si vous n'activez pas cette connexion, vous devez télécharger manuellement les extensions ou les blocs à partir de leurs dépôts Git et les installer en tant que projets locaux.

Consulter les journaux

Les journaux de flux de cloud privé virtuel et la journalisation de l'équilibreur de charge (tels que la journalisation de l'équilibreur de charge d'application interne ou la journalisation de l'équilibreur de charge réseau passthrough interne) peuvent fournir plus d'informations sur les problèmes de connectivité.

Activez les journaux de flux de cloud privé virtuel sur les sous-réseaux utilisés par l'équilibreur de charge et activez la journalisation sur le service de backend de votre équilibreur de charge interne. Ensuite, essayez de vous connecter à partir de Looker (Google Cloud Core) pour reproduire l'erreur.

Dans Cloud Logging, interrogez les journaux de flux de cloud privé virtuel en filtrant le trafic provenant de la plage d'adresses IP du sous-réseau NAT Private Service Connect vers l'adresse IP de l'équilibreur de charge. Si le trafic atteint l'équilibreur de charge, interrogez les journaux d'équilibrage de charge pour obtenir des informations sur l'état de la connexion au backend.