Résoudre les problèmes de mise en réseau de Looker (Google Cloud Core)

Vous pouvez diagnostiquer et résoudre les problèmes de connectivité entrante et sortante courants pour votre instance Looker (Google Cloud Core) dans les configurations réseau publiques, privées et hybrides. Le dépannage de vos domaines personnalisés, de Private Service Connect, de l'accès aux services privés et de la sortie contrôlée vous aide à rétablir l'accès des utilisateurs à votre instance et à maintenir les connexions aux fournisseurs d'identité, aux services externes et aux backends de base de données.

Échec de la validation du domaine personnalisé avec l'erreur 9

Lorsque vous configurez un domaine personnalisé pour une instance Looker (Google Cloud Core) qui utilise des connexions publiques, la validation du domaine peut échouer et générer une erreur code: 9.

Symptômes

Lorsque vous cliquez sur VALIDER LE DOMAINE dans l'onglet DOMAINE PERSONNALISÉ de votre instance Looker (Google Cloud Core), la validation échoue et un message d'erreur semblable à celui-ci s'affiche :

DNS record is not created or not the same as public IP address (code: 9)

L'état du domaine personnalisé reste Non validé ou affiche Indisponible.

Cause

Bien que le message d'erreur indique que l'enregistrement A DNS est manquant ou incorrect, cette erreur se produit généralement pour l'une des raisons suivantes :

  • Enregistrements CAA restrictifs : la configuration DNS de votre domaine inclut des enregistrements CAA (Certification Authority Authorization) qui n'autorisent pas les autorités de certification (AC) de Google à émettre des certificats SSL/TLS. Étant donné que Looker (Google Cloud Core) utilise des certificats gérés par Google pour les instances publiques, le provisionnement des certificats échoue.
  • CDN ou proxy tiers : les instances Looker (Google Cloud Core) avec des connexions publiques utilisent exclusivement l'autorisation de l'équilibreur de charge (LB) pour les certificats gérés par Google. L'autorisation LB exige que l'enregistrement DNS A de votre domaine personnalisé soit résolu directement en adresse IP publique d'entrée Looker (Google Cloud Core). Si vous acheminez le trafic via un réseau de diffusion de contenu (CDN), un pare-feu d'application Web (WAF) ou un proxy inverse tiers (comme Akamai ou Cloudflare), l'autorisation automatique de l'équilibreur de charge échoue.

Solution

Selon la cause de l'échec, utilisez les méthodes suivantes pour résoudre le problème :

Autoriser les autorités de certification Google dans les enregistrements CAA

Si votre domaine utilise des enregistrements CAA, vérifiez et mettez à jour vos enregistrements DNS pour autoriser les fournisseurs de certificats de Google :

  1. Vérifiez les enregistrements CAA existants de votre domaine à l'aide d'un outil de résolution DNS tel que dig :

    dig CAA DOMAIN_NAME +short

    Remplacez DOMAIN_NAME par le nom de votre domaine personnalisé (par exemple, example.com ou looker.example.com).

  2. Ajoutez des enregistrements CAA pour autoriser pki.goog et letsencrypt.org :

    DOMAIN_NAME. IN CAA 0 issue "pki.goog"
DOMAIN_NAME. IN CAA 0 issue "letsencrypt.org"

    L'autorisation des deux CA garantit un provisionnement et un renouvellement automatiques fiables.

  3. Après avoir mis à jour vos enregistrements CAA, attendez la propagation DNS, puis cliquez à nouveau sur VALIDER LE DOMAINE dans la console Google Cloud .

Utiliser Private Service Connect pour les CDN et les proxys tiers

Il est impossible de placer des CDN et des proxys inversés tiers directement devant une instance Looker (Google Cloud Core) publique, car l'autorisation de l'équilibreur de charge automatisé nécessite une résolution DNS directe vers l'adresse IP publique de l'instance.

Pour acheminer le trafic entrant via un CDN ou un WAF tiers, déployez Looker (Google Cloud Core) à l'aide d'une architecture Private Service Connect au lieu de connexions publiques :

  1. Déployez une instance Looker (Google Cloud Core) avec Private Service Connect activé.
  2. Configurez un équilibreur de charge d'application externe avec un backend Private Service Connect dans votre réseau VPC.
  3. Provisionnez et associez votre propre certificat SSL autogéré ou géré par Google à l'équilibreur de charge d'application externe. Cette architecture vous permet de contrôler la terminaison TLS et de router le trafic via votre CDN ou WAF.

Échec de l'authentification OpenID Connect avec sortie contrôlée

Lorsque vous configurez l'authentification OpenID Connect sur une instance Looker (Google Cloud Core) configurée avec Private Service Connect et la sortie contrôlée activée, l'authentification peut échouer.

Symptômes

Si l'authentification a échoué, vous pouvez rencontrer l'un des problèmes suivants :

  • Le point de terminaison /openidconnect de Looker se bloque pendant environ 60 secondes dans le navigateur avant d'afficher une erreur ou d'expirer avec une erreur 504 Upstream Request Timeout ou 504 Gateway Timeout.

  • Votre fournisseur d'identité affiche un message d'erreur indiquant que l'URI de redirection ne correspond pas, par exemple :

    AADSTS50011: The redirect URI specified in the request does not match the
redirect URIs configured for the application

    Ce message d'erreur est trompeur, car l'URI de redirection que vous avez configuré dans votre fournisseur d'identité peut être correct. L'échec se produit lorsque Looker (Google Cloud Core) ne parvient pas à contacter le point de terminaison du jeton du fournisseur d'identité lors de l'échange de backend.

Cause

Le workflow de provisionnement automatisé pour la sortie contrôlée échoue parfois à créer la route réseau Secure Web Proxy (looker-swp-route) nécessaire dans le projet locataire Looker (Google Cloud Core).

Lorsque cette route est manquante, les requêtes de backend de Looker (Google Cloud Core) vers le point de terminaison du jeton du fournisseur d'identité expirent, car l'instance ne peut pas acheminer le trafic sortant vers l'Internet public via le Secure Web Proxy.

Solution

Pour résoudre ce problème, suivez ces étapes afin de réinitialiser la configuration de sortie contrôlée et forcer le système à recréer la route réseau manquante :

  1. Dans la console Google Cloud , accédez à la page Looker :

    Accéder à Looker

  2. Cliquez sur le nom de l'instance que vous souhaitez mettre à jour.

  3. Cliquez sur Modifier.

  4. Développez la section Connexions, puis accédez à la section Configurer les connexions sortantes.

  5. Enregistrez tous les noms de domaine complets (FQDN) existants listés dans la section FQDN global (tels que les points de terminaison de votre fournisseur d'identité).

  6. Supprimez tous les noms de domaine complets listés dans la section Nom de domaine complet global.

  7. Décochez la case Autoriser Looker à se connecter à des services externes pour désactiver la sortie contrôlée.

  8. Cliquez sur Enregistrer.

  9. Attendez que la mise à jour de l'instance soit terminée et que les modifications de configuration soient effacées.

  10. Cliquez à nouveau sur Modifier.

  11. Développez la section Connexions, puis cochez la case Autoriser Looker à se connecter à des services externes.

  12. Dans la section Nom de domaine complet global, ajoutez de nouveau les noms de domaine complets requis pour votre fournisseur d'identité et tout autre service externe.

  13. Cliquez sur Enregistrer.

La réinitialisation de la sortie contrôlée déclenche le processus de provisionnement automatique pour recréer la route réseau looker-swp-route manquante. Une fois la route créée, les requêtes de backend sortantes vers le fournisseur d'identité peuvent être effectuées.

Erreur 504 : expiration du délai de la requête en amont

Lorsque vous effectuez des appels d'API, exécutez des requêtes de longue durée ou vous authentifiez auprès d'un service externe sur une instance Looker (Google Cloud Core), la requête peut échouer avec une erreur de délai d'attente HTTP 504.

Symptômes

Vous pouvez recevoir une erreur 504 Upstream Request Timeout ou 504 Gateway Timeout dans l'un des cas suivants :

  • Appels ou requêtes d'API entrants : les appels d'API aux points de terminaison Looker, tels que /result_format, ou les requêtes de longue durée dans l'interface utilisateur Looker échouent avec une erreur 504 après environ 30 secondes sur une instance qui est précédée d'un équilibreur de charge.
  • Authentification sortante ou connexions à des services externes : vous recevez une erreur 504 dans votre navigateur après être revenu de la page de connexion d'un fournisseur d'identité ou lorsque vous vous connectez à un service externe sur une instance avec sortie contrôlée activée.

Cause

Une erreur de délai d'attente 504 se produit généralement pour l'une des raisons suivantes :

  • Délai avant expiration du service de backend de l'équilibreur de charge pour les requêtes entrantes : lorsque votre instance Looker (Google Cloud Core) est accessible via un équilibreur de charge Cloud Load Balancing, le service de backend de l'équilibreur de charge dispose d'un délai avant expiration du service de backend de 30 secondes par défaut. Si le temps d'exécution combiné des requêtes de base de données et le délai d'affichage de la charge utile Looker dépassent cette limite de délai avant expiration, l'équilibreur de charge ferme la connexion et renvoie une erreur HTTP 504.
  • Domaine sortant bloqué avec sortie contrôlée : l'instance Looker (Google Cloud Core) ne peut pas accéder à un domaine externe via une sortie contrôlée. Contrairement aux erreurs de route manquante, une erreur 504 lors des requêtes sortantes signifie généralement que le chemin réseau existe, mais qu'un domaine requis est manquant dans la liste d'autorisation FQDN global et est bloqué, ou que la requête expire au niveau de la passerelle.

Solution

En fonction de la cause de l'erreur, suivez les étapes décrites dans les sections suivantes pour résoudre le problème.

Résoudre les délais d'expiration de l'équilibreur de charge lors d'appels ou de requêtes d'API

Pour résoudre les erreurs 504 causées par le délai avant expiration du service de backend de l'équilibreur de charge, utilisez l'une des méthodes suivantes, ou les deux :

  • Augmentez le délai avant expiration du service de backend de l'équilibreur de charge :

    1. Dans la console Google Cloud , accédez à la page Équilibrage de charge :

      Accéder à la page Équilibrage de charge

    2. Cliquez sur Backends, puis sur le nom du service de backend associé à votre instance Looker (Google Cloud Core).

    3. Cliquez sur Modifier.

    4. Dans le champ Délai avant expiration, augmentez la valeur du délai avant expiration (par exemple, de 30 secondes à 300 secondes) pour tenir compte de vos requêtes et requêtes API les plus longues.

    5. Cliquez sur Enregistrer.

  • Utilisez un workflow d'API asynchrone : si vous appelez l'API Looker pour récupérer des données de requête et que vous ne pouvez pas modifier le délai d'expiration de l'équilibreur de charge, utilisez des points de terminaison asynchrones au lieu de requêtes synchrones. Appelez create_query_task pour démarrer la requête de manière asynchrone, puis interrogez query_task_results pour récupérer les résultats une fois la requête terminée.

Résoudre les délais d'expiration de la sortie contrôlée

Pour résoudre les erreurs 504 qui se produisent lorsque Looker (Google Cloud Core) ne parvient pas à se connecter à un service externe ou à un fournisseur d'identité avec la sortie contrôlée activée, procédez comme suit :

  1. Vérifiez les FQDN requis : dans la console Google Cloud , vérifiez que tous les domaines requis par votre service externe ou fournisseur d'identité sont ajoutés à la liste FQDN global. Les flux d'authentification OIDC nécessitent souvent plusieurs points de terminaison (tels que les points de terminaison d'autorisation, de jeton et d'informations utilisateur) qui peuvent utiliser différents domaines.
  2. Capturez une trace réseau : si l'erreur persiste, capturez une trace réseau du navigateur (fichier HAR) tout en reproduisant le problème. Recherchez les codes d'état 504 ou les requêtes HTTP ayant échoué dans la trace pour identifier les domaines qui ont été contactés pendant le flux, mais qui ne figurent pas dans votre liste Nom de domaine complet global.
  3. Réinitialiser la configuration : si les FQDN requis sont présents, mais que les requêtes continuent d'expirer, suivez les étapes de la section Résolution pour les échecs d'authentification OpenID Connect afin de réinitialiser la configuration de sortie contrôlée.

HttpClient:ConnectTimeoutError execution expired

Lorsque vous testez une connexion OpenID Connect ou d'autres connexions réseau externes dans le panneau d'administration Looker, le test de connexion peut échouer avec une erreur de délai avant expiration.

Symptômes

Lorsque vous exécutez un test de connexion dans le panneau d'administration Looker (par exemple, sur la page Authentification OpenID Connect), Looker renvoie l'erreur suivante :

HttpClient:ConnectTimeoutError execution expired

Cause

Cette erreur indique que l'instance Looker (Google Cloud Core) ne dispose pas du chemin réseau nécessaire pour communiquer avec le service externe ou le fournisseur d'identité. Ce problème se produit généralement lorsque l'une des conditions suivantes est remplie :

  • Propagation de route manquante : Cloud Router utilise les paramètres par défaut et ne propage pas les routes du réseau VPC (telles que les routes annoncées personnalisées) à l'instance Looker (Google Cloud Core).
  • NEG Internet manquant : un groupe de points de terminaison du réseau (NEG) Internet n'est pas configuré dans votre réseau VPC pour acheminer le trafic vers le service externe.

Solution

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

  1. Configurer la propagation des routes Cloud Router : vérifiez que Cloud Router est configuré pour propager les routes de réseau VPC nécessaires à votre instance Looker (Google Cloud Core) en configurant des routes annoncées personnalisées.
  2. Configurer un NEG Internet : configurez un NEG Internet dans votre réseau VPC pour permettre à l'instance Looker (Google Cloud Core) de router le trafic de sortie vers le fournisseur d'identité externe ou le service.
  3. Vérifiez l'accès aux services privés : pour les instances qui utilisent l'accès aux services privés, assurez-vous que votre réseau VPC est correctement appairé aux services Google. Pour en savoir plus, consultez Accéder à des services externes à l'aide de l'accès aux services privés.

Problèmes de connexion Southbound Private Service Connect

Pour les instances Looker (Google Cloud Core) qui utilisent Private Service Connect pour les connexions sortantes aux backends de base de données ou aux services publiés, vous pouvez rencontrer des erreurs de connexion même lorsque l'état du point de terminaison est Accepted.

Voici quelques problèmes courants :

  • Erreurs de résolution de nom d'hôte : si Looker (Google Cloud Core) affiche une erreur Unknown host lors du test d'une connexion, vérifiez que le nom d'hôte configuré correspond à l'enregistrement DNS de votre réseau privé et que l'équilibreur de charge de backend est opérationnel.
  • Délai d'expiration de la connexion : si les connexions expirent, vérifiez vos règles de pare-feu VPC pour vous assurer que le trafic entrant est autorisé depuis le sous-réseau NAT Private Service Connect vers les backends de votre équilibreur de charge.
  • État "En attente" ou "Fermé" : si l'état du rattachement de service est Pending ou Closed, vérifiez que le projet consommateur figure dans la liste d'autorisation du rattachement de service et que les vérifications d'état TCP obligatoires sont configurées.
  • Échecs de mise à jour avec l'erreur interne 13 : lorsque vous mettez à jour les pièces jointes de service sortant à l'aide de Terraform ou de l'API, la mise à jour peut échouer avec un Internal error 13 si votre configuration entrante est dans un état d'erreur. Pour en savoir plus, consultez Erreur interne 13 lors de la mise à jour des rattachements de service sortants.

Pour obtenir des informations détaillées sur les procédures de diagnostic et un arbre de décision, consultez Dépannage des connexions Private Service Connect southbound.

Erreur interne 13 lors de la mise à jour des rattachements de service sortants

Lorsque vous utilisez Terraform ou l'API Looker (Google Cloud Core) pour ajouter, modifier ou supprimer des rattachements de service Private Service Connect sortants (sortie) sur une instance Looker (Google Cloud Core) existante, la mise à jour peut échouer et générer une erreur interne.

Symptômes

Vous pouvez observer les symptômes suivants :

  • La mise à jour de Terraform ou de l'API échoue et renvoie une erreur semblable à celle-ci :

    Error: Error waiting for Updating Instance: Error code 13, message: an internal error has occurred

  • L'instance Looker (Google Cloud Core) ne parvient pas à établir de connexion avec les services cibles, même si le rattachement de service dans le réseau VPC du producteur affiche un état de connexion Accepted.

Cause

Cette erreur se produit lorsque la configuration Private Service Connect entrante de l'instance (allowed_vpcs) passe à l'état d'erreur dans le backend.

Lorsque vous utilisez Terraform ou un client API pour mettre à jour les pièces jointes de service sortantes (psc_service_attachments), la charge utile de la requête inclut généralement l'intégralité du bloc psc_config, qui contient le paramètre allowed_vpcs. L'API Looker (Google Cloud Core) tente de valider la configuration entrante lors de la mise à jour. Étant donné que allowed_vpcs est dans un état d'erreur, la validation échoue, ce qui entraîne l'échec de la mise à jour de l'ensemble de l'instance avec le code d'erreur 13 et empêche l'application des modifications apportées aux rattachements de service sortants.

Solution

Pour contourner l'erreur de validation de la configuration entrante et appliquer les modifications apportées à votre rattachement de service sortant, procédez comme suit :

  1. Dans votre configuration Terraform ou votre charge utile d'API, commentez ou supprimez temporairement le paramètre allowed_vpcs du bloc psc_config.

  2. Appliquez la configuration Terraform ou renvoyez la requête API pour mettre à jour vos pièces jointes de service sortantes (psc_service_attachments).

    Étant donné que la charge utile de la requête omet allowed_vpcs, l'API ignore la validation de la configuration entrante et applique les modifications apportées à l'association de service sortante.

  3. Une fois les pièces jointes de service sortantes déployées et les connexions établies, restaurez le paramètre allowed_vpcs dans votre configuration Terraform ou votre charge utile d'API.

  4. Appliquez à nouveau la configuration Terraform.

Problèmes de connectivité et de route d'accès aux services privés

Pour les instances Looker (Google Cloud Core) qui utilisent l'accès aux services privés, la communication sortante vers des services externes nécessite une propagation des routes et une infrastructure réseau appropriées :

  • Propagation des routes : vérifiez que Cloud Router est configuré pour propager les routes du réseau VPC à l'instance Looker (Google Cloud Core), telles que les routes annoncées personnalisées.
  • Groupes de points de terminaison réseau Internet : si votre instance doit accéder à des points de terminaison externes via l'accès aux services privés, assurez-vous qu'un groupe de points de terminaison réseau Internet (NEG) est configuré dans votre réseau VPC.

Si ces routes ou groupes de points de terminaison sont manquants, les tests de connexion aux points de terminaison externes échouent et génèrent une erreur HttpClient:ConnectTimeoutError execution expired.

Pour en savoir plus, consultez Accéder à des services externes à l'aide de l'accès aux services privés.

Outils de diagnostic et journaux

Utilisez les outils et journaux suivants pour diagnostiquer les problèmes de réseau :

  • Cloud Logging : affichez les journaux au niveau de l'instance dans Cloud Logging pour identifier les échecs de connexion et les événements système. Pour en savoir plus, consultez Afficher les journaux d'instance.
  • Activité du système Looker : si vous pouvez vous connecter en tant qu'administrateur, consultez le tableau de bord Activité des utilisateurs dans l'activité du système. Ce tableau de bord affiche les échecs de connexion récents, la méthode d'authentification utilisée et les messages d'erreur. Pour en savoir plus, consultez Tableau de bord "Activité utilisateur".
  • Journaux de flux VPC : consultez les journaux de flux VPC pour déterminer si le trafic réseau de Looker (Google Cloud Core) atteint votre sous-réseau de destination ou s'il est bloqué par les règles de pare-feu.
  • Cloud Customer Care : si vous avez suivi la procédure de dépannage et que le problème persiste, contactez Cloud Customer Care pour obtenir de l'aide.