Cette page a été traduite par l'API Cloud Translation.

502 – Erreur de délai avant expiration de la passerelle incorrecte

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

L'application cliente reçoit une erreur 502 Bad Gateway (Passerelle incorrecte). Le processeur de messages renvoie cette erreur à l'application cliente lorsqu'il ne reçoit pas de réponse d'un serveur backend.

Message d'erreur

L'application cliente reçoit le code de réponse suivant:

HTTP/1.1 502 Bad Gateway

De plus, le message d'erreur suivant peut s'afficher:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Cause possible

La cause possible de ce problème est indiquée dans le tableau suivant:

Cause	Description	La procédure de dépannage peut être effectuée par
Délai avant expiration du handshake TLS/SSL	Une expiration du délai se produit lors du handshake TLS/SSL entre le processeur de messages et le serveur backend.	Utilisateurs de cloud privé et public Edge

Cause: délai avant expiration du handshake TLS/SSL

Dans Apigee Edge, vous pouvez configurer une connexion TLS/SSL au serveur backend pour activer la communication TLS entre le processeur de messages Edge et un serveur backend.

Un handshake TLS/SSL implique plusieurs étapes. Cette erreur se produit généralement lorsque le handshake TLS/SSL entre le processeur de messages et un serveur backend expire.

Diagnostic

Cette section explique comment diagnostiquer correctement un délai avant expiration du handshake TLS/SSL. Les instructions pour le cloud privé Edge et le cloud public sont répertoriées.

Analyser les résultats d'une session Trace

Les étapes suivantes expliquent comment effectuer un diagnostic préliminaire du problème à l'aide de l'outil Apigee Edge Trace.

Dans l'interface utilisateur Edge, activez une session de traçage pour le proxy d'API concerné.
Si la trace de la requête API ayant échoué indique ce qui suit, il est probable qu'une erreur de délai avant expiration du handshake TLS/SSL s'est produite. L'erreur est probablement due au fait que le pare-feu du serveur backend bloque le trafic provenant d'Apigee.
1. Déterminez si l'erreur 502 Bad Gateway (Passerelle incorrecte) se produit après 55 secondes, ce qui correspond au délai avant expiration par défaut défini sur le processeur de messages. Si vous constatez que l'erreur s'est produite au bout de 55 secondes, cela vous indique qu'un délai avant expiration était probablement la cause du problème.
2. Déterminez si l'erreur est due à l'erreur: messaging.adaptors.http.BadGateway. Là encore, cette erreur indique généralement un délai d'inactivité.
3. Si vous êtes sur Edge Private Cloud, notez la valeur du champ X-Apigee.Message-ID dans la trace de sortie, comme indiqué ci-dessous. Un utilisateur de cloud privé peut utiliser cette valeur d'ID pour effectuer d'autres opérations de dépannage, comme expliqué ultérieurement.
  1. Cliquez sur l'icône Données analytiques enregistrées dans le chemin de trace:
  2. Faites défiler vers le bas et notez la valeur du champ appelé X-Apigee.Message-ID.

Pour vérifier que le délai avant expiration du handshake TLS/SSL est la cause de l'erreur, suivez les étapes dans les sections suivantes selon que vous utilisez un cloud public ou un cloud privé.

Étapes de diagnostic supplémentaires pour les utilisateurs de cloud privé Edge uniquement

Si vous utilisez un cloud privé Apigee Edge, vous pouvez effectuer les étapes suivantes pour vérifier la cause de l'erreur de handshake. Au cours de cette étape, vous allez rechercher des informations pertinentes dans le fichier journal du processeur de messages. Si vous êtes sur Edge Public Cloud, vous pouvez ignorer cette section et passer à Further Diagnostic steps for Private and Public Cloud Users (Autres étapes de diagnostic pour les utilisateurs de cloud public et privé).

Vérifiez si vous pouvez vous connecter au serveur backend spécifique directement depuis chacun des processeurs de messages à l'aide de la commande telnet:
1. Si la résolution du serveur backend est une seule adresse IP, utilisez la commande suivante:
```
telnet BackendServer-IPaddress 443
```
2. Si la résolution du serveur backend correspond à plusieurs adresses IP, utilisez le nom d'hôte du serveur backend dans la commande telnet, comme indiqué ci-dessous:
```
telnet BackendServer-HostName 443
```
Si vous parvenez à vous connecter au serveur backend sans erreur, passez à l'étape suivante.

Si la commande telnet échoue, vous devez contacter votre équipe réseau pour vérifier la connectivité entre le processeur de messages et le serveur backend.
Vérifiez que le fichier journal du processeur de messages contient des preuves d'échec du handshake. Ouvrez le fichier:

/opt/apigee/var/log/edge-message-processor/system.log

et recherchez l'ID unique du message (la valeur de X-Apigee.Message-ID que vous avez trouvée dans le fichier de suivi). Déterminez si un message d'erreur de handshake associé à l'ID de message s'affiche, comme indiqué ci-dessous:
```
org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout
```

Si cette erreur apparaît dans le fichier journal du processeur de messages, poursuivez vos recherches. Accédez à la section Autres étapes de diagnostic pour les utilisateurs de cloud privé et public Edge.

Si le message de handshake ne s'affiche pas dans le fichier journal, consultez la section Recueillir des informations de diagnostic.

Autres étapes de diagnostic pour les utilisateurs de cloud privé et public Edge

Pour mieux cerner le problème, vous pouvez analyser les paquets TCP/IP à l'aide de l'outil tcpdump afin de vérifier si le délai a expiré lors du handshake TLS/SSL.

Si vous êtes un utilisateur du cloud privé, vous pouvez capturer les paquets TCP/IP sur le serveur backend ou sur le processeur de messages. De préférence, capturez-les sur le serveur backend, car les paquets sont déchiffrés sur le serveur backend.
Si vous êtes un utilisateur du cloud public, vous n'avez pas accès au processeur de messages. Toutefois, la capture des paquets TCP/IP sur le serveur backend peut aider à identifier un problème.
Une fois que vous avez décidé où capturer les paquets TCP/IP, exécutez la commande tcpdump suivante pour capturer les paquets TCP/IP.
```
tcpdump -i any -s 0 host <IP address> -w <File name>
```
- Si vous prenez les paquets TCP/IP sur le serveur backend, utilisez l'adresse IP publique du processeur de messages dans la commande tcpdump. Si vous avez besoin d'aide pour examiner le trafic du serveur backend à l'aide de la commande, consultez la section tcpdump.
- Si vous prenez les paquets TCP/IP sur le processeur de messages, utilisez l'adresse IP publique du serveur backend dans la commande tcpdump. Pour obtenir de l'aide sur l'utilisation de la commande afin d'examiner le trafic du processeur de messages, consultez tcpdump.
- S'il existe plusieurs adresses IP pour le serveur backend/le processeur de messages, vous devez essayer une autre utilisation de la commande tcpdump. Pour plus d'informations sur cet outil et pour découvrir d'autres variantes de cette commande, reportez-vous à la section tcpdump.
Analysez les paquets TCP/IP à l'aide de l'outil Wireshark ou d'un outil similaire. La capture d'écran suivante montre les paquets TCP/IP dans Wireshark.
Vous remarquerez dans la sortie de Wireshark que le handshake TCP à trois voies aboutit dans les trois premiers paquets.
Le processeur de messages envoie ensuite le message "Client Hello" dans le paquet n° 4.
Comme il n'y a pas d'accusé de réception de la part du serveur backend, le processeur de messages retransmet le message "Client Hello" plusieurs fois dans les paquets 5, 6 et 7 après avoir attendu un intervalle de temps prédéfini.
Lorsque le processeur de messages ne reçoit aucun accusé de réception après trois tentatives, il envoie le message FIN, ACK au serveur backend pour indiquer qu'il ferme la connexion.
Comme vous l'avez montré dans l'exemple de session Wireshark, la connexion au backend est réussie (étape 1). Cependant, le handshake SSL a expiré, car le serveur backend n'a jamais répondu.

Si vous avez suivi les étapes de dépannage de ce playbook et déterminé qu'un délai d'inactivité a causé l'erreur de handshake TLS/SSL, accédez à la section Résolution.

Identifier un problème à l'aide de la surveillance des API

La surveillance des API vous permet d'isoler rapidement les problèmes afin de diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, par exemple les applications de développement, les proxys d'API, les cibles de backend ou la plate-forme d'API.

Suivez un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de la surveillance des API. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre d'erreurs messaging.adaptors.http.BadGateway dépasse un certain seuil.

Résolution

En règle générale, les délais avant expiration du handshake SSL se produisent en raison de restrictions de pare-feu sur le serveur backend qui bloquent le trafic provenant d'Apigee Edge. Si vous avez suivi les étapes de diagnostic et déterminé que la cause de l'erreur de handshake est un délai d'inactivité, vous devez engager votre équipe réseau pour identifier la cause et corriger les restrictions de pare-feu.

Notez que les restrictions du pare-feu peuvent être imposées à différentes couches réseau. Il est important de s'assurer que les restrictions sur toutes les couches réseau concernant les adresses IP du processeur de messages sont supprimées afin de garantir un flux de trafic fluide entre Apigee Edge et le serveur backend.

S'il n'y a pas de restrictions de pare-feu et/ou que le problème persiste, consultez Collecte des informations de diagnostic obligatoire.

Doit recueillir des informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez-les et partagez-les avec l'assistance Apigee Edge:

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes :
1. Nom de l'organisation
2. Nom de l'environnement
3. Nom du proxy d'API
4. Exécuter la commande curl pour reproduire l'erreur
5. Fichier de suivi affichant l'erreur
6. Paquets TCP/IP capturés sur le serveur backend
Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
1. Message d'erreur complet observé
2. Groupe de proxys d'API
3. Fichier de suivi affichant l'erreur
4. Journaux du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Paquets TCP/IP capturés sur le serveur backend ou sur le processeur de messages
Informations sur les sections du playbook que vous avez essayées et sur d'autres informations qui nous aideront à accélérer la résolution de ce problème.