Error 503 de servicio no disponible con TARGET_CONNECT_TIMEOUT (objetivos de intercambio de tráfico entre Internet y VPC)

Estás viendo la documentación de Apigee y Apigee hybrid.
No hay documentación de Apigee Edge equivalente para este tema.

Síntoma

Este problema aparece como errores "503 - Servicio no disponible" en Supervisión de API, Depuración o en otras herramientas. El motivo "TARGET_CONNECT_TIMEOUT" indica un tiempo de espera de conexión entre la instancia de Apigee y el destino de Internet o un destino al que se puede acceder con el intercambio de tráfico entre VPC.

Este error no se debe confundir con otros errores de tiempo de espera, como el error 504 de tiempo de espera de la puerta de enlace.

Mensaje de error

Este es el error típico en la sesión de depuración o la carga útil de la respuesta. Ten en cuenta el motivo: TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Causas posibles

Ten en cuenta que estas causas son específicas de los destinos de Internet o los destinos a los que se puede acceder con el intercambio de tráfico entre VPC. Consulta Opciones de red de Apigee. Si el destino es PSC (adjunto de extremo), consulta la guía de PSC en su lugar.

Causa	Descripción
Configuración incorrecta de rutas	Las rutas de destino no se exportan al intercambio de tráfico con la instancia de Apigee.
Problema de conectividad en el destino	El destino no siempre puede aceptar una conexión TCP.
Lista de entidades permitidas de IP en el destino con algunas o todas las IPs de NAT de Apigee no agregadas	No todas las IPs de NAT de Apigee están en la lista de entidades permitidas en el destino.
Agotamiento de puertos de IP NAT	No se admiten suficientes puertos NAT para el tráfico.
El valor de connect.timeout.millis está configurado demasiado bajo	El parámetro de configuración de tiempo de espera de conexión es demasiado bajo en el lado de Apigee.

Pasos comunes de diagnóstico

Debug es una herramienta esencial para capturar y evaluar los siguientes detalles sobre el problema:

• Duración total de la solicitud. Por lo general, se necesitan tres segundos (connect.timeout.millis predeterminado) hasta que se agote el tiempo de espera de la conexión. Si observas una duración más baja, verifica la configuración del extremo de destino.
• Nombre de host de destino y dirección IP La dirección IP incorrecta que se muestra podría indicar un problema relacionado con el DNS. También es posible que notes una correlación entre diferentes IPs de destino y el problema.
• Frecuencia. Se necesitan diferentes enfoques según si el problema es intermitente o persistente.

Causa: Configuración incorrecta de la ruta

Diagnóstico

Si el problema persiste, incluso si comenzó recientemente, es posible que se deba a un error de configuración de la ruta.

Esto podría afectar a los destinos internos (enrutados dentro de la VPC interconectada) y externos (Internet).

1. Primero, identifica la dirección IP del destino resuelta desde la instancia de Apigee. Uno de los métodos es usar una sesión de depuración. En Depuración, navega a AnalyticsPublisher (o AX en la depuración clásica):
   
   

   Busca el valor de target.ip en el lado derecho de la pantalla.

   En este ejemplo, la IP es 10.2.0.1. Dado que este rango es privado, requiere que se implementen ciertas medidas de enrutamiento para garantizar que Apigee pueda llegar al destino.

   Ten en cuenta que, si el destino está en Internet, debes seguir este paso si los Controles del servicio de VPC están habilitados para Apigee, ya que eso impide la conectividad a Internet.

2. Toma nota de la región en la que se implementa la instancia de Apigee afectada. En la IU de Apigee en la consola de Cloud, haz clic en Instancias. En el campo Ubicación, puedes encontrar la región exacta de la instancia.
   
   
   
3. En el proyecto que tiene intercambio de tráfico con Apigee, navega a la sección Red de VPC -> Intercambio de tráfico entre redes de VPC en la IU. Ten en cuenta que, si usas la VPC compartida, esos pasos deben realizarse en el proyecto host en lugar del proyecto de Apigee.
   
   
4. Haz clic en servicenetworking-googleapis-com, selecciona la pestaña RUTAS EXPORTADAS y filtra por la región que obtuviste en el paso 2.
   
   En este ejemplo, se muestra la ruta 10.2.0.0/24 tal como se exportó y se incluye la IP de destino de ejemplo 10.2.0.1. Si no ves una ruta que corresponda a tu objetivo, ese es el motivo del problema.
   
   Nota: Si el destino es externo, las rutas no suelen estar presentes en las rutas exportadas y las solicitudes de Apigee se enrutan directamente a Internet. Esto no siempre es así, por lo que debes asegurarte de aclarar la topología de red deseada. Por ejemplo, si los Controles del servicio de VPC están habilitados, también debes exportar rutas predeterminadas o de otro tipo para llegar a destinos externos.
   
   

Solución

Revisa la arquitectura de tu red y asegúrate de que las rutas se exporten al intercambio de tráfico entre VPC y Apigee. Es muy probable que la ruta que falta sea estática o dinámica. La falta de rutas dinámicas necesarias indica un problema con la función correspondiente, por ejemplo, Cloud Interconnect.

Ten en cuenta que no se admite el intercambio de tráfico transitivo. En otras palabras, si la red de VPC N1 intercambia tráfico con las redes N2 y N3, pero estas no están conectadas directamente, la red de VPC N2 no se podrá comunicar con la N3 mediante el intercambio de tráfico entre redes de VPC.

Para obtener más información, puedes leer Patrones de herramientas de redes descendentes.

Causa: Problema de conectividad en el destino

Diagnóstico

Es posible que no se pueda acceder al destino desde la VPC o que no pueda aceptar una conexión. Hay dos opciones disponibles para diagnosticar el problema.

Prueba de conectividad (direcciones IP de destino privadas)

Si el destino está en una red privada, puedes usar la función Prueba de conectividad para diagnosticar las causas comunes.

1. Identifica la dirección IP del destino resuelta desde la instancia de Apigee. Uno de los métodos es usar una sesión de depuración.
   
   En Depuración, navega a AnalyticsPublisher (o AX en la depuración clásica). Busca el valor de target.ip en el lado derecho de la pantalla.
   
   En este ejemplo, la IP es 10.2.0.1. Esta es una dirección IP privada, lo que significa que podemos usar la prueba de conectividad.
   
   
2. Anota la dirección IP de la instancia de Apigee que no se puede conectar al destino. En Instances de la consola de Apigee, busca la dirección IP de la instancia de Apigee en el campo IP Address.
   
   
3. Ve a Pruebas de conectividad y haz clic en Crear prueba de conectividad. Proporciona los siguientes detalles:
   1. Dirección IP de origen: Usa la IP de la instancia de Apigee que obtuviste en el paso 2 anterior. Ten en cuenta que esta no es la IP de origen exacta que usa Apigee para enviar una solicitud al destino, pero es suficiente para la prueba, ya que está en la misma subred.
   2. Esta es una dirección IP que se usa en Google Cloud: Deja desmarcada, a menos que la dirección esté en cualquiera de tus proyectos de Google Cloud. Si verificas este valor, también debes proporcionar el proyecto y la red.
   3. Coloca la dirección de destino (paso 1) y el puerto como la dirección IP de destino y el puerto de destino, respectivamente.
   
4. Haz clic en Crear y espera a que la prueba finalice la primera ejecución.
5. En la lista de pruebas de conectividad, haz clic en Ver para ver los resultados de la ejecución.
6. Si el resultado es "Inaccesible", significa que tienes un problema con la configuración. La herramienta debería dirigirte a la documentación de los estados de las pruebas de conectividad para continuar. Si el estado es "Accesible", se descartan muchos problemas de configuración. Sin embargo, esto no garantiza que se pueda llegar al objetivo. No se intentó establecer una conexión TCP con el destino. Solo el siguiente diagnóstico te ayudará a probarlo.
   
   

Prueba de conectividad de la VM
(todos los destinos)

1. En la misma VPC que se intercambia con Apigee, crea una instancia de VM en Linux.
2. Realiza pruebas de conectividad desde la VM, de preferencia en el momento en que el problema se puede reproducir desde Apigee. Puedes usar telnet, curl y otras utilidades para establecer una conexión. Este ejemplo de curl se ejecuta en un bucle con un tiempo de espera de tres segundos. Si curl no puede establecer una conexión TCP en tres segundos, falla.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. Verifica el resultado completo y busca este error:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   La presencia de este error confirma que el problema se puede reproducir fuera de Apigee.

   Ten en cuenta que, si ves otros errores, como errores relacionados con TLS, códigos de estado incorrectos, etcétera, No confirman el tiempo de espera de conexión y no están relacionados con este problema.

4. Si el destino requiere una lista de IP de permiso, es posible que no puedas probarlo desde una VM, a menos que también agregues a la lista de permiso la IP de origen de la instancia de VM.

Solución

Si identificaste un problema en función de las pruebas de conectividad, continúa con los pasos de resolución documentados.

Si el tiempo de espera se reproduce desde una VM, no hay orientación definitiva sobre cómo resolver el problema del lado del destino. Una vez que se pueda reproducir el tiempo de espera de conexión fuera de Apigee, continúa investigando el problema desde la VPC. Intenta probar la conectividad lo más cerca posible del objetivo.

Si el destino está detrás de una conexión de VPN, es posible que también puedas probarlo desde la red local.

Si el destino está en Internet, puedes intentar reproducir el problema fuera de la consola de Google Cloud.

Si el problema ocurre en horas pico, es posible que el objetivo esté sobrecargado de conexiones.

Si necesitas generar un caso de asistencia de Google Cloud en esa etapa, ya no necesitas seleccionar el componente de Apigee, ya que el problema ahora se puede reproducir directamente desde la VPC.

Causa: Lista de entidades permitidas de IP en el destino con algunas o todas las IPs de NAT de Apigee no agregadas

Diagnóstico

Esto se relaciona con los destinos externos (Internet) que tienen habilitada la lista de IPs permitidas. Asegúrate de que todas las IPs de NAT de Apigee se agreguen en el destino afectado. Si no hay una lista de entidades permitidas en el destino, puedes omitir esta sección.

El problema es más fácil de detectar si los errores son intermitentes, ya que, en ese caso, es posible que encuentres una correlación entre las IPs de NAT particulares y los errores.

Si el problema es persistente (todas las llamadas fallan), asegúrate de que las IP de NAT estén habilitadas en Apigee y recupéralas mediante estos pasos:

Obtén una lista de las IP NAT de una instancia:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Una respuesta de ejemplo:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Si no recibes ninguna dirección en el resultado, significa que las IP de NAT no se agregaron en Apigee. Si obtienes direcciones, pero ninguna de ellas tiene estado ACTIVE, entonces ninguna de las direcciones usadas permite el acceso a Internet, lo que también es un problema.

Si tienes al menos una dirección con estado ACTIVE, se puede incluir en la lista de entidades permitidas en el destino, por lo que no hay una configuración incorrecta del lado de Apigee. En ese caso, es posible que falte la dirección en la lista de entidades permitidas del destino.

Si el problema es intermitente, es posible que solo se haya incluido en la lista de entidades permitidas en el destino un subconjunto de IPs de NAT. Para identificarlo, haz lo siguiente:

1. Crea un nuevo proxy inverso en el que se especifica el destino afectado en TargetEndpoint. También puedes reutilizar el proxy existente y pasar al siguiente paso:
   
   
2. Agrega una política ServiceCallout al flujo previo de solicitud. El ServiceCallout debe llamar a "https://icanhazip.com", "https://mocktarget.apigee.net/ip" o cualquier otro extremo público que devuelva la dirección IP del llamador en la respuesta. Almacena la respuesta en la variable "response" para que el contenido sea visible en Debug. Este es un ejemplo de configuración de la política de ServiceCallout:
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   También puedes almacenar la respuesta en una variable personalizada, pero deberás leer el ".content" de esa variable con la política de AssignMessage para revelarla en la herramienta de depuración.

   Asegúrate de que el destino esté configurado exactamente de la misma manera que en el proxy afectado.

   Nota: La solicitud de ServiceCallout y la solicitud de Target deben ocurrir en una sola transacción. Esto garantiza que el mismo servidor procese una solicitud, de modo que la IP de NAT de la solicitud afectada coincida con la IP de NAT obtenida de ServiceCallout.
3. Ejecuta una sesión de depuración y haz clic en el paso ServiceCallout:
   
   
4. En la esquina inferior derecha, deberías ver una sección Contenido de la respuesta que contiene la IP de NAT (en el cuerpo) de la instancia de Apigee que realiza la solicitud. Como alternativa, si almacenas la respuesta de ServiceCallout en otro lugar, deberías verla allí.
   
   Ten en cuenta que, más adelante en el flujo, el proxy llamará al destino y el contenido de la respuesta se sobrescribirá con el error o una respuesta del destino.
5. Intenta correlacionar las IPs de NAT con el problema. Si notas que solo fallan IPs específicas, esto indica que algunas IPs, pero no todas, están en la lista de entidades permitidas en el destino.
6. Si no ves una correlación entre las IPs de NAT y los errores, por ejemplo, si la misma IP falla en una solicitud, pero no en la otra, es muy probable que no se trate de un problema de lista de IPs permitidas. Es posible que se trate de un agotamiento de NAT. Consulta Causa: Agotamiento de puertos de IP de NAT.

Solución

Asegúrate de tener IPs de NAT aprovisionadas y activadas, y de que todas se hayan agregado en el destino.

Causa: Agotamiento de puertos de IP de NAT

Diagnóstico

Nota: Esta causa no es común y es relevante si el problema no se puede reproducir desde tu VPC ni desde ningún otro lugar fuera de Apigee. Si no realizaste esa prueba, sigue las instrucciones de la sección Problema de conectividad en el destino que se encuentra más arriba. Esta sección tampoco es relevante si no usas IPs de NAT.

Si el problema solo se reproduce desde Apigee y se aprovisionan IPs de NAT para tu organización, y ves que ocurre para diferentes destinos al mismo tiempo, es posible que te estés quedando sin puertos de origen de NAT:

1. Toma nota del período del problema. Por ejemplo, todos los días entre las 5:58 p.m. y las 6:08 p.m.
2. Confirma si algún otro objetivo se ve afectado por el problema en el mismo período. Ese otro destino debe ser accesible a través de Internet y no debe estar alojado en la misma ubicación que el destino original afectado.
3. Establece si los errores solo ocurren por encima de un cierto volumen de tráfico en TPS. Para ello, anota el período del problema y navega al panel de Rendimiento del proxy.
4. Intenta correlacionar el periodo de tiempo de error con el aumento en el promedio de transacciones por segundo (tps).

En este ejemplo, los TPS aumentan a 1,000 a las 5:58 p.m. Si suponemos que, en este ejemplo, las 5:58 p.m. es exactamente el momento en que ocurre el problema y que este afecta a dos o más destinos no relacionados, esto es un indicador de un problema de agotamiento de NAT.

Solución

Vuelve a calcular tus requisitos de IP NAT con las instrucciones que se indican en Cómo calcular los requisitos de IP NAT estáticas.

También puedes agregar más IPs de NAT y ver si eso resuelve el problema. Ten en cuenta que, para agregar más IPs, es posible que primero debas incluirlas en la lista de entidades permitidas en todos los destinos.

Causa: El valor de connect.timeout.millis está configurado demasiado bajo

Diagnóstico

Es posible que hayas configurado de forma incorrecta el valor de tiempo de espera en el proxy.

Para verificarlo, navega al proxy afectado y, luego, inspecciona el TargetEndpoint en cuestión. Toma nota de la propiedad "connect.timeout.millis" y su valor. En este ejemplo, el valor es 50, que es 50 milisegundos y, por lo general, es demasiado bajo para garantizar que se establezca una conexión TCP. Si ves un valor inferior a 1,000, es probable que esa sea la causa del problema. Si no ves la propiedad "connect.timeout.millis", se estableció el valor predeterminado y no se confirmó la causa.

Solución

Corrige el valor de connect.timeout.millis y asegúrate de tener en cuenta que las unidades de tiempo están en milisegundos. El valor predeterminado es 3,000, lo que equivale a 3,000 milisegundos. Para obtener más información, consulta la referencia de las propiedades de Endpoints.

Comunícate con el equipo de Asistencia para obtener más ayuda

Si el problema persiste después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico para Asistencia de Google Cloud:

1. ID del proyecto y nombre de la organización de Apigee
2. Nombres de proxy y el entorno
3. Período del problema.
4. Frecuencia del problema
5. Nombre de host de destino
6. Sesión de depuración con el problema.
7. Es el resultado de las verificaciones realizadas para las posibles causas mencionadas anteriormente. Por ejemplo, el resultado del comando curl de una VM