503 Service indisponible - Échec de la création du tunnel proxy avec 403

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X. info

Problème constaté

L'application cliente reçoit un code d'état HTTP de 503 Service Unavailable avec le code d'erreur protocol.http.ProxyTunnelCreationFailed en réponse aux appels d'API.

Message d'erreur

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

HTTP/1.1 503 Service Unavailable

Vous pouvez également observer le message d'erreur suivant :

{
   "fault":{
      "faultstring":"Proxy refused to create tunnel with response status 403",
      "detail":{
         "errorcode":"protocol.http.ProxyTunnelCreationFailed"
      }
   }
}

Proxy de transfert et tunneling

Apigee Edge permet à vos proxys d'API de communiquer avec votre serveur backend via un serveur proxy, comme expliqué dans Configurer un proxy de transfert. Le serveur proxy ouvre une connexion sécurisée (HTTPS) ou non sécurisée (HTTP) au serveur backend en fonction du type de proxy (indiqué par la propriété HTTPClient.proxy.type) utilisé, et transfère les données dans les deux sens. C'est ce qu'on appelle le tunneling.

Par défaut, Apigee Edge utilise le tunneling pour tout le trafic. Pour désactiver le tunneling, la propriété HTTPClient.use.tunneling doit être définie sur false.

Code d'erreur : protocol.http.ProxyTunnelCreationFailed

Apigee Edge renvoie le code d'erreur protocol.http.ProxyTunnelCreationFailed si le serveur proxy ne parvient pas à créer un tunnel entre Apigee Edge et le serveur backend en raison de problèmes tels que le pare-feu, les restrictions de liste de contrôle d'accès (LCA), les problèmes DNS, l'indisponibilité du serveur backend, les délais avant expiration, etc.

Le code d'état dans le faultstring de la réponse d'Apigee Edge indique généralement une cause possible de haut niveau qui a entraîné cette erreur.

Modèle de faultstring :

Proxy refused to create tunnel with response status STATUS_CODE

Causes possibles de certains codes d'état observés dans faultstring :

Le tableau suivant décrit les causes possibles en fonction du code d'état indiqué dans le faultstring :

En fonction du code d'état observé dans le faultstring, vous devez utiliser les techniques appropriées pour résoudre le problème. Ce guide explique comment résoudre le problème si vous observez le code d'état 403 dans le faultstring pour le code d'erreur protocol.http.ProxyTunnelCreationFailed.

Causes possibles

Cette erreur (code d'état 403) se produit si des restrictions de pare-feu ou de liste de contrôle d'accès (LCA) sont configurées sur le serveur backend et empêchent le serveur proxy de créer le tunnel entre Apigee Edge et le serveur backend.

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

Cause : le proxy a refusé de créer un tunnel avec l'état de réponse 403

Diagnostic

1. Déterminez le code d'erreur et la source de l'erreur pour 503 Service Unavailable à l'aide de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes.
2. Examinez le message d'erreur et déterminez le code d'état indiqué dans le faultstring en cas d'échec de la création du tunnel.
3. Dans ce scénario, le code d'état est 403, ce qui signifie Interdit.
4. Cela signifie que les droits ou privilèges sont insuffisants pour créer le tunnel. Cela peut généralement se produire si des restrictions de pare-feu ou de liste de contrôle d'accès (LCA) empêchent la création du tunnel.
5. Examinez les restrictions de pare-feu et/ou de LCA configurées sur votre serveur backend qui peuvent empêcher la création du tunnel.
6. En fonction du type de restrictions de pare-feu et/ou de LCA, vous devez résoudre le problème de manière appropriée.

7. Prenons l'exemple d'une restriction de pare-feu pour expliquer comment résoudre ce problème :

   Scénario : la restriction de pare-feu sur le serveur backend s'attend à ce que l'en-tête d'hôte contienne toujours le nom d'hôte du serveur backend

   Vous pouvez utiliser l'une des méthodes suivantes pour déterminer l'en-tête d'hôte transmis par Apigee Edge :

   Trace

   Pour déterminer l'en-tête d'hôte à l'aide de Trace :

   1. Assurez-vous que le faultstring contient Proxy refused to create tunnel with response status 403 à l'aide de la trace, comme expliqué dans Étapes de diagnostic courantes.
   2. Accédez à la phase Target Request Flow Started et examinez les Request Headers
   3. Vérifiez la valeur du nom d'hôte spécifié dans l'en-tête d'hôte de la section En-têtes de requête.
   4. Si l'en-tête Host contient le nom d'hôte du proxy, il s'agit de la cause de cette erreur.
   5. En effet, le pare-feu est configuré sur le serveur backend pour n'accepter les requêtes que si l'en-tête d'hôte contient le nom du serveur backend.
   6. Ainsi, lorsque le serveur proxy tente de créer le tunnel avec le serveur backend, il échoue avec l'erreur

      Proxy refused to create tunnel with response status 403.

      Exemple de trace montrant que l'en-tête d'hôte contient le nom d'hôte du proxy

      ( Agrandir l'image)

      

      Dans l'exemple de trace ci-dessus, l'en-tête d'hôte contient le nom de l'hôte proxy www.proxyserver.com. Étant donné qu'une restriction de pare-feu est configurée sur le serveur backend et qu'elle ne s'attend à ce que le nom d'hôte du serveur backend soit contenu dans l' en-tête d'hôte, vous obtenez l' erreur Proxy refused to create tunnel with response status 403.

   tcpdump

   Pour déterminer l'en-tête d'hôte à l'aide de tcpdump

   1. Capturez un tcpdump sur le serveur proxy pour les requêtes provenant de le composant de processeur de messages d'Apigee Edge avec la commande suivante :

      tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
      

      Pour en savoir plus sur l'utilisation de la commande tcpdump, consultez tcpdump.

   2. Analysez les données tcpdump à l'aide de l'outil Wireshark ou d'un outil similaire.

   3. Voici un exemple d'analyse du tcpdump à l'aide de Wireshark :

      ( Agrandir l'image)

      
   4. Les numéros de paquet 13, 14 et 15 indiquent que le processeur de messages établit une connexion au serveur proxy via un processus de handshake TCP en trois étapes.
   5. Dans le paquet 16, le processeur de messages s'est connecté à l'hôte proxy httpbin.org (illustré dans l'exemple ci-dessus).

   6. Sélectionnez le paquet 16 et examinez en détail le contenu du paquet, et en particulier l'en-tête d'hôte transmis au serveur proxy par le processeur de messages.

      
   7. L'exemple ci-dessus montre l'en-tête d'hôte httpin.org, qui est le nom d'hôte du serveur proxy. Par conséquent, lorsque le serveur proxy tente de créer le tunnel avec le serveur backend en transmettant le Host Header httpin.org ci-dessus, il échoue avec l'erreur Proxy refused to create tunnel with response status 403.

Solution

Scénario : la restriction de pare-feu sur le serveur proxy s'attend à ce que l'en-tête d'hôte contienne toujours le nom d'hôte du serveur backend

Si vous avez déterminé que cette erreur est due au fait que le pare-feu du serveur backend est configuré de sorte qu'il s'attend à ce que l'en-tête d'hôte contienne toujours le nom d'hôte du serveur backend, tandis que le processeur de messages envoie le nom d'hôte du serveur proxy, procédez comme suit pour résoudre le problème :

1. Définissez la propriété use.proxy.host.header.with.target.uri sur "true" dans le TargetEndpoint, comme illustré dans l'exemple suivant :

   Exemple de configuration de TargetEndpoint :

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="use.proxy.host.header.with.target.uri">true</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

2. Assurez-vous que les autres propriétés liées au proxy de transfert sont configurées sur le processeur de messages comme suit :

   1. Examinez le fichier /opt/apigee/customer/application/message-processor.properties sur chacun des processeurs de messages.

   2. Assurez-vous que les propriétés suivantes sont définies en fonction de votre cas d'utilisation ou de vos exigences :

      Exemples de valeurs pour les propriétés :

      conf_http_HTTPClient.use.proxy=true
      conf/http.properties+HTTPClient.proxy.type=HTTP
      conf/http.properties+HTTPClient.proxy.host=PROXY_SERVER_HOST_NAME
      conf/http.properties+HTTPClient.proxy.port=PORT_#
      conf/http.properties+HTTPClient.proxy.user=USERNAME
      conf/http.properties+HTTPClient.proxy.password=PASSWORD

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 Edge :

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

• Message d'erreur complet observé pour les requêtes ayant échoué
• Nom de l'environnement
• Bundle de proxy d'API
• Fichier de trace pour les requêtes API

• Journaux d'accès NGINX

  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Où : ORG, ENV et PORT# sont remplacés par des valeurs réelles.

• Journaux système du processeur de messages

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

Références

• Configurer un proxy de transfert
• Tunneling SSL