Problèmes de routage des accès avec Apigee

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 :
1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
  
  Accéder à la page "Équilibrage de charge"
2. Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
3. 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.
4. 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 \
--project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -noout

Remplacez 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) du certificat correspond au nom d'hôte configuré dans Apigee > Administrateur > Environnements > Groupes. Assurez-vous que le certificat est valide et qu'il n'a pas expiré. Vous pouvez utiliser openssl pour effectuer ces vérifications.

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 -servername LB_HOSTNAME -showcerts
```
Remplacez 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 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Remplacez 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 --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
Remplacez CERTIFICATE_NAME par le nom du certificat. Par exemple, my-certificate.
Si les certificats de l'Étape 1 et de l'Étape 2 correspondent (par exemple, si les valeurs md5 sont identiques), vous pouvez effectuer une packet 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 à l'assistance Apigee.
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'assistance Apigee si nécessaire.
Si vous voyez des erreurs dans les journaux de l'équilibreur de charge, consultez la section Erreurs 5XX inexpliquées et envoyez une demande à l'assistance Apigee 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 :
1. Dans la console Google Cloud, accédez à la page Explorateur de journaux.
  
  Accéder à l'explorateur de journaux
2. Collez le code suivant dans le volet Requête :
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Cliquez sur Exécuter la requête.
4. 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 l'assistance Apigee.

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 VM apigee-proxy du groupe d'instances en procédant comme suit :
1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
  
  Accéder à la page "Équilibrage de charge"
2. Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
3. 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 IP ENDPOINT à laquelle se connecter sur l'adresse IP de l'instance Apigee.
1. 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.
2. Vous pouvez également obtenir l'adresse IP de l'instance Apigee à partir de l'interface utilisateur d'Apigee :
  1. Dans l'interface utilisateur Apigee, cliquez sur Administrateur > Instances.
  2. La colonne Adresses IP répertorie l'adresse IP :
3. Récupérez l'adresse IP ENDPOINT à partir du modèle :
  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
    
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
  3. Dans la zone Backend, cliquez sur le nom d'un service de backend.
  4. Dans la zone Membres du groupe d'instances, cliquez sur le nom d'un modèle.
  5. 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.

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 charge 130.211.0.0/22 et 35.191.0.0/16 d'accéder au MIG.
Dans Google Cloud Console, accédez à la page Pare-feu.

Accéder à 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 et 35.191.0.0/16 sur le port 443 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é avec servicenetworking :
1. Dans la console Google Cloud du projet hôte, accédez à la page Appairage de réseaux VPC.
  
  Accéder à la page "Appairage de réseaux VPC"
2. 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.
1. Dans Google Cloud Console, accédez à la page VPC partagé.
  
  Accéder à la page "VPC partagé"
2. Sélectionnez le projet hôte.
3. La valeur répertoriée pour servicenetworking-googleapis-com dans Votre réseau VPC doit être identique à la valeur authorizedNetwork 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 :
1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
  
  Accéder à la page "Équilibrage de charge"
2. 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 :
3. Cliquez sur le nom d'un groupe d'instances. La page Présentation du groupe d'instances s'affiche.
4. Cliquez sur l'onglet Détails.
5. Faites défiler la page jusqu'à la section Mise en réseau :
6. Vérifiez que le réseau principal est identique à la valeur authorizedNetwork. Exemple : default.
7. Cliquez sur l'onglet Overview (Vue d'ensemble).
8. Dans la section Membres du groupe d'instances, cliquez sur le nom d'une instance. La page Détails s'affiche.
9. Faites défiler la page jusqu'à la section Interfaces réseau :
10. Vérifiez que la valeur Réseau est identique à la valeur authorizedNetwork. Exemple : default.
11. 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é avec servicenetworking, vérifiez que vous avez appairé le bon réseau VPC avec servicenetworking 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 que authorizedNetwork correspond au réseau appairé avec servicenetworking. . Si l'appairage est correct et que le réseau est toujours différent de authorizedNetwork,, cela signifie que le groupe d'instances a été créé de manière incorrecte, auquel cas vous devez contacter l'assistance Apigee.

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. Par 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
```
Remarque : Cette erreur 503 n'est pas affichée dans la trace de débogage, car les requêtes n'atteignent jamais le processeur de messages de l'environnement d'exécution.
Si des erreurs 503 s'affichent sur la deuxième région immédiatement après une expansion de région :
1. 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"
```
  Par 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 et prod.
2. 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 :
  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
    
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur le nom de l'équilibreur de charge. La page Détails de l'équilibreur de charge s'affiche.
  3. 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 :
  4. 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.

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 l'assistance Apigee :

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