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 ni conectarse a él 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 desde tu cliente a Apigee, ves un error de protocolo de enlace TLS o una respuesta 4xx/5xx, aunque los proxies de API puedan parecer correctos en la IU de Apigee.

Causas posibles

Causa Descripción Códigos de error
Errores de TLS en el balanceador de cargas HTTPS Administras la configuración de TLS del balanceador de cargas HTTPS. Investiga los errores 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 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 VMs de proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee. Se debe investigar la configuración del proxy del router de tráfico de la API de Apigee y su estado. 502 Server Error
Configuración de red incorrecta Asegúrate de que la red correcta intercambie tráfico con la VPC de Apigee. 502 Server error
Entornos sin conectar en la nueva instancia de Apigee creada como parte de la expansión de la región 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 HTTPS

Diagnóstico

  1. Busca el certificado TLS asociado con el balanceador de cargas.
    1. 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:Port, asegúrate de estar viendo el balanceador de cargas correcto; para ello, verifica su dirección IP y puerto.
      4. En la columna Certificado, haz clic en el nombre del certificado para ver el certificado TLS.
    2. Con un comando de gcloud:
      1. Enumera los balanceadores de cargas con el siguiente comando de gcloud. Este comando también muestra los SSL_CERTIFICATES asociados con cada balanceador de cargas. 
        gcloud compute target-https-proxies list --project=PROJECT_NAME

        Reemplaza PROJECT_NAME por el nombre de tu 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:
      2. Consulta el certificado TLS con el siguiente comando de gcloud (se supone que tienes 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) del 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.

  2. Para verificar el certificado TLS que muestra el balanceador de cargas, ejecuta el siguiente comando openssl desde tu máquina cliente. Verifica si este certificado coincide con el que se muestra 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 coincida con md5: 

    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

  3. 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 en el cliente con herramientas como Wireshark, tcpdump o cualquier otra herramienta confiable.
  4. Para habilitar los registros en el balanceador de cargas, sigue las instrucciones que se indican en Habilita el registro en un servicio de backend existente.
  5. Revisa los registros del balanceador de cargas en busca de errores.

Solución

  1. Si el certificado autoadministrado en el balanceador de cargas venció o tiene valores incorrectos de CN o SAN, es posible que debas reemplazar el certificado en el balanceador de cargas.
  2. Si el certificado que muestra el balanceador de cargas en el paso 1 y el certificado del paso 2 no coinciden, es posible que el balanceador de cargas esté entregando un certificado incorrecto o inactivo, y debes enviar un ticket al equipo de Atención al cliente de Google Cloud.
  3. Si 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 la falla o el restablecimiento de la conexión se produce del lado del cliente, verifica tu aplicación cliente para comprender por qué se comporta de forma incorrecta. Por ejemplo, puedes verificar la configuración de red en el cliente o comprobar que la aplicación cliente tenga conectividad con Apigee.
    • Si ves la falla o el restablecimiento desde el balanceador de cargas, consulta Soluciona problemas generales de conectividad y, si es necesario, envía un ticket al equipo de Atención al cliente de Google Cloud.
  4. Si ves errores en los registros del balanceador de cargas, consulta Errores 5XX sin motivo y, si es necesario, envía un ticket al equipo de Atención al cliente de Google Cloud.

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

Causa: Cloud Armor bloquea las solicitudes

Diagnóstico

Si ves una respuesta de error 403, 404 o 502 según la configuración de Cloud Armor, revisa la configuración del balanceador de cargas y del MIG para verificar que estén configurados correctamente y que tengan un estado correcto.

  1. Si usas Google Cloud Armor en tu entorno de Google Cloud, revisa la configuración de Google Cloud Armor en busca de reglas que puedan estar bloqueando la solicitud. Puedes encontrar las políticas de seguridad en Configura las políticas de seguridad de Google Cloud Armor.
  2. 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.

  3. Una vez que se habilite el registro, realiza una consulta de registros para encontrar las solicitudes que bloqueen 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 con tus necesidades y resolver este problema. Si necesitas asistencia con esto, comunícate con Atención al cliente de Google Cloud.

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

Diagnóstico

  1. Si los clientes de API reciben errores HTTP 502 con el siguiente mensaje de error, es posible que las VMs de proxy del router de tráfico de la API de Apigee estén 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 VMs (con un prefijo apigee-proxy) que se ejecutan en un grupo de instancias administrado (MIG) que reenvía el tráfico a la instancia de Apigee. Si ves mensajes como los anteriores, verifica el estado de las VMs apigee-proxy que forman parte del grupo de instancias a través de 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.

  2. Verifica que la dirección IP del extremo en la plantilla de MIG coincida con la dirección IP de la instancia de Apigee.

    Las VMs de apigee-proxy se crean con una plantilla de instancias. La plantilla define la dirección IP de 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, puedes obtener la dirección IP de la instancia de Apigee con 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 de 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 de un servicio de backend.

      4. En el área Miembros del grupo de instancias, haz clic en el nombre de una Plantilla.

      5. En la página de la plantilla, desplázate hasta Metadatos personalizados, que es donde verás la dirección IP de ENDPOINT:

    Asegúrate de que la dirección IP de ENDPOINT coincida con la dirección IP de Apigee que se muestra en el paso 2. Si no coinciden, ve a Resolución.

Solución

  1. Si las VMs de apigee-proxy en el grupo de instancias muestran que están en mal estado, asegúrate de tener una regla de firewall que permita que los rangos de direcciones IP de balanceo de cargas 130.211.0.0/22 y 35.191.0.0/16 accedan al MIG.

  2. En la consola de Google Cloud, ve a la página Firewall.

    Ir a Firewall

  3. 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 a través del 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 no existe la regla de firewall, agrégala.

  4. Si la dirección IP de ENDPOINT no coincide con la dirección IP de la instancia de Apigee, es posible que la instancia se haya borrado y vuelto a crear, lo que generaría una dirección IP que ya no coincide con la dirección IP de la plantilla. Para actualizar la plantilla para usar la dirección IP nueva, sigue las instrucciones que se indican en Cambia las IP de instancias.

Causa: Configuración de red incorrecta

Diagnóstico

  1. Para ubicar el valor de authorizedNetwork, ejecuta 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.

  2. Verifica que el valor de 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 se muestra en la llamada a la API. Por ejemplo, default.

  3. Si usas una VPC compartida, asegúrate de que el valor de 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 se indica para servicenetworking-googleapis-com en Tu red de VPC debe ser el mismo que el valor authorizedNetwork que se muestra en la llamada a la API. Por ejemplo, default.

  4. Verifica que el grupo de instancias asociado con el balanceador de cargas sea la misma red que el valor de 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. En el área Backend, se muestra una lista de grupos de instancias:

    3. Haz clic en el nombre de un grupo de instancia. Se mostrará 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 igual que el valor de 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 de la red sea el mismo que el valor de authorizedNetwork. Por ejemplo, default.
    11. Ve a la pestaña Descripción general y repite del paso h al paso j para cada instancia en la sección Miembros del grupo de instancias.

Solución

  1. Si, en el paso 2 o el paso 3, el valor de authorizedNetwork no es el mismo que el de la red que intercambia tráfico con servicenetworking, asegúrate de haber establecido el intercambio de tráfico con la red de VPC correcta con servicenetworking. Para ello, sigue los pasos que se indican en el Paso 4: Configura las herramientas de redes de servicio.
  2. Si, en los pasos 4f y 4j, los valores de red no son los mismos que el valor de authorizedNetwork, verifica que authorizedNetwork sea la red que intercambia tráfico con servicenetworking. Si se estableció correctamente el intercambio de tráfico y la red aún no es la misma que authorizedNetwork,, significa que el grupo de instancias se creó de forma incorrecta y debes comunicarte con el equipo de Atención al cliente de Google Cloud.

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

Diagnóstico

  1. Ves 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
  2. Si ves errores 503 en la segunda región inmediatamente después de una expansión de la región, haz lo siguiente:
    1. Para asegurarte de que los entornos estén conectados a la instancia nueva, ejecuta 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 está conectada 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 que se muestre 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 uno para la región 2. Verifica que ambos estén en buen estado:

      4. Para validar el segundo MIG, sigue los pasos que se indican en Las VMs de proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee.

Solución

  1. Si la instancia nueva no está conectada al entorno, sigue las instrucciones que se indican en Conecta entornos a la instancia nueva para conectarla.

    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 no de producción. Se recomienda conectarlo a una sola región. Sin embargo, es posible que el balanceador de cargas enrute la solicitud a la región incorrecta. Deberás actualizar la configuración del balanceador de cargas para asegurarte de que enrute a la región correcta.

  2. Si un MIG no está en buen estado, consulta Diagnóstico y Solución en Las VMs de 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 Atención al cliente de Google Cloud:

  • 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 detallado de curl de una solicitud con errores.
  • Balanceador de cargas configurado para enviar llamadas a la API a Apigee