Accede a los problemas de enrutamiento con Apigee

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

Síntoma

En algunos casos, los clientes externos no pueden acceder a Apigee de la manera deseada. Esto incluye las fallas de conectividad de red (errores de protocolo de enlace TLS) o las respuestas 4xx/5xx de Apigee.

Mensaje de error

Cuando envías una solicitud a la API de tu cliente a Apigee, verás una falla de protocolo de enlace TLS o una respuesta 4xx/5xx, aunque los proxies de API puedan parecer en buen estado en la IU de Apigee.

Causas posibles

Causa	Descripción	Códigos de error
Errores de TLS en el balanceador de cargas de HTTPS	La configuración de TLS se administra mediante el balanceador de cargas de HTTPS. Investiga cualquier error de TLS en los registros del balanceador de cargas HTTPS.	Errores de protocolo de enlace TLS de la dirección IP del balanceador de cargas
Google Cloud Armor que bloquea las solicitudes	Si usas Google Cloud Armor, es posible que haya una regla que bloquee la solicitud.	El código de respuesta de la API puede variar según la configuración de Google Cloud Armor. Las reglas de denegación pueden mostrar una respuesta `HTTP 403` (no autorizado), `404` (acceso denegado) o `502` (puerta de enlace incorrecta) o, incluso, otro código de respuesta.
Las VM del proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee	La configuración del proxy de tráfico de la API de Apigee y su estado deben investigarse	`502 Server Error`
Configuración de red incorrecta	Asegúrate de que la red correcta intercambia tráfico con la VPC de Apigee.	`502 Server error`
Entornos no conectados en la instancia nueva de Apigee creada como parte de la expansión regional	Después de crear una instancia nueva, por ejemplo, una segunda región, debes adjuntar entornos a ella; de lo contrario, no podrá responder a las solicitudes a la API.	`503 error response`

Causa: Errores de TLS en el balanceador de cargas de HTTPS

Diagnóstico

Busca el certificado TLS asociado con el balanceador de cargas.

Usa Google Cloud Console
1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
  
  Ir a Balanceo de cargas
2. Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
3. En el área Frontend, en la columna IP:Puerto, asegúrate de ver el balanceador de cargas correcto mediante la verificación de la dirección IP y el puerto.
4. En la columna Certificado, haz clic en el nombre del certificado para ver el certificado TLS.

Con un comando de gcloud

Enumera los balanceadores de cargas con el siguiente comando de gcloud. Este comando también muestra SSL_CERTIFICATES asociado a cada balanceador de cargas.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Reemplaza PROJECT_NAME por el nombre del proyecto.

Se mostrará un resultado similar al siguiente:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

Visualiza el certificado TLS con el siguiente comando de gcloud (siempre que tengas

jq

o una herramienta similar instalada en tu máquina):

gcloud compute ssl-certificates describe CERTICATE_NAME \
--project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -noout

Reemplaza CERTIFICATE_NAME por el nombre del certificado. Por ejemplo, example-ssl-cert

Se mostrará un resultado similar al siguiente:

certCertificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            51:3b:a4:60:fe:49:34:a2:09:af:14:85:96:a2:4f:d9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1D4
        Validity
            Not Before: Jul 11 11:51:52 2023 GMT
            Not After : Oct  9 12:44:45 2023 GMT
        Subject: CN = 34.149.207.105.nip.io
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                .
                .

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A5:DB:7C:6A:8B:0B:7A:22:45:52:1E:85:29:32:77:18:A3:9D:87:76
            X509v3 Authority Key Identifier:
                keyid:25:E2:18:0E:B2:57:91:94:2A:E5:D4:5D:86:90:83:DE:53:B3:B8:92

            Authority Information Access:
                OCSP - URI:http://ocsp.pki.goog/s/gts1d4/qMhEcTt7LjA
                CA Issuers - URI:http://pki.goog/repo/certs/gts1d4.der

            X509v3 Subject Alternative Name:
                DNS:34.149.207.105.nip.io
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.11129.2.5.3

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.pki.goog/gts1d4/LjtNmxrQfWE.crl

Asegúrate de que el nombre común (CN) en el certificado coincida con el Nombre de host configurado en Apigee > Administrador > Entornos > Grupos. Asegúrate de que el certificado sea válido y no haya vencido. Puedes usar openssl para realizar estas verificaciones.

Para verificar el certificado TLS que muestra el balanceador de cargas, ejecuta el siguiente comando de openssl desde tu máquina cliente. Comprueba si este certificado coincide con el que se mostró en el paso 1 anterior.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
Reemplaza lo siguiente:
- LB_HOSTNAME_OR_IP: El nombre de host o la dirección IP del balanceador de cargas. Por ejemplo, my-load-balancer
- LB_HOSTNAME: El nombre de host del balanceador de cargas. Por ejemplo, my-hostname.
Para verificar que los certificados coincidan, ejecuta el siguiente comando desde tu cliente:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Reemplaza HOST_NAME por el nombre de host configurado en Apigee (Administrador > Entornos > Grupos).

Luego, ejecuta el siguiente comando de gcloud para verificar que md5 coincida:
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
Reemplaza CERTIFICATE_NAME por el nombre del certificado. Por ejemplo, my-certificate
Si los certificados del paso 1 ypaso 2 coinciden (es decir, si en md5 hay coincidencias de valores), se recopila unapacket capture del cliente para investigar la falla del protocolo de enlace TLS. Puedes realizar la captura de paquetes del cliente con herramientas como Wireshark, tcpdump o cualquier otra herramienta confiable.
Para habilitar los registros en el balanceador de cargas, sigue las instrucciones en Habilita el registro en un servicio de backend existente.
Revisa los registros del balanceador de cargas en busca de errores.

Solución

Si tu certificado autoadministrado en el balanceador de cargas venció o tiene valores de CN/SAN incorrectos, es posible que debas reemplazar el certificado en el balanceador de cargas.
Si el certificado que muestra el balanceador de cargas en el paso 1 y el certificado en el paso 2 no coinciden, es posible que el balanceador de cargas entregue una el certificado está inactivo o es incorrecto, y debes enviar un ticket con la Asistencia de Apigee.
Si un tcpdump indica una falla del protocolo de enlace TLS, investiga si la falla de conexión proviene del balanceador de cargas o del cliente.
- Si el restablecimiento o la falla son del lado del cliente, verifica la aplicación cliente para comprender por qué tiene un comportamiento deficiente. Por ejemplo, puedes verificar la configuración de red en el lado del cliente o verificar que la aplicación cliente tenga conectividad con Apigee.
- Si ves la falla o el restablecimiento del balanceador de cargas, consulta Soluciona problemas generales de conectividad y envía un ticket al equipo de asistencia de Apigee si es necesario.
Si ves errores en los registros del balanceador de cargas, consulta Errores 5XX sin explicación y envía un ticket con la Asistencia de Apigee si es necesario.

Si aún necesitas asistencia, consulta Recopila información de diagnóstico.

Causa: Cloud Armor bloquea las solicitudes

Diagnóstico

Si ves una respuesta de error 403, 404 o 502 basada en la configuración de Cloud Armor, revisa el balanceador de cargas y la configuración del MIG para verificarlos. están configurados correctamente y se ven en buen estado.

Si usas Google Cloud Armor en tu entorno de Google Cloud, revisa la configuración de Google Cloud Armor para detectar reglas que puedan bloquear la solicitud. Las políticas de seguridad se encuentran en Configura políticas de seguridad de Google Cloud Armor.
Si no estás seguro de qué regla rechaza el tráfico, puedes intentar habilitar el registro en el balanceador de cargas como se describe en Habilita el registro en un servicio de backend existente.
Una vez habilitado el registro, realiza una consulta de registros para encontrar cualquier solicitud bloqueada por las políticas de Google Cloud Armor:
1. En la consola de Google Cloud, ve a la página Explorador de registros.
  
  Ir al Explorador de registros
2. Pega lo siguiente en el panel Consulta:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Haz clic en Ejecutar consulta.
4. El nombre de la política aplicada se muestra en jsonPayload.enforcedSecurityPolicy.name en el panel Resultados de la consulta:

Solución

Modifica las reglas o la configuración de Google Cloud Armor para que se alineen a tus necesidades a fin de resolver este problema. Si necesitas ayuda con esto, comunícate con la Asistencia de Apigee.

Causa: Las VM del proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee

Diagnóstico

Si los clientes de la API reciben errores HTTP 502 con el siguiente mensaje de error, las VM del proxy de tráfico de la API de Apigee pueden estar en mal estado.

Los clientes pueden recibir errores 502 como los siguientes:
```
<html><head> <meta http-equiv="content-type"
  content="text/html;charset=utf-8"> <title>502 Server Error</title> </head>
  <body text=#000000 bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The
  server encountered a temporary error and could not complete your
  request.<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>
```
Revisa los registros del balanceador de cargas en busca de mensajes de error como los siguientes:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
Hay un conjunto de VM (con un prefijo apigee-proxy) que se ejecutan en un grupo de instancias administrado (MIG) y que reenvían el tráfico a la instancia de Apigee. Si ves mensajes como el anterior, verifica el estado de las VM de apigee-proxy que forman parte del grupo de instancias mediante los siguientes pasos:
1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
  
  Ir a Balanceo de cargas
2. Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
3. En la sección Backend, verifica que todos los backends del balanceador de cargas tengan una marca de verificación verde en la columna En buen estado.
Verifica que la dirección IP del extremo en la plantilla del MIG coincida con la dirección IP de la instancia de Apigee.

Las VM apigee-proxy se crean mediante una plantilla de instancias. La plantilla define la dirección IP ENDPOINT para conectarse a la dirección IP de la instancia de Apigee.
1. Obtén la dirección IP de la instancia de Apigee:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  Reemplaza lo siguiente:
  - ORG_NAME: Es el nombre de tu organización. Por ejemplo: my-org
  - INSTANCE_NAME: el nombre de tu instancia Por ejemplo: apigee-proxy-example
2. O bien, obtén la dirección IP de la instancia de Apigee mediante la IU de Apigee:
  1. En la IU de Apigee, haz clic en Administrador > Instancias.
  2. En la columna Direcciones IP, se muestra la dirección IP:
3. Obtén la dirección IP ENDPOINT de la plantilla:
  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
    
    Ir a Balanceo de cargas
  2. Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
  3. En el área Backend, haz clic en el nombre del servicio de backend.
  4. En el área Grupo de instancias, haz clic en un nombre de Plantilla.
  5. En la página de la plantilla, desplázate hasta Metadatos personalizados (Custom metadata), que es donde verás la dirección IP EXTREMO:
Asegúrate de que la dirección IP ENDPOINT coincida con la dirección IP de Apigee que se muestra en el paso 2. Si no coincide, ve a Resolución.

Solución

Si las VM apigee-proxy del grupo de instancias muestran un mal estado, asegúrate de tener una regla de firewall que permita que los rangos de direcciones IP del balanceo de cargas 130.211.0.0/22 y 35.191.0.0/16 accede al MIG.
En la consola de Google Cloud, ve a la página Firewall.

Ir a Firewall
Asegúrate de que exista una regla de firewall de entrada con target-tag, como gke-apigee-proxy, y rangos de IP de origen, como 130.211.0.0/22 y 35.191.0.0/16, en el puerto 443 TCP:

Si el MIG tiene una etiqueta diferente a gke-apigee-proxy, asegúrate de que la etiqueta se agregue a target-tag en la regla de firewall.

Si la regla de firewall no existe, agrégala.
Si la dirección IP ENDPOINT no coincide con la dirección IP de la instancia de Apigee, es posible que la instancia se haya borrado y recreado, lo que daría como resultado una dirección IP que ya no coincida con la dirección IP. Dirección IP en la plantilla. Para actualizar la plantilla a fin de usar la nueva dirección IP, sigue las instrucciones en Cambia las IP de la instancia.

Causa: La configuración de red es incorrecta

Diagnóstico

Ubica el valor de authorizedNetwork mediante la ejecución de la siguiente llamada a la API:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME"

Se mostrará un resultado similar al siguiente:

{
  "name": "apigee-example-org",
  "createdAt": "1621287579456",
  "lastModifiedAt": "1674063833580",
  "environments": [
    "test"
  ],
  "properties": {
    "property": [
      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }
    ]
  },
  "analyticsRegion": "us-west1",
  "authorizedNetwork": "default",
  "runtimeType": "CLOUD",
  "subscriptionType": "PAID",
  "caCertificate": "certificate-number",
  "runtimeDatabaseEncryptionKeyName": "projects/apigee-example-org/locations/us-west1/keyRings/my-database-key-ring/cryptoKeys/my-database-key",
  "projectId": "apigee-example-org",
  "state": "ACTIVE",
  "billingType": "SUBSCRIPTION",
  "addonsConfig": {
    "advancedApiOpsConfig": {},
    "integrationConfig": {},
    "monetizationConfig": {}
  },
  "apigeeProjectId": "l09587a43efde330cp-tp"
}

En este ejemplo, el valor de authorizedNetwork es el predeterminado.

Verifica que el valor authorizedNetwork sea el mismo que el de la red que intercambia tráfico con servicenetworking:
1. En la consola de Google Cloud del proyecto host, ve a la página Intercambio de tráfico entre redes de VPC.
  
  Ir a Intercambio de tráfico entre redes de VPC
2. El valor que aparece para servicenetworking-googleapis-com en Tu red de VPC debe ser el mismo que el valor que muestra la llamada a la API. Por ejemplo, default.
Si usas una VPC compartida, asegúrate de que el valor authorizedNetwork tenga el valor de la VPC real en el proyecto host que intercambia tráfico con servicenetworking.
1. En la consola de Google Cloud, ve a la página VPC compartida.
  
  Ir a VPC compartida
2. Selecciona el Proyecto host.
3. El valor que aparece para servicenetworking-googleapis-com en Tu red de VPC debe ser el mismo que el valor authorizedNetwork que muestra la llamada a la API. Por ejemplo, default.
Verifica que el grupo de instancias asociado con el balanceador de cargas sea la misma red que el valor authorizedNetwork:
1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
  
  Ir a Balanceo de cargas
2. Haz clic en el nombre de un balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas. Se muestra una lista de grupos de instancias en el área Backend:
3. Haz clic en el nombre de un grupo de instancia. Se muestra la página Descripción general del grupo de instancias.
4. Haga clic en la pestaña Detalles.
5. Desplázate hasta la sección Herramientas de redes:
6. Verifica que la Red principal aquí sea la misma que el valor authorizedNetwork. Por ejemplo, default.
7. Haz clic en la pestaña Descripción general.
8. En la sección Miembros del grupo de instancias, haz clic en el nombre de una instancia. Se muestra la página Detalles.
9. Desplázate hasta la sección Interfaces de red.
10. Verifica que el valor Red sea el mismo que el valor authorizedNetwork. Por ejemplo, default.
11. Ve a Descripción general pestaña y repite el procesopaso h a través depaso j para cada instancia en la Miembros del grupo de instancias.

Solución

Si se encuentra en el paso 2 o en el paso 3, el valor authorizedNetwork no es lo mismo que la red que intercambia tráfico con servicenetworking Luego, asegúrate de haber intercambiado el tráfico de la red de VPC correcta con servicenetworking mediante los pasos del Paso 4: Configura las herramientas de redes de servicio.
Si en el paso 4f y 4j, los valores de red no son los mismos que el valor authorizedNetwork, verifica que las authorizedNetwork es que la red intercambia tráfico con servicenetworking. Si intercambia tráfico de forma correcta y la red aún no es igual a la authorizedNetwork,, significa que el grupo de instancias se creó de forma incorrecta y deberías hacer lo siguiente: comunícate con el equipo de asistencia de Apigee.

Causa: Entorno no conectado en la instancia nueva de Apigee creada como parte de la expansión regional

Diagnóstico

Verás un error 503 en el lado del cliente. Por ejemplo:
```
HTTP/2 503
date: Thu, 08 Jun 2023 07:22:15 GMT
content-length: 0
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
```
Nota: Este error 503 no se muestra en el seguimiento de depuración, ya que las solicitudes nunca llegan al procesador de mensajes del entorno de ejecución.
Si ves errores 503 en la segunda región inmediatamente después de una expansión de región, haz lo siguiente:
1. Asegúrate de que los entornos estén conectados a la instancia nueva mediante la ejecución de la siguiente llamada a la API:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  Por ejemplo:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  Se mostrará un resultado similar al siguiente:
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  En este ejemplo, la instancia llamada apigee-proxy-example se conecta a dos entornos: dev y prod.
2. Asegúrate de que se haya creado el grupo de instancias administrado (MIG) para la segunda región y se muestre como en buen estado:
  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.
    
    Ir a Balanceo de cargas
  2. Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
  3. En Backend, deberías ver dos MIG. uno para la región 1 y otro para la región 2. Verifica que ambos estén en buen estado:
  4. Para validar el segundo MIG, sigue los pasos en Las VM del proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee.

Solución

Si la instancia nueva no está conectada al entorno, sigue las instrucciones en Adjunta entornos a la instancia nueva para adjuntarla.

Otra opción es asegurarse de que el balanceador de cargas enrute la solicitud al backend correcto al que ya está conectado el entorno. Por ejemplo, de un entorno que no es de producción. Puedes adjuntar esto a una sola región; Sin embargo, el balanceador de cargas puede enrutar la solicitud a la región incorrecta. Deberás actualizar la configuración del balanceador de cargas para asegurarte de que se enrute a la región correcta.
Si un MIG está en mal estado, consultaDiagnóstico ySolución enLas VM del proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee.

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:

Organización de Apigee
Entorno y proxy de API que ven el problema
Sesión de depuración descargada (si el problema es intermitente)
Resultado de curl detallado de una solicitud con errores.
Balanceador de cargas configurado para enviar llamadas a la API a Apigee