Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Il n'existe pas de documentation Apigee Edge équivalente pour ce sujet.
Symptôme
Dans certains cas, les clients externes ne peuvent pas accéder à Apigee de la manière souhaitée, ni s'y connecter. Cela inclut les échecs de connectivité réseau (échec du handshake TLS) ou les réponses 4xx/5xx
d'Apigee.
Message d'erreur
Lorsque vous envoyez une requête API de votre client à Apigee, vous constatez un échec du handshake TLS ou une réponse 4xx/5xx
même si les proxys d'API semblent opérationnels dans l'interface utilisateur Apigee.
Causes possibles
Cause | Description | Codes d'erreur |
---|---|---|
Erreurs TLS au niveau de l'équilibreur de charge HTTPS | Vous gérez la configuration TLS de l'équilibreur de charge HTTPS. Examinez les erreurs TLS dans les journaux de l'équilibreur de charge HTTPS. | Erreurs de handshake TLS à partir de l'adresse IP de l'équilibreur de charge |
Google Cloud Armor bloque les requêtes | Si vous utilisez Google Cloud Armor, une règle peut bloquer la requête. |
Le code de réponse de l'API peut varier en fonction de la configuration de Google Cloud Armor. Les règles de refus peuvent renvoyer une réponse HTTP 403 (Non autorisée), 404 (Accès refusé) ou 502 (Passerelle incorrecte), voire même un autre code de réponse.
|
Les VM de proxy Apigee ne parviennent pas à transférer le trafic vers l'instance Apigee | La configuration du proxy du routeur de trafic de l'API Apigee et son état doivent être examinés | 502 Server Error |
Configuration réseau incorrecte | Assurez-vous que le bon réseau est appairé avec Apigee VPC. | 502 Server error |
Environnements non associés sur la nouvelle instance Apigee créée dans le cadre de l'expansion de région | Après avoir créé une instance, par exemple dans une deuxième région, vous devez lui associer des environnements. Sinon, elle ne peut pas répondre aux requêtes API. | 503 error response |
Cause : erreurs TLS au niveau de l'équilibreur de charge HTTPS
Diagnostic
- Recherchez le certificat TLS associé à l'équilibreur de charge.
- En utilisant la console Google Cloud :
-
Dans la console Google Cloud, accédez à la page Équilibrage de charge.
-
Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
- Dans la zone Frontend, dans la colonne IP:Port, vérifiez que l'équilibreur de charge est le bon en confirmant son adresse IP et son port.
- Dans la colonne Certificat, cliquez sur le nom du certificat TLS pour l'afficher.
-
-
En utilisant une commande gcloud :
-
Répertoriez les équilibreurs de charge à l'aide de la commande gcloud suivante. Cette commande affiche également les
SSL_CERTIFICATES
associés à chaque équilibreur de charge.gcloud compute target-https-proxies list --project=
PROJECT_NAME Remplacez
PROJECT_NAME
par le nom de votre projet.Un résultat semblable au suivant s'affiche :
NAME: example-proxy-https-proxy SSL_CERTIFICATES: example-ssl-cert URL_MAP: example-proxy-url-map REGION: CERTIFICATE_MAP:
-
Affichez le certificat TLS avec la commande gcloud suivante (en supposant que
jq
ou un outil similaire est installé sur votre ordinateur) :gcloud compute ssl-certificates describe
CERTICATE_NAME \ --projectPROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -nooutRemplacez CERTIFICATE_NAME par le nom du certificat. Par exemple,
example-ssl-cert
.Un résultat semblable au suivant s'affiche :
certCertificate: Data: Version: 3 (0x2) Serial Number: 51:3b:a4:60:fe:49:34:a2:09:af:14:85:96:a2:4f:d9 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1D4 Validity Not Before: Jul 11 11:51:52 2023 GMT Not After : Oct 9 12:44:45 2023 GMT Subject: CN = 34.149.207.105.nip.io Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) . . Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: A5:DB:7C:6A:8B:0B:7A:22:45:52:1E:85:29:32:77:18:A3:9D:87:76 X509v3 Authority Key Identifier: keyid:25:E2:18:0E:B2:57:91:94:2A:E5:D4:5D:86:90:83:DE:53:B3:B8:92 Authority Information Access: OCSP - URI:http://ocsp.pki.goog/s/gts1d4/qMhEcTt7LjA CA Issuers - URI:http://pki.goog/repo/certs/gts1d4.der X509v3 Subject Alternative Name: DNS:34.149.207.105.nip.io X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.11129.2.5.3 X509v3 CRL Distribution Points: Full Name: URI:http://crls.pki.goog/gts1d4/LjtNmxrQfWE.crl
Assurez-vous que le nom commun (CN) dans le certificat correspond au nom d'hôte configuré dans Apigee> Admin > Environments >Groups. Assurez-vous que le certificat est valide et qu'il n'a pas expiré. Vous pouvez utiliser
openssl
pour effectuer ces vérifications.
-
Répertoriez les équilibreurs de charge à l'aide de la commande gcloud suivante. Cette commande affiche également les
- En utilisant la console Google Cloud :
-
Pour vérifier le certificat TLS renvoyé par l'équilibreur de charge, exécutez la commande
openssl
suivante à partir de votre machine cliente. Vérifiez si ce certificat correspond à celui renvoyé à l'étape 1 ci-dessus.openssl s_client -connect
LB_HOSTNAME_OR_IP :443 -servernameLB_HOSTNAME -showcertsRemplacez les éléments suivants :
-
LB_HOSTNAME_OR_IP : nom d'hôte ou adresse IP de l'équilibreur de charge. Par exemple,
my-load-balancer
. -
LB_HOSTNAME : nom d'hôte de l'équilibreur de charge. Par exemple,
my-hostname
.
Pour vérifier que les certificats correspondent, exécutez la commande suivante à partir de votre client :
echo | openssl s_client -connect
HOST_NAME :443 -servernameHOST_NAME | openssl x509 -noout -text | openssl md5Remplacez HOST_NAME par le nom d'hôte configuré dans Apigee (Administrateur > Environnements > Groupes).
Vérifiez ensuite que
md5
correspond, en exécutant la commande gcloud suivante :gcloud compute ssl-certificates describe
CERTIFICATE_NAME --projectPROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5Remplacez CERTIFICATE_NAME par le nom du certificat. Par exemple,
my-certificate
. -
LB_HOSTNAME_OR_IP : nom d'hôte ou adresse IP de l'équilibreur de charge. Par exemple,
-
Si les certificats de l'Étape 1 et de l'Étape 2 correspondent (par exemple, si les valeurs
md5
sont identiques), vous pouvez effectuer unepacket capture
côté client pour examiner l'échec du handshake TLS. Vous pouvez effectuer la capture de paquets côté client avec des outils tels que Wireshark, tcpdump ou tout autre outil fiable. - Activez les journaux sur l'équilibreur de charge en suivant les instructions de la section Activer la journalisation sur un service de backend existant.
- Recherchez d'éventuelles erreurs dans les journaux de l'équilibreur de charge.
Solution
- Si votre certificat autogéré sur l'équilibreur de charge a expiré ou comporte des valeurs CN/SAN incorrectes, vous devrez peut-être remplacer le certificat sur l'équilibreur de charge.
-
Si les certificats renvoyés par l'équilibreur de charge à l'étape 1 et à l'étape 2 ne correspondent pas, cela peut signifier que l'équilibreur de charge diffuse un certificat obsolète ou incorrect, auquel cas vous devrez envoyer une demande à Cloud Customer Care.
-
Si un
tcpdump
indique un échec de handshake TLS, déterminez si l'échec de connexion provient du côté équilibreur de charge ou du côté client.- Si la défaillance ou la réinitialisation de la connexion s'effectue côté client, vérifiez l'application cliente pour comprendre pourquoi elle présente un problème. Par exemple, vous pouvez vérifier la configuration réseau côté client ou vérifier que l'application cliente dispose bien d'une connectivité avec Apigee.
- Si vous constatez l'échec/la réinitialisation de l'équilibreur de charge lui-même, consultez la page Résoudre les problèmes de connectivité générale et envoyez une demande à l'équipe Google Cloud Customer Care si requis.
- Si vous voyez des erreurs dans les journaux de l'équilibreur de charge, consultez la section Erreurs 5XX inexpliquées et envoyez une demande à Google Cloud Customer Care si nécessaire.
Si vous avez encore besoin d'aide, consultez la page Vous devez collecter des informations de diagnostic.
Cause : Cloud Armor bloque les requêtes
Diagnostic
Si une réponse d'erreur 403
, 404
ou 502
s'affiche du fait de la configuration Cloud Armor, vérifiez l'équilibreur de charge et le MIG pour confirmer qu'ils sont correctement configurés et semblent opérationnels.
- Si vous utilisez Google Cloud Armor dans votre environnement Google Cloud, examinez la configuration de Google Cloud Armor pour identifier les règles susceptibles de bloquer la requête. Les règles de sécurité sont disponibles dans Configurer les règles de sécurité Google Cloud Armor.
- Si vous ne savez pas quelle règle refuse le trafic, vous pouvez essayer d'activer la journalisation sur l'équilibreur de charge, comme décrit dans la section Activer la journalisation sur un service de backend existant.
-
Une fois la journalisation activée, exécutez une requête de journaux pour rechercher les requêtes bloquées par les règles Google Cloud Armor :
-
Dans la console Google Cloud, accédez à la page Explorateur de journaux.
-
Collez le code suivant dans le volet Requête :
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
- Cliquez sur Exécuter la requête.
-
Le nom de la règle appliquée est affiché dans
jsonPayload.enforcedSecurityPolicy.name
, dans le volet Résultats de la requête :
-
Solution
Modifiez les règles/configurations Google Cloud Armor en fonction de vos besoins pour résoudre ce problème. Si vous avez besoin d'aide, contactez Google Cloud Customer Care.
Cause : Les VM de proxy Apigee ne parviennent pas à transférer le trafic vers l'instance Apigee.
Diagnostic
-
Si les clients API reçoivent des erreurs
HTTP 502
avec le message d'erreur suivant, les VM de proxy du routeur de trafic de l'API Apigee sont peut-être dans un état non opérationnel.Les clients peuvent recevoir les erreurs
502
suivantes :<html><head> <meta http-equiv="content-type" content="text/html;charset=utf-8"> <title>502 Server Error</title> </head> <body text=#000000 bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>
Recherchez des messages d'erreur comme ceux ci-dessous dans les journaux de l'équilibreur de charge :
statusDetails: "failed_to_pick_backend" severity: "WARNING"
Un ensemble de VM (avec le préfixe
apigee-proxy
) s'exécute dans un groupe d'instances géré (MIG) qui transfère le trafic vers l'instance Apigee. Si vous voyez des messages semblables à ceux ci-dessus, vérifiez l'état des VMapigee-proxy
du groupe d'instances en procédant comme suit :-
Dans la console Google Cloud, accédez à la page Équilibrage de charge.
-
Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
-
Dans la section Backend, vérifiez que la colonne Opérationnel contient une coche verte pour tous les backends de l'équilibreur de charge.
-
-
Vérifiez que l'adresse IP du point de terminaison dans le modèle de groupe d'instances géré correspond à l'adresse IP de l'instance Apigee.
Les VM
apigee-proxy
sont créées à l'aide d'un modèle d'instance. Le modèle définit l'adresse IPENDPOINT
à laquelle se connecter sur l'adresse IP de l'instance Apigee.-
Obtenez l'adresse IP de l'instance Apigee :
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \ "https://apigee.googleapis.com/v1/organizations/
ORG_NAME /instances/INSTANCE_NAME "Remplacez les éléments suivants :
-
ORG_NAME : nom de votre organisation. Par exemple,
my-org
. -
INSTANCE_NAME : nom de votre instance. Par exemple,
apigee-proxy-example
.
-
ORG_NAME : nom de votre organisation. Par exemple,
-
Vous pouvez également obtenir l'adresse IP de l'instance Apigee à partir de l'interface utilisateur d'Apigee :
- Dans l'interface utilisateur Apigee, cliquez sur Administrateur > Instances.
-
La colonne Adresses IP répertorie l'adresse IP :
-
Récupérez l'adresse IP
ENDPOINT
à partir du modèle :-
Dans la console Google Cloud, accédez à la page Équilibrage de charge.
- Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
- Dans la zone Backend, cliquez sur le nom d'un service de backend.
-
Dans la zone Membres du groupe d'instances, cliquez sur le nom d'un modèle.
-
Sur la page du modèle, faites défiler la page jusqu'à Métadonnées personnalisées, où vous pourrez voir l'adresse IP ENDPOINT :
-
Assurez-vous que l'adresse IP ENDPOINT correspond à l'adresse IP Apigee renvoyée à l'étape 2. Si ce n'est pas le cas, accédez à la section Résolution.
-
Obtenez l'adresse IP de l'instance Apigee :
Solution
-
Si les VM
apigee-proxy
du groupe d'instances affichent un état non opérationnel, assurez-vous que vous avez mis en place une règle de pare-feu qui permet aux plages d'adresses IP d'équilibrage de charge130.211.0.0/22
et35.191.0.0/16
d'accéder au MIG. -
Dans Google Cloud Console, accédez à la page Pare-feu.
-
Assurez-vous qu'il existe une règle de pare-feu d'entrée avec un
target-tag
similaire àgke-apigee-proxy
et avec des plages d'adresses IP sources similaires à130.211.0.0/22
et35.191.0.0/16
sur le port443 TCP
:Si le MIG a un tag différent de
gke-apigee-proxy
, assurez-vous que le tag est ajouté àtarget-tag
dans la règle de pare-feu.Si la règle de pare-feu n'existe pas, ajoutez-la.
- Si l'adresse IP ENDPOINT ne correspond pas à l'adresse IP de l'instance Apigee, il est possible que l'instance ait été supprimée et recréée, ce qui résulterait en une adresse IP qui ne correspond plus à celle du modèle. Pour mettre à jour le modèle de sorte qu'il utilise la nouvelle adresse IP, suivez les instructions de la section Modifier des adresses IP d'instance.
Cause : configuration réseau incorrecte
Diagnostic
-
Localisez la valeur de
authorizedNetwork
en exécutant l'appel d'API suivant :curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/
ORG_NAME "Un résultat semblable au suivant s'affiche :
{ "name": "apigee-example-org", "createdAt": "1621287579456", "lastModifiedAt": "1674063833580", "environments": [ "test" ], "properties": { "property": [ { "name": "features.mart.connect.enabled", "value": "true" }, { "name": "features.hybrid.enabled", "value": "true" } ] }, "analyticsRegion": "us-west1", "authorizedNetwork": "default", "runtimeType": "CLOUD", "subscriptionType": "PAID", "caCertificate": "certificate-number", "runtimeDatabaseEncryptionKeyName": "projects/apigee-example-org/locations/us-west1/keyRings/my-database-key-ring/cryptoKeys/my-database-key", "projectId": "apigee-example-org", "state": "ACTIVE", "billingType": "SUBSCRIPTION", "addonsConfig": { "advancedApiOpsConfig": {}, "integrationConfig": {}, "monetizationConfig": {} }, "apigeeProjectId": "l09587a43efde330cp-tp" }
Dans cet exemple,
authorizedNetwork
utilise la valeur par défaut. -
Vérifiez que la valeur
authorizedNetwork
est identique à celle du réseau appairé avecservicenetworking
:-
Dans la console Google Cloud du projet hôte, accédez à la page Appairage de réseaux VPC.
-
La valeur répertoriée pour
servicenetworking-googleapis-com
dans Votre réseau VPC doit être identique à la valeur renvoyée par l'appel d'API. Exemple :default
.
-
-
Si vous utilisez un VPC partagé, assurez-vous que la valeur
authorizedNetwork
correspond bien au VPC dans le projet hôte appairé àservicenetworking
.-
Dans Google Cloud Console, accédez à la page VPC partagé.
- Sélectionnez le projet hôte.
-
La valeur répertoriée pour
servicenetworking-googleapis-com
dans Votre réseau VPC doit être identique à la valeurauthorizedNetwork
renvoyée par l'appel d'API. Exemple :default
-
-
Vérifiez que le groupe d'instances associé à l'équilibreur de charge se trouve sur le même réseau que la valeur
authorizedNetwork
:-
Dans la console Google Cloud, accédez à la page Équilibrage de charge.
-
Cliquez sur le nom d'un équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche. La liste des groupes d'instances s'affiche dans la zone Backend :
- Cliquez sur le nom d'un groupe d'instances. La page Présentation du groupe d'instances s'affiche.
- Cliquez sur l'onglet Détails.
-
Faites défiler la page jusqu'à la section Mise en réseau :
-
Vérifiez que le réseau principal est identique à la valeur
authorizedNetwork
. Exemple :default
. - Cliquez sur l'onglet Overview (Vue d'ensemble).
- Dans la section Membres du groupe d'instances, cliquez sur le nom d'une instance. La page Détails s'affiche.
-
Faites défiler la page jusqu'à la section Interfaces réseau :
-
Vérifiez que la valeur Réseau est identique à la valeur
authorizedNetwork
. Exemple :default
. - Accédez à l'onglet Présentation et répétez les étapes, de l'étape h jusqu'à l'étape j pour chaque instance dans la section Membres du groupe d'instances.
-
Solution
-
Si à l'étape 2 ou à l'étape 3, la valeur
authorizedNetwork
est différente du réseau appairé avecservicenetworking
, vérifiez que vous avez appairé le bon réseau VPC avecservicenetworking
en suivant les étapes dans Étape 4 : Configurer la mise en réseau des services. -
Si à l'étape 4f et à l'étape 4j, les valeurs réseau ne sont pas identiques à la valeur
authorizedNetwork
, vérifiez queauthorizedNetwork
correspond au réseau appairé avecservicenetworking.
. Si l'appairage est correct et que le réseau est toujours différent deauthorizedNetwork,
, cela signifie que le groupe d'instances a été créé de manière incorrecte, auquel cas vous devez contacter Google Cloud Customer Care.
Cause : environnement non associé sur la nouvelle instance Apigee créée dans le cadre de l'expansion de région
Diagnostic
-
Une erreur
503
s'affiche côté client. Exemple :HTTP/2 503 date: Thu, 08 Jun 2023 07:22:15 GMT content-length: 0 via: 1.1 google alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
-
Si des erreurs
503
s'affichent sur la deuxième région immédiatement après une expansion de région :-
Assurez-vous que les environnements sont associés à la nouvelle instance en exécutant l'appel d'API suivant :
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/
ORG_NAME /instances/NEW_INSTANCE /attachments"Exemple :
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
Un résultat semblable au suivant s'affiche :
{ "attachments": [ { "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33", "environment": "dev", "createdAt": "1628153855420" }, { "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5", "environment": "prod", "createdAt": "1664517347106" } ] }
Dans cet exemple, l'instance nommée
apigee-proxy-example
est associée à deux environnements :dev
etprod
. -
Assurez-vous que le groupe d'instances géré (MIG) de la deuxième région a été créé et s'affiche comme étant opérationnel :
-
Dans la console Google Cloud, accédez à la page Équilibrage de charge.
- Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
-
Sous Backend, vous devriez voir deux MIG : un pour la région 1 et un pour la région 2. Vérifiez qu'ils sont tous les deux opérationnels :
- Validez le deuxième MIG en suivant les étapes décrites dans la section Les VM de proxy Apigee ne parviennent pas à transférer le trafic vers l'instance Apigee.
-
-
Assurez-vous que les environnements sont associés à la nouvelle instance en exécutant l'appel d'API suivant :
Solution
-
Si la nouvelle instance n'est pas associée à l'environnement, associez-la en suivant les instructions de la section Associer des environnements à la nouvelle instance.
Vous pouvez également vérifier que l'équilibreur de charge achemine la requête vers le backend approprié auquel l'environnement est déjà associé. Par exemple, un environnement hors production. Vous pouvez préférer ne l'associer qu'à une région, mais l'équilibreur de charge risque d'acheminer la requête vers la mauvaise région. Vous devez mettre à jour la configuration de l'équilibreur de charge pour vous assurer qu'il pointe vers la région appropriée.
- Si un MIG n'est pas opérationnel, consultez les sections suivantes Diagnostic et Résolution dans Les VM de proxy Apigee ne parviennent pas à transférer le trafic vers l'instance Apigee.
Vous devez collecter des informations de diagnostic
Si le problème persiste, même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez Google Cloud Customer Care :
- Organisation Apigee
- Environnement et proxy d'API où survient le problème
- Session de débogage téléchargée (si le problème est intermittent).
- Sortie curl détaillée d'une requête ayant échoué.
- Équilibreur de charge configuré pour envoyer des appels d'API à Apigee