Problemas de roteamento de acesso com a Apigee

Esta é a documentação da Apigee e da Apigee híbrida.
Não há documentação equivalente do Apigee Edge para esse tópico.

Sintoma

Em alguns casos, os clientes externos não conseguem acessar/se conectar à Apigee da maneira que quiserem. Isso inclui falhas de conectividade de rede (falha no handshake de TLS) ou respostas 4xx/5xx da Apigee.

Mensagem de erro

Ao enviar uma solicitação de API do seu cliente para a Apigee, você vê uma falha de handshake de TLS ou uma resposta 4xx/5xx, mesmo que os proxies de API pareçam estar íntegros na IU da Apigee.

Causas possíveis

Causa Descrição Códigos de erro
Erros de TLS no balanceador de carga HTTPS Você gerencia a configuração do TLS do balanceador de carga HTTPS. Investigue erros de TLS nos registros do balanceador de carga HTTPS. Erros de handshake de TLS do endereço IP do balanceador de carga
O Google Cloud Armor bloqueia as solicitações Se você estiver usando o Google Cloud Armor, talvez haja uma regra bloqueando a solicitação. O código de resposta da API pode variar de acordo com a configuração do Google Cloud Armor. As regras de negação podem retornar uma resposta HTTP 403 (não autorizado), 404 (acesso negado) ou 502 (gateway inválido), ou até mesmo outro código de resposta.
As VMs do proxy da Apigee não conseguem encaminhar o tráfego para a instância da Apigee A configuração e a integridade do proxy do roteador de tráfego da API Apigee precisam ser investigadas 502 Server Error
Configuração de rede incorreta Verifique se a rede correta faz peering com a VPC da Apigee. 502 Server error
Ambientes não anexados na nova instância da Apigee criados como parte da expansão da região Depois de criar uma nova instância, como uma segunda região, é preciso anexar ambientes a ela. Caso contrário, o serviço não poderá responder às solicitações de API. 503 error response

Causa: erros de TLS no balanceador de carga HTTPS

Diagnóstico

  1. Encontre o certificado TLS associado ao balanceador de carga.
    1. Como usar o Console do Google Cloud:

      1. No Console do Google Cloud, acesse a página Balanceamento de carga.

        Acessar o "Balanceamento de carga"

      2. Clique em Nome do balanceador de carga. A página Detalhes do balanceador de carga é aberta.

      3. Na área Front-end, na coluna IP:Porta, confira se você está analisando o balanceador de carga certo, verificando o endereço IP e a porta.
      4. Na coluna Certificado, clique no nome do certificado para ver o certificado TLS.
    2. Com um comando gcloud:
      1. Liste os balanceadores de carga com o seguinte comando gcloud. Esse comando também exibe o SSL_CERTIFICATES associado a cada balanceador de carga. 
        gcloud compute target-https-proxies list --project=PROJECT_NAME

        Substitua PROJECT_NAME pelo nome do projeto.

        Algo semelhante ao seguinte é retornado:

        NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP:
      2. Visualize o certificado TLS com o seguinte comando gcloud (supondo que você tenha jq ou uma ferramenta semelhante instalada na sua máquina): 
        gcloud compute ssl-certificates describe CERTICATE_NAME \
--project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -noout

        Substitua CERTIFICATE_NAME pelo nome do certificado. Por exemplo, example-ssl-cert.

        Algo semelhante ao seguinte é retornado:

        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

        Verifique se o nome comum (CN) no certificado corresponde ao Nome do host configurado em Apigee > Administrador > Ambientes > Grupos. Verifique se o certificado é válido e não está expirado. Você pode usar openssl para realizar essas verificações.

  2. Para verificar o certificado TLS retornado pelo balanceador de carga, execute o seguinte comando openssl na máquina cliente. Verifique se esse certificado corresponde ao retornado na etapa 1 acima. 
    openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts

    Substitua:

    • LB_HOSTNAME_OR_IP: o nome do host ou o endereço IP do balanceador de carga. Por exemplo, my-load-balancer.
    • LB_HOSTNAME: o nome do host do balanceador de carga. Por exemplo: my-hostname

    Para verificar se os certificados correspondem, execute o seguinte comando no seu cliente: 

    echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5

    Substitua HOST_NAME pelo nome do host configurado na Apigee (Administrador > Ambientes > Grupos).

    Em seguida, verifique se o md5 corresponde ao executando o seguinte comando gcloud: 

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

    Substitua CERTIFICATE_NAME pelo nome do certificado. Por exemplo, my-certificate

  3. Se os certificados da etapa 1 e da etapa 2 forem correspondentes (ou seja, se os valores de md5 forem correspondentes), prossiga para a coleta de um packet capture no lado do cliente para investigar a falha de handshake de TLS. Use a captura de pacotes no lado do cliente com ferramentas como Wireshark, tcpdump ou qualquer outra ferramenta confiável.
  4. Ative os registros no balanceador de carga seguindo as instruções em Como ativar a geração de registros em um serviço de back-end atual.
  5. Consulte os registros do balanceador de carga para ver se há erros.

Resolução

  1. Se o certificado autogerenciado no balanceador de carga expirar ou tiver valores CN/SAN incorretos, talvez seja necessário substituir o certificado no balanceador de carga.
  2. Se o certificado retornado pelo balanceador de carga na etapa 1 e o certificado na etapa 2 não corresponderem, isso pode significar que o balanceador de carga está exibindo um certificado desatualizado/incorreto e você deve registrar um tíquete com o Atendimento ao cliente do Google Cloud.
  3. Se tcpdump indicar uma falha de handshake de TLS, investigue se a falha de conexão vem do balanceador de carga ou do lado do cliente.
    • Se a falha ou a redefinição da conexão for do lado do cliente, verifique o aplicativo cliente para entender o motivo pelo qual ele está apresentando um comportamento inadequado. Por exemplo, é possível verificar a configuração de rede no lado do cliente ou se o aplicativo cliente tem conectividade com a Apigee.
    • Se você vir a falha/redefinição do próprio balanceador de carga, consulte Resolver problemas gerais de conectividade e registre um tíquete com o Atendimento ao cliente do Google Cloud se necessário.
  4. Se você encontrar erros nos registros do balanceador de carga, consulte Erros 5XX inexplicáveis e registre um tíquete no Atendimento ao cliente do Google Cloud, se necessário.

Se você ainda precisar de ajuda, consulte Coletar informações de diagnóstico.

Causa: Cloud Armor bloqueando as solicitações

Diagnóstico

Se você vir uma resposta de erro 403, 404 ou 502 com base na configuração do Cloud Armor, analise o balanceador de carga e a configuração do MIG para verificar se estão configurados corretamente e parecem íntegros.

  1. Se você estiver usando o Google Cloud Armor no seu ambiente do Google Cloud, analise a configuração do Google Cloud Armor para encontrar regras que possam estar bloqueando a solicitação. As políticas de segurança podem ser encontradas em Configurar políticas de segurança do Google Cloud Armor.
  2. Se você não tiver certeza de qual regra está negando o tráfego, tente ativar a geração de registros no balanceador de carga, conforme descrito em Como ativar a geração de registros em um serviço de back-end atual.

  3. Depois que a geração de registros estiver ativada, faça uma consulta de registros para encontrar solicitações bloqueadas pelas políticas do Google Cloud Armor:

    1. No console do Google Cloud, acesse a página do Explorador de registros.

      Acessar o Explorador de registros

    2. Cole o seguinte no painel Consulta:

      jsonPayload.enforcedSecurityPolicy.outcome="DENY"
    3. Clique em Executar consulta.

    4. O nome da política aplicada é exibido em jsonPayload.enforcedSecurityPolicy.name no painel Resultados da consulta:

Resolução

Modifique as regras/configuração do Google Cloud Armor de acordo com suas necessidades para resolver esse problema. Se precisar de ajuda, entre em contato com o Atendimento ao cliente do Google Cloud.

Causa: as VMs do proxy da Apigee não conseguem encaminhar o tráfego para a instância da Apigee

Diagnóstico

  1. Se os clientes da API receberem erros HTTP 502 com a mensagem de erro a seguir, as VMs do proxy do roteador de tráfego da API Apigee poderão estar em um estado não íntegro.

    Erros 502, como os seguintes, podem ser recebidos pelos clientes: 

    <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>

    Verifique se há mensagens de erro nos registros do balanceador de carga, como as seguintes:

    statusDetails: "failed_to_pick_backend"
severity: "WARNING"

    Há um conjunto de VMs (com um prefixo apigee-proxy) em execução em um grupo gerenciado de instâncias (MIG) que encaminham o tráfego para a instância da Apigee. Se você estiver vendo mensagens como a mostrada acima, verifique a integridade da parte das VMs apigee-proxy do grupo de instâncias seguindo estas etapas:

    1. No Console do Google Cloud, acesse a página Balanceamento de carga.

      Acessar o "Balanceamento de carga"

    2. Clique em Nome do balanceador de carga. A página Detalhes do balanceador de carga é aberta.

    3. Na seção Back-end, verifique se todos os back-ends do balanceador de carga têm uma marca de seleção verde na coluna Íntegra.

  2. Verifique se o endereço IP do endpoint no modelo MIG corresponde ao endereço IP da instância da Apigee.

    As VMs apigee-proxy são criadas usando um modelo de instância. O modelo define o endereço IP ENDPOINT para se conectar ao endereço IP da instância da Apigee.

    1. Consiga o endereço IP da instância da Apigee: 
      curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"

      Substitua:

      • ORG_NAME: o nome da organização. Exemplo, my-org.
      • INSTANCE_NAME: o nome da instância. Exemplo, apigee-proxy-example.

    2. Ou consiga o endereço IP da instância da Apigee usando a IU da Apigee:

      1. Na IU da Apigee, clique em Administrador > Instâncias.

      2. A coluna Endereços IP lista o endereço IP:

    3. Consiga o endereço IP ENDPOINT do modelo:

      1. No Console do Google Cloud, acesse a página Balanceamento de carga.

        Acessar o "Balanceamento de carga"

      2. Clique em Nome do balanceador de carga. A página Detalhes do balanceador de carga é aberta.
      3. Na área Back-end, clique no nome de um serviço de back-end.

      4. Na área Membros do grupo de instâncias, clique em um nome de Modelo.

      5. Na página do modelo, role até Metadados personalizados, que é onde você verá o endereço IP ENDPOINT:

    Verifique se o endereço IP ENDPOINT corresponde ao endereço IP da Apigee retornado na etapa 2. Se não corresponder, acesse Resolução.

Resolução

  1. Se oapigee-proxy As VMs no grupo de instâncias exibem um status não íntegro. Verifique se você tem uma regra de firewall que permita que os intervalos de endereços IP de balanceamento de carga130.211.0.0/22 e 35.191.0.0/16 acessar o MIG.

  2. No Console do Google Cloud, acesse a página Firewall.

    Acessar o Firewall

  3. Verifique se existe uma regra de firewall de entrada com target-tag como gke-apigee-proxy e intervalos de IP de origem como 130.211.0.0/22 e 35.191.0.0/16 na porta 443 TCP:

    Se o MIG tiver uma tag diferente de gke-apigee-proxy, verifique se a tag foi adicionada a target-tag na regra de firewall.

    Adicione a regra de firewall se ela não existir.

  4. Se o endereço IP ENDPOINT não corresponder ao endereço IP da instância da Apigee, é possível que a instância tenha sido excluída e recriada, o que resultaria em um endereço IP que não corresponde mais ao no modelo. Para atualizar o modelo para usar o novo endereço IP, siga as instruções em Como alterar IPs de instância.

Causa: configuração de rede incorreta

Diagnóstico

  1. Localize o valor de authorizedNetwork executando a seguinte chamada de API: 

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

    Algo semelhante ao seguinte é retornado:

    {
  "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"
}

    Neste exemplo, o valor de authorizedNetwork é padrão.

  2. Verifique se o valor de authorizedNetwork é o mesmo da rede que está fazendo peering com servicenetworking:

    1. No console do Google Cloud do projeto host, acesse a página Peering da rede VPC.

      Acessar o peering de rede VPC

    2. O valor listado para servicenetworking-googleapis-com em Sua rede VPC precisa ser igual ao valor retornado da chamada de API. Por exemplo, default.

  3. Se você estiver usando uma VPC compartilhada, verifique se o valor authorizedNetwork tem o valor da VPC real no projeto host que faz peering com servicenetworking.

    1. No console do Google Cloud, acesse a página VPC compartilhada.

      Acessar VPC compartilhada

    2. Selecione o projeto host.
    3. O valor listado para servicenetworking-googleapis-com em Sua rede VPC precisa ser igual ao valor authorizedNetwork retornado da chamada de API. Por exemplo, default.

  4. Verifique se o grupo de instâncias associado ao balanceador de carga é da mesma rede que o valor authorizedNetwork:

    1. No Console do Google Cloud, acesse a página Balanceamento de carga.

      Acessar o "Balanceamento de carga"

    2. Clique no nome de um balanceador de carga. A página Detalhes do balanceador de carga é aberta. Uma lista de grupos de instâncias é exibida na área Back-end:

    3. Clique no nome de uma instância. A página Visão geral do grupo de instâncias é exibida.
    4. Clique na guia Detalhes.

    5. Role até a seção Rede:

    6. Verifique se a Rede principal mostrada aqui é igual ao valor authorizedNetwork. Por exemplo, default.
    7. Clique na guia Visão geral.
    8. Na seção Membros do grupo de instâncias, clique no nome de uma instância. A página Detalhes é exibida.

    9. Role até a seção Interfaces de rede:

    10. Verifique se o valor de Rede é igual ao valor de authorizedNetwork. Por exemplo, default.
    11. Acesse a guia Visão geral e repita a etapa h até a etapa j para cada instância na seção Membros do grupo de instâncias.

Resolução

  1. Se na etapa 2 ou etapa 3, o valor de authorizedNetwork não será igual à rede que faz peering com servicenetworking, em seguida, verifique se você fez peering com a rede VPC correta com servicenetworking seguindo as etapas da Etapa 4: configurar a rede de serviços.
  2. Se nas etapas 4f e 4j, os valores de rede não forem iguais ao valor de authorizedNetwork, verifique se o authorizedNetwork é a rede com peering com servicenetworking. Se estiver com peering correto e a rede ainda não for igual à authorizedNetwork,, isso significa que o grupo de instâncias foi criado incorretamente e que é preciso entrar em contato com o Atendimento ao cliente do Google Cloud.

Causa: ambiente não anexado na nova instância da Apigee criada como parte da expansão da região

Diagnóstico

  1. Você vê um erro 503 no lado do cliente. Por exemplo: 
    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. Se você estiver vendo erros 503 na segunda região imediatamente após uma expansão de região:
    1. Verifique se os ambientes estão anexados à nova instância executando a seguinte chamada de API: 
      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"

      Exemplo:

      curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"

      Algo semelhante ao seguinte é retornado:

      {
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}

      Neste exemplo, a instância chamada apigee-proxy-example está anexada a dois ambientes: dev e prod.

    2. Verifique se o grupo gerenciado de instâncias (MIG) da segunda região foi criado e está sendo exibido como íntegro:

      1. No Console do Google Cloud, acesse a página Balanceamento de carga.

        Acessar o "Balanceamento de carga"

      2. Clique em Nome do balanceador de carga. A página Detalhes do balanceador de carga é aberta.
      3. Em Back-end, você verá dois MIGs: um para a região 1 e outro para a região 2. Verifique se ambos estão íntegros:

      4. Valide o segundo MIG seguindo as etapas em As VMs do proxy da Apigee não conseguem encaminhar o tráfego para a instância da Apigee.

Resolução

  1. Se a nova instância não estiver anexada ao ambiente, anexe-a ao ambiente seguindo as instruções em Anexar ambientes à nova instância.

    Outra opção é verificar se o balanceador de carga encaminha a solicitação para o back-end correto em que o ambiente já está anexado. Por exemplo, de um env que não é de produção. É possível anexar somente uma região. No entanto, o balanceador de carga pode estar roteando a solicitação para a região errada. Você precisaria atualizar a configuração do balanceador de carga para garantir que ele seja roteado para a região correta.

  2. Se um MIG não estiver íntegro, consulteDiagnóstico e Resolução em As VMs do proxy da Apigee não conseguem encaminhar o tráfego para a instância da Apigee de dois minutos.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o Suporte do Google Cloud:

  • Organização da Apigee
  • O ambiente e o proxy de API veem o problema
  • Download da sessão de depuração concluído (se o problema for intermitente)
  • Saída de curl detalhada de uma solicitação com falha.
  • Balanceador de carga configurado para enviar chamadas de API para a Apigee