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
-
En la consola de Google Cloud, ve a la página Balanceo de cargas.
-
Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
- 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.
- 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.
-
Enumera los balanceadores de cargas con el siguiente
comando de gcloud. Este comando también muestra
- Usa Google Cloud Console
-
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
-
LB_HOSTNAME_OR_IP: El nombre de host o la dirección IP del balanceador de cargas. Por ejemplo,
-
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:
-
En la consola de Google Cloud, ve a la página Explorador de registros.
-
Pega lo siguiente en el panel Consulta:
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
- Haz clic en Ejecutar consulta.
-
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 deapigee-proxy
que forman parte del grupo de instancias mediante los siguientes pasos:-
En la consola de Google Cloud, ve a la página Balanceo de cargas.
-
Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
-
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 IPENDPOINT
para conectarse a la dirección IP de la instancia de Apigee.-
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
-
ORG_NAME: Es el nombre de tu organización. Por ejemplo:
-
O bien, obtén la dirección IP de la instancia de Apigee mediante la IU de Apigee:
- En la IU de Apigee, haz clic en Administrador > Instancias.
-
En la columna Direcciones IP, se muestra la dirección IP:
-
Obtén la dirección IP
ENDPOINT
de la plantilla:-
En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
- En el área Backend, haz clic en el nombre del servicio de backend.
-
En el área Grupo de instancias, haz clic en un nombre de Plantilla.
-
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.
-
Obtén la dirección IP de la instancia de Apigee:
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 cargas130.211.0.0/22
y35.191.0.0/16
accede al MIG. -
En la consola de Google Cloud, ve a la página Firewall.
-
Asegúrate de que exista una regla de firewall de entrada con
target-tag
, comogke-apigee-proxy
, y rangos de IP de origen, como130.211.0.0/22
y35.191.0.0/16
, en el puerto443 TCP
:Si el MIG tiene una etiqueta diferente a
gke-apigee-proxy
, asegúrate de que la etiqueta se agregue atarget-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 conservicenetworking
:-
En la consola de Google Cloud del proyecto host, ve a la página Intercambio de tráfico entre redes de VPC.
-
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 conservicenetworking
.-
En la consola de Google Cloud, ve a la página VPC compartida.
- Selecciona el Proyecto host.
-
El valor que aparece para
servicenetworking-googleapis-com
en Tu red de VPC debe ser el mismo que el valorauthorizedNetwork
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
:-
En la consola de Google Cloud, ve a la página Balanceo de cargas.
-
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:
- Haz clic en el nombre de un grupo de instancia. Se muestra la página Descripción general del grupo de instancias.
- Haga clic en la pestaña Detalles.
-
Desplázate hasta la sección Herramientas de redes:
-
Verifica que la Red principal aquí sea la misma que el valor
authorizedNetwork
. Por ejemplo,default
. - Haz clic en la pestaña Descripción general.
- En la sección Miembros del grupo de instancias, haz clic en el nombre de una instancia. Se muestra la página Detalles.
-
Desplázate hasta la sección Interfaces de red.
-
Verifica que el valor Red sea el mismo que el valor
authorizedNetwork
. Por ejemplo,default
. - 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 conservicenetworking
Luego, asegúrate de haber intercambiado el tráfico de la red de VPC correcta conservicenetworking
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 lasauthorizedNetwork
es que la red intercambia tráfico conservicenetworking.
Si intercambia tráfico de forma correcta y la red aún no es igual a laauthorizedNetwork,
, 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
-
Si ves errores
503
en la segunda región inmediatamente después de una expansión de región, haz lo siguiente:-
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
yprod
. -
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:
-
En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Haz clic en nombre del Balanceador de cargas. Se abrirá la página Detalles del balanceador de cargas.
-
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:
- 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.
-
-
Asegúrate de que los entornos estén conectados a la instancia nueva mediante la ejecución de la siguiente
llamada a la API:
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