Servicio no disponible [503 Service available - Proxytunnel failure with 403]

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 503 Service Unavailable con el código de error protocol.http.ProxyTunnelCreationFailed como respuesta para las llamadas a la API.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 503 Service Unavailable

Además, es posible que observes el siguiente mensaje de error:

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

Proxy de reenvío y tunelización

Apigee Edge permite que tus proxies de API se comuniquen con tu servidor de backend a través de un servidor proxy, como se explica en Configura el proxy de reenvío. El servidor proxy abre una conexión segura (HTTPS) o no segura (HTTP) al servidor de backend según el tipo de proxy (indicado por la propiedad HTTPClient.proxy.type) que se use y transfiere los datos en ambas direcciones. Esto se conoce como tunelización.

De forma predeterminada, Apigee Edge usa la tunelización para todo el tráfico. Para inhabilitar la tunelización, la propiedad HTTPClient.use.tunneling debe establecerse en false.

Código de error: protocol.http.ProxyTunnelCreationFailed

Apigee Edge muestra el código de error protocol.http.ProxyTunnelCreationFailed si el servidor proxy no puede crear un túnel entre Apigee Edge y el servidor de backend debido a problemas como el firewall, las restricciones de la LCA (Lista de control de acceso), problemas de DNS, falta de disponibilidad del servidor de backend, tiempos de espera, etcétera.

El código de estado en el faultstring de la respuesta de Apigee Edge suele indicar una posible causa de alto nivel que provocó este error.

Plantilla de Faultstring:

Proxy refused to create tunnel with response status STATUS_CODE

Causas posibles de algunos de los códigos de estado observados en faultstring:

En la siguiente tabla, se describen las posibles causas según el código de estado indicado en el faultstring:

Según el código de estado observado en el faultstring, debes usar las técnicas adecuadas para solucionar el problema. En este manual, se explica cómo solucionar el problema si observas el código de estado 403 en el faultstring para el código de error protocol.http.ProxyTunnelCreationFailed.

Causas posibles

Este error (código de estado 403) ocurre si hay restricciones de firewall o de LCA (Lista de control de acceso) configuradas en el servidor de backend que impiden que el servidor proxy cree el túnel entre Apigee Edge y el servidor de backend.

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Causa: El proxy se negó a crear un túnel con el estado de respuesta 403

Diagnóstico

1. Determina el código de falla y la fuente de falla para 503 Service Unavailable con la herramienta de Trace o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico.
2. Revisa el mensaje de error y determina el código de estado indicado en el faultstring para la falla en la creación del túnel.
3. En este caso, el código de estado es 403, lo que significa Forbidden.
4. Esto significa que no hay derechos o privilegios suficientes para crear el túnel. Por lo general, esto puede ocurrir si hay restricciones de firewall o de LCA (Lista de control de acceso) que impiden la creación del túnel.
5. Revisa las restricciones de firewall o de LCA que estén configuradas en tu servidor de backend y que puedan impedir la creación del túnel.
6. Según el tipo de firewall o las restricciones de LCA, debes solucionar el problema de forma adecuada.

7. Tomemos como ejemplo una restricción de firewall para explicar cómo solucionar este problema:

   Situación: La restricción de firewall en el servidor de backend espera que el encabezado de host siempre contenga el nombre de host del servidor de backend

   Puedes usar una de las siguientes formas para determinar el encabezado de host que pasa Apigee Edge:

   Seguimiento

   Para determinar el encabezado de host con Trace, haz lo siguiente:

   1. Asegúrate de que el faultstring contenga Proxy refused to create tunnel with response status 403 con el seguimiento, como se explica en Pasos comunes de diagnóstico.
   2. Navega a la fase Target Request Flow Started y revisa los encabezados de solicitud
   3. Verifica el valor del nombre de host especificado en el encabezado de host en la sección Encabezados de solicitud.
   4. Si el encabezado Host contiene el nombre de host del proxy, esa es la causa de este error.
   5. Esto se debe a que el firewall está configurado en el servidor de backend para aceptar las solicitudes solo si el encabezado de host contiene el nombre del servidor de backend.
   6. Por lo tanto, cuando el servidor proxy intenta crear el túnel con el servidor de backend, falla con el error

      Proxy refused to create tunnel with response status 403.

      Seguimiento de muestra que muestra el encabezado de host con el nombre de host del proxy

      ( ver imagen más grande)

      

      En el seguimiento de muestra que se muestra arriba, se indica que el encabezado de host contiene el nombre del host del proxy www.proxyserver.com. Como hay una restricción de firewall configurada en el servidor de backend que espera que solo el nombre de host del servidor de backend esté contenido en el encabezado de host, obtienes el error Proxy refused to create tunnel with response status 403.

   tcpdump

   Para determinar el encabezado de host con tcpdump, haz lo siguiente:

   1. Captura un tcpdump en el servidor proxy para las solicitudes que provienen de el componente Message Processor de Apigee Edge con el siguiente comando:

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

      Para obtener más información sobre el uso del comando tcpdump, consulta tcpdump.

   2. Analiza los datos de tcpdump con la herramienta Wireshark o una similar herramienta.

   3. A continuación, se muestra un análisis de muestra del tcpdump con Wireshark:

      ( ver imagen más grande)

      
   4. Los números de paquete 13, 14 y 15 muestran que el Message Processor establece una conexión con el servidor proxy a través de un proceso de protocolo de enlace TCP de tres vías.
   5. En el paquete 16, el Message Processor se conectó al host del proxy httpbin.org (que se muestra en el ejemplo anterior).

   6. Selecciona el paquete 16 y examina el contenido del paquete en detalle y en particular el encabezado de host que el Message Processor pasa al servidor proxy.

      
   7. En el ejemplo anterior, se muestra el encabezado de host httpin.org, que es el nombre de host del servidor proxy. Por lo tanto, cuando el servidor proxy intenta crear el túnel con el servidor de backend pasando el encabezado de host httpin.org, falla con el error Proxy refused to create tunnel with response status 403.

Solución

Situación: La restricción de firewall en el servidor proxy espera que el encabezado de host siempre contenga el nombre de host del servidor de backend

Si determinaste que este error se produce porque el firewall del servidor de backend está configurado de modo que espera que el encabezado de host siempre contenga el nombre de host del servidor de backend, mientras que el Message Processor envía el nombre de host del servidor proxy, sigue los pasos que se indican a continuación para resolver el problema:

1. Establece la propiedad use.proxy.host.header.with.target.uri en true en el TargetEndpoint, como se muestra en el siguiente ejemplo:

   Configuración de TargetEndpoint de muestra:

   <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. Asegúrate de que las otras propiedades relacionadas con el proxy de reenvío estén configuradas en el Message Processor de la siguiente manera:

   1. Revisa el archivo /opt/apigee/customer/application/message-processor.properties en cada uno de los Message Processors.

   2. Asegúrate de que las siguientes propiedades estén configuradas según tu caso de uso o requisitos:

      Valores de muestra para las propiedades:

      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

Se debe recopilar información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge:

Si eres usuario de la nube privada, proporciona la siguiente información:

• Mensaje de error completo observado para las solicitudes con errores
• Nombre del entorno
• Paquete de proxy de API
• Archivo de seguimiento para las solicitudes a la API

• Registros de acceso de NGINX

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

  Donde: ORG, ENV y PORT# se reemplazan por valores reales.

• Registros del sistema del Message Processor

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

Referencias

• Configura el proxy de reenvío
• Tunelización SSL