Error 503 de servicio no disponible del intercambio de tráfico entre VPC con TARGET_CONNECT_TIMEOUT

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 la supervisión de API, la 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 cuando se usa el intercambio de tráfico de VPC.

El error no debe confundirse con otros errores de tiempo de espera, como 504 Gateway Timeout.

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 la configuración de Apigee 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 las 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 del puerto IP de NAT	No hay suficientes puertos NAT alojados para el tráfico.
El valor de connect.timeout.millis es demasiado bajo	La configuración del tiempo de espera de conexión es demasiado baja del lado de Apigee.

Pasos comunes de diagnóstico

La depuración es una herramienta esencial que permite capturar y evaluar los siguientes detalles del problema:

Duración total de la solicitud Por lo general, toma tres segundos (el valor predeterminado connect.timeout.millis) hasta que se produce un tiempo de espera de conexión. Si notas 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 puede indicar un problema relacionado con el DNS. También puedes notar una correlación entre las diferentes IP de destino y el problema.
Frecuencia. Se necesitan diferentes enfoques en función de si el problema es intermitente o persistente.

Causa: Configuración incorrecta de la ruta

Diagnóstico

Si el problema es persistente, incluso si comenzó hace poco, puede deberse a una configuración incorrecta de la ruta.

Esto podría afectar a objetivos internos (enrutados dentro de la VPC con intercambio de tráfico) y externos (Internet).

Primero, identifica la dirección IP del destino que se resolvió a partir de 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 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 alcanzar el 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.
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.
En el proyecto que intercambia 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 una VPC compartida, esos pasos deben realizarse en el proyecto host en lugar del proyecto de Apigee.
Haz clic en servicenetworking-googleapis-com, selecciona la pestaña servicenetworking-googleapis-com y filtra por la región que se obtuvo en el Paso 2.

En este ejemplo, se muestra la ruta 10.2.0.0/24 como se exportó y se incluye la IP de destino de ejemplo 10.2.0.1. Si no ves una ruta correspondiente a tu destino, esa es la causa del problema.
Nota: Si el destino es externo, las rutas normalmente no están presentes en Rutas exportadas y las solicitudes de Apigee se enrutan directamente a Internet. Este puede no ser siempre, así que asegúrate de aclarar la topología de red deseada. Por ejemplo, si los Controles del servicio de VPC están habilitados, también debes exportar las rutas predeterminadas o de otras rutas para llegar a objetivos externos.

Solución

Revisa la arquitectura de tu red y asegúrate de que las rutas se exporten al intercambio de tráfico de VPC con Apigee. Lo más probable es que la ruta faltante 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.

Puedes leer Patrones de herramientas de redes descendentes para obtener más información.

Causa: Problema de conectividad en el destino

Diagnóstico

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

Prueba de conectividad (direcciones IP de destino privado)

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

Identifica la dirección IP del destino que se resolvió en 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 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.
Ten en cuenta la dirección IP de la instancia de Apigee que no puede conectarse al destino. En Instancias en la consola de Apigee, busca la dirección IP de la instancia de Apigee en el campo Dirección IP.
Ve a Pruebas de conectividad y haz clic en Crear prueba de conectividad. Proporciona estos detalles:
1. Dirección IP de origen: Usa la IP de la instancia de Apigee que se obtuvo 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 proporciona el proyecto y la red.
3. Ingresa la dirección de destino (Paso 1) y el puerto como la Dirección IP de destino y el Puerto de destino respectivamente.
Haz clic en Crear y espera a que la prueba termine la primera ejecución.
En la lista de pruebas de conectividad, haz clic en Ver para ver los resultados de la ejecución.
Si el resultado es “No accesible”, significa que tienes un problema con la configuración. La herramienta debería dirigirte a la documentación de estados de las pruebas de conectividad para continuar. Si el estado es "Accesible", se descartarán muchos problemas de configuración. Sin embargo, esto no garantiza que se pueda alcanzar el objetivo. No hubo un intento real de establecer una conexión TCP con el destino. Solo el siguiente diagnóstico ayudará a probarla.

Prueba de conectividad de VM (todos los destinos)

En la misma VPC que intercambia tráfico con Apigee, crea una instancia de VM en Linux.
Realiza pruebas de conectividad desde la VM, preferentemente 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
```
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. no confirman el tiempo de espera de conexión y no están relacionados con este problema.
Si el destino requiere una lista de entidades permitidas de IP, es posible que no puedas probarla desde una VM, a menos que también incluyas la IP de origen de la instancia de VM en la lista de entidades permitidas.

Solución

Si identificaste un problema según 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 una guía definida sobre cómo resolver el problema en el lado del destino. Una vez que el tiempo de espera de la conexión se pueda reproducir fuera de Apigee, busca el problema más allá de la VPC. Intenta probar la conectividad lo más cerca posible del destino.

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 las horas pico, es posible que el objetivo esté sobrecargado con 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 afecta a los destinos externos (Internet) que tienen habilitada la lista de IP permitidas. Asegúrate de que todas las IP de NAT de Apigee se agreguen en el lado de 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 puedas encontrar una correlación entre las IP de NAT específicas 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 en el destino.

Si el problema es intermitente, esto puede indicar que solo se incluyó un subconjunto de IP de NAT en la lista de entidades permitidas en el destino. Para identificarlo, haz lo siguiente:

Crea un proxy inverso nuevo en el que el destino afectado se especifique en el TargetEndpoint. También puedes volver a usar el proxy existente y continuar con el siguiente paso:
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 muestre la dirección IP del emisor 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 de la misma manera que en el proxy afectado.

Nota: La solicitud ServiceCallout y la solicitud de destino deben ocurrir en una sola transacción. Esto garantiza que el mismo servidor procese una solicitud para que la IP de NAT de la solicitud afectada coincida con la IP de NAT que se obtuvo del ServiceCallout.
Ejecuta una sesión de Debug y haz clic en el paso ServiceCallout:
En la esquina inferior derecha, deberías ver una sección Contenido de 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 un lugar diferente, deberías verla allí.

Ten en cuenta que, más adelante en el flujo, el proxy llamará al destino y el contenido de respuesta se reemplazará por el error o una respuesta del objetivo.
Intenta correlacionar las IP NAT con el problema. Si notas que solo fallan direcciones IP específicas, esto significa que algunas, pero no todas las IP, están en la lista de entidades permitidas en el destino.
Si no ves una correlación entre las IP de NAT y los errores, por ejemplo, si la misma IP falla en una solicitud, pero no en la otra, es probable que este no sea un problema de lista de entidades permitidas. Esto podría ser un agotamiento de la NAT. Consulta Causa: Agotamiento del puerto IP de NAT.

Solución

Asegúrate de tener IP NAT aprovisionadas y activadas y asegúrate de que todas estén agregadas en el lado de destino.

Causa: Agotamiento del puerto IP de NAT

Diagnóstico

Si el problema solo se puede reproducir desde Apigee y se aprovisionan las IP de NAT a tu organización y ves que sucede para diferentes destinos al mismo tiempo, es posible que estés ejecutando fuera de los puertos de origen de NAT:

Ten en cuenta el período del problema. Por ejemplo, todos los días entre las 5:58 p.m. y las 6:08 p.m.
Confirma si el problema afecta a algún otro destino 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 afectado original.
Establece si los errores solo ocurren por encima de un volumen de tráfico determinado en TPS. Para ello, observa el período del problema y navega al panel Rendimiento del proxy.
Intenta correlacionar el periodo de tiempo de error con el aumento en el promedio de transacciones por segundo (tps).

En este ejemplo, el valor de tps aumenta a 1,000 a las 5:58 p.m. Si suponemos que en este ejemplo, a las 5:58 p.m. es exactamente el momento en que ocurre el problema y que afecta a dos o más objetivos no relacionados, es una señal de un problema con el agotamiento de la NAT.

Solución

Vuelve a calcular los requisitos de IP NAT con las instrucciones que aparecen en Calcula los requisitos de IP NAT estáticas.

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

Causa: El valor connect.timeout.millis es demasiado bajo

Diagnóstico

Es posible que tengas un valor de tiempo de espera configurado de forma incorrecta 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, esa es la causa del problema. Si no ves la propiedad “connect.timeout.millis”, entonces, se establece el valor predeterminado y la causa no se confirma.

Proxy con tiempo de espera

Solución

Corrige el valor 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, que es 3,000 milisegundos. Si quieres obtener más información, consulta la referencia de 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 la Asistencia de Google Cloud:

ID del proyecto y nombre de la organización de Apigee
Nombres de proxy y el entorno
Período del problema.
Frecuencia del problema
Nombre de host de destino
Sesión de depuración con el problema.
Resultados de las comprobaciones realizadas para las posibles causas anteriores. Por ejemplo, el resultado del comando curl de una VM