Acceder a problemas de enrutamiento con Apigee

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

Síntoma

En algunos casos, los clientes externos no pueden acceder o conectarse a Apigee de la forma deseada. Entre ellos, se incluyen errores de conectividad de red (fallos de handshake de TLS) o respuestas 4xx/5xx de Apigee.

Mensaje de error

Cuando envías una solicitud de API de tu cliente a Apigee, se produce un error de handshake de TLS o recibes una respuesta 4xx/5xx, aunque los proxies de API parezcan estar en buen estado en la interfaz de usuario de Apigee.

Posibles motivos

Causa Descripción Códigos de error
Errores de TLS en el balanceador de carga HTTPS Usted gestiona la configuración de TLS del balanceador de carga HTTPS. Investiga los errores de TLS en los registros del balanceador de carga HTTPS. Errores de handshake TLS de la dirección IP del balanceador de carga
Google Cloud Armor bloquea las solicitudes Si usas Google Cloud Armor, puede que haya una regla que bloquee la solicitud. El código de respuesta de la API puede variar en función de la configuración de Google Cloud Armor. Las reglas de denegación pueden devolver una respuesta HTTP 403 (No autorizado), 404 (Acceso denegado) o 502 (Puerta de enlace incorrecta), o incluso otro código de respuesta.
Las VMs proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee Es necesario 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 esté emparejada con la VPC de Apigee. 502 Server error
Entornos no asociados en la nueva instancia de Apigee creada como parte de la ampliación de la región Después de crear una instancia, por ejemplo, una segunda región, debes asociarle entornos. De lo contrario, no podrá responder a las solicitudes de la API. 503 error response

Causa: errores de TLS en el balanceador de carga HTTPS

Diagnóstico

  1. Busca el certificado TLS asociado al balanceador de carga.
    1. En la consola de Google Cloud:

      1. En la Google Cloud consola, ve a la página Balanceo de carga.

        Ir al balanceo de carga

      2. Haz clic en el Nombre del balanceador de carga. Se abrirá la página Detalles del balanceador de carga.

      3. En el área Frontend (Frontend), en la columna IP:Port (IP:Puerto), asegúrate de que estás consultando el balanceador de carga correcto verificando su dirección IP y su 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. Lista los balanceadores de carga con el siguiente comando de gcloud. Este comando también muestra los SSL_CERTIFICATES asociados a cada balanceador de carga. 
        gcloud compute target-https-proxies list --project=PROJECT_NAME

        Sustituye PROJECT_NAME por el nombre de tu proyecto.

        Se devuelve algo similar a lo 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 presupone 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

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

        Se devuelve algo similar a lo 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 > Administrar > Entornos > Grupos. Asegúrate de que el certificado sea válido y no haya caducado. Puedes usar openssl para realizar estas comprobaciones.

  2. Para comprobar el certificado TLS devuelto por el balanceador de carga, ejecuta el siguiente comando openssl desde tu máquina cliente. Comprueba si este certificado coincide con el que se ha devuelto en el paso 1 anterior. 
    openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts

    Haz los cambios siguientes:

    • LB_HOSTNAME_OR_IP: el nombre de host o la dirección IP del balanceador de carga. Por ejemplo, my-load-balancer.
    • LB_HOSTNAME: nombre de host del balanceador de carga. 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

    Sustituye HOST_NAME por el nombre de host configurado en Apigee (Administrar > Entornos > Grupos).

    A continuación, comprueba que el md5 coincida ejecutando el siguiente comando de gcloud: 

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

    Sustituye CERTIFICATE_NAME por el nombre del certificado. Por ejemplo, my-certificate

  3. Si los certificados de los pasos 1 y 2 coinciden (es decir, si los valores de md5 coinciden), recoge un packet capture en el lado del cliente para investigar el fallo del handshake TLS. Puedes hacer una captura de paquetes en el lado del cliente con herramientas como Wireshark, tcpdump o cualquier otra herramienta fiable.
  4. Para habilitar los registros en el balanceador de carga, sigue las instrucciones de la sección Habilitar el registro en un servicio de backend disponible.
  5. Revisa los registros del balanceador de carga para ver si hay errores.

Resolución

  1. Si tu certificado autogestionado del balanceador de carga ha caducado o tiene valores de CN o SAN incorrectos, puede que tengas que sustituir el certificado del balanceador de carga.
  2. Si el certificado devuelto por el balanceador de carga en el paso 1 y el certificado del paso 2 no coinciden, puede que el balanceador de carga esté usando un certificado obsoleto o incorrecto, por lo que deberías enviar una incidencia al servicio de atención al cliente de Google Cloud.
  3. Si tcpdump indica que se ha producido un error en el handshake TLS, investiga si el error de conexión procede del balanceador de carga o del lado del cliente.
    • Si el error o el restablecimiento de la conexión se produce en el lado del cliente, comprueba tu aplicación cliente para saber por qué no funciona correctamente. Por ejemplo, puedes comprobar la configuración de la red en el lado del cliente o verificar que la aplicación cliente tenga conectividad con Apigee.
    • Si ves que el balanceador de carga falla o se reinicia, consulta el artículo Solucionar problemas generales de conectividad y registra una incidencia con Cloud Customer Care de Google si es necesario.
  4. Si ve errores en los registros del balanceador de carga, consulte la sección Errores 5XX inexplicables y registre una incidencia con Google Cloud Customer Care si es necesario.

Si sigues necesitando ayuda, consulta la sección Debo recoger 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 la configuración del balanceador de carga y del MIG para verificar que estén configurados correctamente y que tengan un buen estado.

  1. Si usas Google Cloud Armor en tu Google Cloud entorno, revisa la configuración de Google Cloud Armor para ver si hay alguna regla que pueda estar bloqueando la solicitud. Las políticas de seguridad se pueden encontrar en el artículo Configurar políticas de seguridad de Google Cloud Armor.
  2. Si no sabes qué regla está denegando el tráfico, puedes probar a habilitar el registro en el balanceador de carga, tal como se describe en Habilitar el registro en un servicio de backend ya creado.

  3. Una vez que se haya habilitado el registro, realiza una consulta de registros para encontrar las solicitudes bloqueadas por las políticas de Google Cloud Armor:

    1. En la Google Cloud consola, ve a la página Explorador de registros.

      Ir a Explorador de registros

    2. Pega lo siguiente en el panel Consulta:

      jsonPayload.enforcedSecurityPolicy.outcome="DENY"
    3. Haz clic en Realizar una consulta.

    4. El nombre de la política aplicada se muestra en jsonPayload.enforcedSecurityPolicy.name en el panel Resultados de la consulta:

Resolución

Modifica las reglas o la configuración de Google Cloud Armor para adaptarlas a tus necesidades y resolver este problema. Si necesitas ayuda, ponte en contacto con el equipo de Asistencia de Google Cloud.

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

Diagnóstico

  1. Si los clientes de la API reciben errores HTTP 502 con el siguiente mensaje de error, es posible que las VMs proxy del router de tráfico de la API de Apigee no estén en buen 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 carga para ver si hay mensajes de error como los siguientes:

    statusDetails: "failed_to_pick_backend"
severity: "WARNING"

    Hay un conjunto de VMs (con el prefijo apigee-proxy) que se ejecutan en un grupo de instancias gestionado (MIG) que reenvía el tráfico a la instancia de Apigee. Si ves mensajes como los anteriores, comprueba el estado de las VMs que forman parte del grupo de instancias siguiendo estos pasos:apigee-proxy

    1. En la Google Cloud consola, ve a la página Balanceo de carga.

      Ir al balanceo de carga

    2. Haz clic en el Nombre del balanceador de carga. Se abrirá la página Detalles del balanceador de carga.

    3. En la sección Backend, comprueba que todos los backends del balanceador de carga tengan una marca de verificación verde en la columna En buen estado.

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

    Las VMs apigee-proxy se crean a partir de una plantilla de instancia. La plantilla define la ENDPOINT dirección IP 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"

      Haz los cambios siguientes:

      • ORG_NAME: el nombre de tu organización. Por ejemplo, my-org.
      • INSTANCE_NAME: el nombre de tu instancia. Por ejemplo, apigee-proxy-example.

    2. También puedes obtener la dirección IP de la instancia de Apigee mediante la interfaz de usuario de Apigee:

      1. En la interfaz de usuario de Apigee, haga clic en Administrar > 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 Google Cloud consola, ve a la página Balanceo de carga.

        Ir al balanceo de carga

      2. Haz clic en el Nombre del balanceador de carga. Se abrirá la página Detalles del balanceador de carga.
      3. En el área Backend, haz clic en el nombre de un servicio de backend.

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

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

    Comprueba que la dirección IP de ENDPOINT coincida con la dirección IP de Apigee devuelta en el paso 2. Si no coincide, ve a Resolución.

Resolución

  1. Si las VMs apigee-proxy del grupo de instancias muestran un estado incorrecto, asegúrate de que tienes una regla de cortafuegos que permita que los intervalos de direcciones IP de balanceo de carga 130.211.0.0/22 y 35.191.0.0/16 accedan al MIG.

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

    Ir a Cortafuegos

  3. Asegúrate de que existe una regla de cortafuegos de entrada con target-tag como gke-apigee-proxy e intervalos 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 añada a target-tag en la regla de firewall.

    Si la regla de cortafuegos no existe, añádala.

  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 eliminado y vuelto a crear, lo que daría como resultado una dirección IP que ya no coincide con la dirección IP de la plantilla. Para actualizar la plantilla y usar la nueva dirección IP, sigue las instrucciones de la sección Cambiar las IPs de las instancias.

Causa: configuración de red incorrecta

Diagnóstico

  1. Busca el valor de authorizedNetwork ejecutando la siguiente llamada a la API: 

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

    Se devuelve algo similar a lo 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 emparejada con servicenetworking:

    1. En la consola del proyecto host, ve a la página Peerings de redes de VPC. Google Cloud

      Ir al emparejamiento entre redes VPC

    2. El valor que aparece en servicenetworking-googleapis-com en Tu red de VPC debe ser el mismo que el valor devuelto por la llamada a la API. Por ejemplo, default.

  3. Si utilizas una VPC compartida, asegúrate de que el valor de authorizedNetwork sea el de la VPC real del proyecto host que está emparejado con servicenetworking.

    1. En la Google Cloud consola, ve a la página VPC compartida.

      Ir a VPC compartida

    2. Selecciona el proyecto host.
    3. El valor que aparece en servicenetworking-googleapis-com en Tu red de VPC debe ser el mismo que el valor authorizedNetwork devuelto por la llamada a la API. Por ejemplo, default.

  4. Verifica que el grupo de instancias asociado al balanceador de carga esté en la misma red que el valor de authorizedNetwork:

    1. En la Google Cloud consola, ve a la página Balanceo de carga.

      Ir al balanceo de carga

    2. Haz clic en el nombre de un balanceador de carga. Se abrirá la página Detalles del balanceador de carga. Se muestra una lista de grupos de instancias en el área Backend:

    3. Haz clic en el nombre de un grupo de instancias. Se muestra la página Información general del grupo de instancias.
    4. Haga clic en la pestaña Detalles.

    5. Desplázate hasta la sección Redes:

    6. Comprueba que la Red principal que aparece aquí sea la misma que el valor de authorizedNetwork. Por ejemplo, default.
    7. Haga clic en la pestaña Descripción general.
    8. En la sección Miembros del grupo de instancias, haga clic en el nombre de una instancia. Se mostrará la página Detalles.

    9. Desplázate hasta la sección Interfaces de red:

    10. Comprueba que el valor de Network sea el mismo que el valor de authorizedNetwork. Por ejemplo, default.
    11. Ve a la pestaña Vista general y repite los pasos del h al j para cada instancia de la sección Miembros del grupo de instancias.

Resolución

  1. Si en el paso 2 o en el paso 3, el valor de authorizedNetwork no es el mismo que el de la red emparejada con servicenetworking, asegúrate de que has emparejado la red de VPC correcta con servicenetworking siguiendo los pasos del paso 4: Configura las redes de servicios.
  2. Si en los pasos 4f y 4j, los valores de la red no son los mismos que el valor de authorizedNetwork, comprueba que authorizedNetwork sea la red emparejada con servicenetworking. . Si está emparejada correctamente y la red sigue sin ser la misma que authorizedNetwork,, significa que el grupo de instancias se ha creado incorrectamente y debes ponerte en contacto con el equipo de Asistencia de Google Cloud.

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

Diagnóstico

  1. Se muestra 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 ampliación de la región:
    1. Asegúrate de que los entornos estén asociados a la nueva instancia ejecutando 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 devuelve algo similar a lo 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á asociada a dos entornos: dev y prod.

    2. Asegúrate de que se ha creado el grupo de instancias gestionado (MIG) de la segunda región y de que aparece como correcto:

      1. En la Google Cloud consola, ve a la página Balanceo de carga.

        Ir al balanceo de carga

      2. Haz clic en el Nombre del balanceador de carga. Se abrirá la página Detalles del balanceador de carga.
      3. En Backend, deberías ver dos MIGs: uno para la región 1 y otro para la región 2. Verifica que ambos estén en buen estado:

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

Resolución

  1. Si la nueva instancia no está asociada al entorno, asóciala siguiendo las instrucciones de Asociar entornos a la nueva instancia.

    Otra opción es asegurarse de que el balanceador de carga enruta la solicitud al backend correcto, donde el entorno ya está asociado. Por ejemplo, de un entorno de no producción. Puede que solo quieras asociarlo a una región, pero el balanceador de carga puede estar enrutando la solicitud a la región incorrecta. Tendrías que actualizar la configuración del balanceador de carga para asegurarte de que se dirige a la región correcta.

  2. Si un MIG no está en buen estado, consulta las secciones Diagnóstico y Resolución en Las VMs proxy de Apigee no pueden reenviar el tráfico a la instancia de Apigee.

Debe recoger información de diagnóstico

Si el problema persiste incluso después de seguir las instrucciones anteriores, recoge la siguiente información de diagnóstico y ponte en contacto con el equipo de Asistencia de Google Cloud:

  • Organización de Apigee
  • Entorno y proxy de API que presentan el problema
  • Sesión de depuración descargada (si el problema es intermitente)
  • Salida detallada de curl de una solicitud fallida.
  • Balanceador de carga configurado para enviar llamadas a la API a Apigee