Vous consultez la documentation Apigee Edge.
Accédez à la
documentation**Apigee X**. info
Problème constaté
L'application cliente reçoit une erreur 502 : 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
Vous pouvez également observer le message d'erreur suivant :
{
"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 | Procédure de dépannage pouvant être effectuée par |
| Délai avant expiration du handshake TLS/SSL | Un délai avant expiration se produit lors du handshake TLS/SSL entre le processeur de messages et le serveur backend. | Utilisateurs du 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 comporte plusieurs étapes. Cette erreur se produit généralement lorsque le délai avant expiration du handshake TLS/SSL entre le processeur de messages et un serveur backend est dépassé.
Diagnostic
Cette section explique comment diagnostiquer correctement un délai avant expiration du handshake TLS/SSL. Les instructions pour le cloud privé et public Edge sont listées.
Examiner la sortie de la session Trace
Les étapes suivantes expliquent comment effectuer un diagnostic préliminaire du problème à l'aide de l'outil Trace d'Apigee Edge.
- Dans l'interface utilisateur Edge, activez une session Trace pour le proxy d'API concerné.
Si la trace de la requête d'API ayant échoué affiche les informations suivantes, il est probable qu'une erreur de délai avant expiration du handshake TLS/SSL s'est produite. La cause probable de l'erreur est que le pare-feu du serveur backend bloque le trafic provenant d'Apigee.
- Déterminez si l'erreur 502 : passerelle incorrecte se produit après 55 secondes, qui correspond au délai avant expiration par défaut défini sur le processeur de messages. Si l'erreur s'est produite après 55 secondes, cela indique qu'un délai avant expiration est la cause probable du problème.
- Déterminez si l'erreur affiche la défaillance : messaging.adaptors.http.BadGateway. Encore une fois, cette erreur indique généralement qu'un délai avant expiration s'est produit.
Si vous utilisez Edge Private Cloud, notez la valeur du X-Apigee.Message-ID champ dans la sortie de trace, comme indiqué ci-dessous. Un utilisateur du cloud privé peut utiliser cette valeur d'ID pour effectuer un dépannage plus approfondi, comme expliqué plus loin.
Cliquez sur l'icône Analytics Data Recorded (Données Analytics enregistrées) dans le chemin de trace :
Faites défiler la page vers le bas et notez la valeur du champ X-Apigee.Message-ID.
Pour confirmer que le délai avant expiration du handshake TLS/SSL est la cause de l'erreur, suivez les étapes décrites dans les sections suivantes, selon que vous utilisez le cloud public ou privé.
Étapes de diagnostic supplémentaires pour les utilisateurs d'Edge Private Cloud uniquement
Si vous utilisez Apigee Edge Private Cloud, vous pouvez suivre les étapes ci-dessous pour vérifier la cause de l'erreur de handshake. À cette étape, vous inspectez le fichier journal du processeur de messages pour obtenir des informations pertinentes. Si vous utilisez Edge Public Cloud, vous pouvez ignorer cette section et passer à la section Étapes de diagnostic supplémentaires pour les utilisateurs du cloud privé et public.
Vérifiez si vous pouvez vous connecter directement au serveur backend spécifique à partir de chacun des processeurs de messages à l'aide de la commande
telnet:Si le serveur backend est résolu en une seule adresse IP, utilisez la commande suivante :
telnet BackendServer-IPaddress 443
Si le serveur backend est résolu en 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 collaborer avec votre équipe réseau pour vérifier la connectivité entre le processeur de messages et le serveur backend.Recherchez dans le fichier journal du processeur de messages des preuves d'un échec de handshake. Ouvrez le fichier :
/opt/apigee/var/log/edge-message-processor/system.loget recherchez l'ID de message unique (la valeur de X-Apigee.Message-ID que vous avez trouvée dans le fichier de trace). 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 s'affiche dans le fichier journal du processeur de messages, poursuivez votre investigation. Passez à la section Étapes de diagnostic supplémentaires pour les utilisateurs d'Edge Private Cloud et Public Cloud.
Si le message de handshake ne s'affiche pas dans le fichier journal, consultez la section Vous devez collecter des informations de diagnostic
Étapes de diagnostic supplémentaires pour les utilisateurs d'Edge Private Cloud et Public Cloud
Pour identifier plus précisément le problème, vous pouvez utiliser l'outil tcpdump afin d'analyser les paquets TCP/IP et confirmer si un délai avant expiration s'est produit 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 le processeur de messages. Il est préférable de les capturer sur le serveur backend, car les paquets y sont déchiffrés.
- 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 vous aider à identifier un problème .
Après avoir décidé où capturer les paquets TCP/IP, utilisez la commande tcpdump suivante pour les capturer.
tcpdump -i any -s 0 host <IP address> -w <File name>Si vous capturez les paquets TCP/IP sur le serveur backend, utilisez l'adresse IP publique du processeur de messages dans la commande
tcpdump. Pour obtenir de l'aide sur l'utilisation de la commande afin d'examiner le trafic du serveur backend, consultez tcpdump.Si vous capturez 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/processeur de messages, vous devez essayer une autre utilisation de la commande
tcpdump. Pour en savoir plus sur cet outil et ses autres variantes, consultez 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.
Notez dans la sortie Wireshark que le handshake TCP en trois étapes se termine correctement dans les trois premiers paquets.
Le processeur de messages envoie ensuite le message "Client Hello" dans le paquet n° 4.
Comme le serveur backend n'envoie pas d'accusé de réception, 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 indiqué dans l'exemple de session Wireshark, la connexion au backend est établie (étape 1). Toutefois, le délai avant expiration du handshake SSL a été dépassé, car le serveur backend n'a jamais répondu.
Si vous avez suivi les étapes de dépannage décrites dans ce guide et déterminé qu'un délai avant expiration est à l'origine de l'erreur de handshake TLS/SSL, passez à la section Solution.
Utiliser API Monitoring pour identifier un problème
API Monitoring vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, tels que les applications de développeur, les proxys d'API, les cibles 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 d'API Monitoring. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de défaillances messaging.adaptors.http.BadGateway dépasse un seuil particulier.
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 avant expiration, vous devez contacter votre équipe réseau pour identifier la cause et corriger les restrictions de pare-feu.
Notez que les restrictions de pare-feu peuvent être imposées à différentes couches réseau. Il est important de s'assurer que les restrictions de toutes les couches réseau sont supprimées concernant les adresses IP du processeur de messages 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 si le problème persiste, consultez la section Vous devez collecter des informations de diagnostic.
Vous devez collecter des informations de diagnostic
Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez collecter les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez-les avec elle :
- Si vous êtes un utilisateur du cloud public, fournissez les informations suivantes :
- Nom de l'organisation
- Nom de l'environnement
- Nom du proxy d'API
- Commande curl complète pour reproduire l'erreur
- Fichier de trace indiquant l'erreur
- Paquets TCP/IP capturés sur le serveur backend
- Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :
- Message d'erreur complet observé
- Bundle de proxy d'API
- Fichier de trace indiquant l'erreur
- Journaux du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log
- Paquets TCP/IP capturés sur le serveur backend ou le processeur de messages.
- Détails sur les sections de ce guide que vous avez essayées et toute autre information qui nous aidera à accélérer la résolution de ce problème.