Esta página foi traduzida pela API Cloud Translation.

Aceda a problemas de encaminhamento com o Apigee

Está a ver a documentação do Apigee e do Apigee Hybrid.
Não existe um equivalente na documentação do Apigee Edge para este tópico.

Sintoma

Em alguns casos, os clientes externos não conseguem aceder/estabelecer ligação ao Apigee da forma pretendida. Estes incluem falhas de conetividade de rede (falhas de TLS handshake) ou respostas 4xx/5xx do Apigee.

Mensagem de erro

Quando envia um pedido de API do seu cliente para o Apigee, vê uma falha de handshake de TLS ou uma resposta 4xx/5xx, mesmo que os proxies de API possam parecer em bom estado na IU do Apigee.

Causas possíveis

Causa	Descrição	Códigos de erro
Erros de TLS no balanceador de carga HTTPS	Gerir a configuração do TLS do balanceador de carga HTTPS. Investigue quaisquer erros de TLS nos registos do balanceador de carga HTTPS.	Erros de handshake TLS do endereço IP do equilibrador de carga
O Google Cloud Armor está a bloquear os pedidos	Se estiver a usar o Google Cloud Armor, pode existir uma regra a bloquear o pedido.	O código de resposta da API pode variar com base na configuração do Google Cloud Armor. As regras de recusa podem devolver uma resposta `HTTP 403` (Não autorizado), `404` (Acesso recusado) ou `502` (Gateway inválido) ou até outro código de resposta.
As VMs de proxy do Apigee não conseguem encaminhar o tráfego para a instância do Apigee	É necessário investigar a configuração do proxy do router de tráfego da API Apigee e o respetivo estado	`502 Server Error`
Configuração de rede incorreta	Certifique-se de que a rede correta está em peering com a VPC do Apigee.	`502 Server error`
Ambientes não associados na nova instância do Apigee criada como parte da expansão da região	Depois de criar uma nova instância, por exemplo, uma segunda região, tem de associar-lhe ambientes. Caso contrário, não pode responder a pedidos de API.	`503 error response`

Causa: erros de TLS no balanceador de carga HTTPS

Diagnóstico

Encontre o certificado TLS associado ao balanceador de carga.

Usar a consola do Google Cloud:
1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
  
  Aceder ao balanceamento de carga
2. Clique no Nome do balanceador de carga. É apresentada a página Detalhes do balanceador de carga.
3. Na área Front-end, na coluna IP:Porta, certifique-se de que está a ver o balanceador de carga correto verificando o respetivo endereço IP e porta.
4. Na coluna Certificado, clique no nome do certificado para ver o certificado TLS.

Usando um comando gcloud:

Apresente uma lista dos balanceadores de carga com o seguinte comando gcloud. Este comando também apresenta SSL_CERTIFICATES associados a cada equilibrador de carga.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Substitua PROJECT_NAME pelo nome do seu projeto.

É devolvido algo semelhante ao seguinte:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

Veja o certificado TLS com o seguinte comando gcloud (isto pressupõe que tem o

jq

ou uma ferramenta semelhante instalada no seu computador):

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.

É devolvido algo semelhante ao seguinte:

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

Certifique-se de que o nome comum (CN) no certificado corresponde ao nome de anfitrião configurado no Apigee > Administração > Ambientes > Grupos. Certifique-se de que o certificado é válido e não expirou. Pode usar openssl para fazer estas verificações.

Para verificar o certificado TLS devolvido pelo equilibrador de carga, execute o seguinte comando openssl a partir do computador cliente. Verifique se este certificado corresponde ao devolvido no passo 1 acima.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
Substitua o seguinte:
- LB_HOSTNAME_OR_IP: o nome de anfitrião ou o endereço IP do balanceador de carga. Por exemplo, my-load-balancer.
- LB_HOSTNAME: o nome do anfitrião do balanceador de carga. Por exemplo, my-hostname.
Para verificar se os certificados correspondem, execute o seguinte comando a partir do cliente:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Substitua HOST_NAME pelo nome do anfitrião configurado no Apigee (Administração > Ambientes > Grupos).

Em seguida, verifique se o md5 corresponde 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
Se os certificados do passo 1 e do passo 2 corresponderem (ou seja, se os valores md5 corresponderem), prossiga para recolher um packet capture no lado do cliente para investigar a falha de handshake TLS. Pode fazer a captura de pacotes no lado do cliente com ferramentas como Wireshark, tcpdump ou quaisquer outras ferramentas fiáveis.
Ative os registos no balanceador de carga seguindo as instruções em Ativar o registo num serviço de back-end existente.
Reveja os registos do equilibrador de carga para verificar se existem erros.

Resolução

Se o seu certificado autogerido no balanceador de carga tiver expirado ou tiver valores CN/SAN incorretos, pode ter de substituir o certificado no balanceador de carga.
Se o certificado devolvido pelo equilibrador de carga no passo 1 e o certificado no passo 2 não corresponderem, pode significar que o equilibrador de carga está a publicar um certificado desatualizado/incorreto e deve apresentar um pedido junto ao apoio técnico do Google Cloud.
Se um tcpdump indicar uma falha de handshake TLS, investigue se a falha de ligação está a ocorrer no equilibrador de carga ou no lado do cliente.
- Se a falha ou a reposição da ligação for do lado do cliente, verifique a aplicação cliente para compreender por que motivo está a ter um comportamento incorreto. Por exemplo, pode verificar a configuração de rede no lado do cliente ou confirmar se a aplicação cliente tem conetividade com o Apigee.
- Se vir a falha/reposição do próprio equilibrador de carga, consulte o artigo Resolva problemas gerais de conetividade e registe um pedido junto do apoio ao cliente do Google Cloud, se necessário.
Se vir erros nos registos do equilibrador de carga, consulte o artigo Erros 5XX inexplicáveis e apresente um pedido ao apoio técnico ao cliente do Google Cloud, se necessário.

Se ainda precisar de assistência, consulte a secção Tem de recolher informações de diagnóstico.

Causa: o Cloud Armor está a bloquear os pedidos

Diagnóstico

Se vir uma resposta de erro 403, 404 ou 502 com base na configuração do Cloud Armor, reveja o balanceador de carga e a configuração do MIG para verificar se estão configurados corretamente e aparecem como estando em bom estado.

Se estiver a usar o Google Cloud Armor no seu Google Cloud ambiente, reveja a configuração do Google Cloud Armor para verificar se existem regras que possam estar a bloquear o pedido. Pode encontrar as políticas de segurança em Configure as políticas de segurança do Google Cloud Armor.
Se não tiver a certeza de que regra está a recusar o tráfego, pode tentar ativar o registo no equilibrador de carga, conforme descrito em Ativar o registo num serviço de back-end existente.
Assim que o registo estiver ativado, execute uma consulta de registos para encontrar pedidos bloqueados pelas políticas do Google Cloud Armor:
1. Na Google Cloud consola, aceda à página Explorador de registos.
  
  Aceda ao Explorador de registos
2. Cole o seguinte no painel Consulta:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Clique em Executar consulta.
4. O nome da política aplicada é apresentado em jsonPayload.enforcedSecurityPolicy.name no painel Resultados da consulta:

Resolução

Modifique as regras/configuração do Google Cloud Armor para se alinharem com as suas necessidades de modo a resolver este problema. Se precisar de ajuda com este processo, contacte o apoio ao cliente do Google Cloud.

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

Diagnóstico

Se os clientes da API receberem erros HTTP 502 com a seguinte mensagem de erro, significa que as VMs do proxy do router de tráfego da API Apigee podem estar num estado não saudável.

Os clientes podem receber erros 502, como os seguintes:
```
<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>
```
Reveja os registos do equilibrador de carga para ver mensagens de erro, como as seguintes:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
Existe um conjunto de VMs (com um prefixo apigee-proxy) que são executadas num grupo de instâncias geridas (GIG) que encaminham o tráfego para a instância do Apigee. Se vir mensagens como as acima, verifique o estado de funcionamento das VMs que fazem parte do grupo de instâncias através dos seguintes passos:apigee-proxy
1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
  
  Aceder ao balanceamento de carga
2. Clique no Nome do balanceador de carga. É apresentada a página Detalhes do equilibrador de carga.
3. Na secção Backend, verifique se todos os backends do equilibrador de carga têm uma marca de verificação verde na coluna Em bom estado.
Verifique se o endereço IP do ponto final no modelo do MIG corresponde ao endereço IP da instância do Apigee.

As VMs são criadas com um modelo de instância.apigee-proxy O modelo define o ENDPOINTendereço IP para estabelecer ligação ao endereço IP da instância do Apigee.
1. Obtenha o endereço IP da instância do Apigee:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  Substitua o seguinte:
  - ORG_NAME: o nome da sua organização. Por exemplo, my-org.
  - INSTANCE_NAME: o nome da sua instância. Por exemplo, apigee-proxy-example.
2. Em alternativa, obtenha o endereço IP da instância do Apigee através da IU do Apigee:
  1. Na IU do Apigee, clique em Administração > Instâncias.
  2. A coluna Endereços IP apresenta o endereço IP:
3. Obtenha o endereço IP ENDPOINT a partir do modelo:
  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
    
    Aceder ao balanceamento de carga
  2. Clique no Nome do balanceador de carga. É apresentada a página Detalhes do equilibrador de carga.
  3. Na área Backend, clique no nome de um serviço de backend.
  4. Na área Membros do grupo de instâncias, clique no nome de um modelo.
  5. Na página do modelo, desloque a página até Metadados personalizados, onde vai ver o endereço IP do PONTO FINAL:
Certifique-se de que o endereço IP do ENDPOINT corresponde ao endereço IP do Apigee devolvido no passo 2. Se não corresponder, aceda à Resolução.

Resolução

Se as VMs apigee-proxy no grupo de instâncias apresentarem um estado não saudável, certifique-se de que tem uma regra de firewall implementada que permite que os intervalos de endereços IP de balanceamento de carga 130.211.0.0/22 e 35.191.0.0/16 acedam ao MIG.
Na Google Cloud consola, aceda à página Firewall.

Aceda à firewall
Certifique-se de que 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 etiqueta diferente de gke-apigee-proxy, certifique-se de que a etiqueta é adicionada ao target-tag na regra de firewall.

Se a regra de firewall não existir, adicione-a.
Se o endereço IP do ENDPOINT não corresponder ao endereço IP da instância do Apigee, é possível que a instância tenha sido eliminada e recriada, o que resultaria num endereço IP que já não corresponde ao endereço IP no modelo. Para atualizar o modelo de modo a usar o novo endereço IP, siga as instruções em Alterar IPs de instâncias.

Causa: configuração de rede incorreta

Diagnóstico

Localize o valor de authorizedNetwork executando a seguinte chamada API:

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

É devolvido algo semelhante ao seguinte:

{
  "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 é o predefinido.

Verifique se o valor de authorizedNetwork é igual à rede que tem uma relação de intercâmbio com servicenetworking:
1. Na Google Cloud consola do projeto anfitrião, aceda à página Interligação de redes VPC.
  
  Aceda ao intercâmbio da rede da VPC
2. O valor indicado para servicenetworking-googleapis-com na sua rede de VPC deve ser igual ao valor devolvido pela chamada API. Por exemplo, default.
Se estiver a usar uma VPC partilhada, certifique-se de que o valor de authorizedNetwork tem o valor da VPC real no projeto anfitrião que está em peering com servicenetworking.
1. Na Google Cloud consola, aceda à página VPC partilhada.
  
  Aceda à VPC partilhada
2. Selecione o projeto anfitrião.
3. O valor indicado para servicenetworking-googleapis-com em A sua rede VPC deve ser igual ao valor authorizedNetwork devolvido pela chamada API. Por exemplo, default.
Verifique se o grupo de instâncias associado ao equilibrador de carga está na mesma rede que o valor de authorizedNetwork:
1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
  
  Aceder ao balanceamento de carga
2. Clique no nome de um balanceador de carga. É apresentada a página Detalhes do equilibrador de carga. É apresentada uma lista de grupos de instâncias na área Backend:
3. Clique no nome de um grupo de instâncias. É apresentada a página Vista geral do grupo de instâncias.
4. Clique no separador Detalhes.
5. Desloque a página até à secção Rede:
6. Verifique se a rede principal aqui é igual ao valor authorizedNetwork. Por exemplo, default.
7. Clique no separador Vista geral.
8. Na secção Membros do grupo de instâncias, clique no nome de uma instância. É apresentada a página Detalhes.
9. Desloque a página até à secção Interfaces de rede:
10. Verifique se o valor Network é igual ao valor authorizedNetwork. Por exemplo, default.
11. Aceda ao separador Vista geral e repita os passos h a j para cada instância na secção Membros do grupo de instâncias.

Resolução

Se, no passo 2 ou no passo 3, o valor authorizedNetwork não for igual à rede que está em peering com servicenetworking, certifique-se de que fez o peering da rede VPC correta com servicenetworking seguindo os passos no Passo 4: configure a rede de serviços.
Se, nos passos 4f e 4j, os valores da rede não forem iguais ao valor de authorizedNetwork, verifique se authorizedNetwork é a rede com peering com servicenetworking. . Se o peering estiver correto e a rede continuar a não ser igual a authorizedNetwork,, significa que o grupo de instâncias foi criado incorretamente e deve contactar o apoio ao cliente do Google Cloud.

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

Diagnóstico

Vê um erro 503 do 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
```
Nota: este erro 503 não é apresentado no rastreio de depuração porque os pedidos nunca chegam ao processador de mensagens de tempo de execução.
Se estiver a ver erros 503 na segunda região imediatamente após uma expansão da região:
1. Certifique-se de que os ambientes estão anexados à nova instância através da execução da seguinte chamada da API:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  Por exemplo:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  É devolvido algo semelhante ao seguinte:
```
{
  "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 denominada apigee-proxy-example está associada a dois ambientes: dev e prod.
2. Certifique-se de que o grupo de instâncias geridas (MIG) para a segunda região foi criado e está a ser apresentado como em bom estado:
  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
    
    Aceder ao balanceamento de carga
  2. Clique no Nome do balanceador de carga. É apresentada a página Detalhes do equilibrador de carga.
  3. Em Backend, deve ver dois MIGs: um para a região 1 e outro para a região 2. Verifique se ambos estão em bom estado:
  4. Valide o segundo MIG seguindo os passos em As VMs de proxy do Apigee não conseguem encaminhar o tráfego para a instância do Apigee.

Resolução

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

Outra opção é certificar-se de que o balanceador de carga encaminha o pedido para o backend correto onde o ambiente já está anexado. Por exemplo, de um ambiente de não produção. Pode querer anexar isto apenas a uma região. No entanto, o balanceador de carga pode estar a encaminhar o pedido para a região errada. Tem de atualizar a configuração do equilibrador de carga para se certificar de que encaminha para a região correta.
Se um MIG não estiver em bom estado, consulte o Diagnóstico e a Resolução em As VMs do proxy do Apigee não conseguem encaminhar o tráfego para a instância do Apigee.

Tem de recolher informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, recolha as seguintes informações de diagnóstico e, em seguida, contacte o apoio ao cliente da Google Cloud:

Organização do Apigee
O ambiente e o proxy de API estão a detetar o problema
Sessão de depuração transferida (se o problema for intermitente)
Resultado detalhado do curl de um pedido com falha.
Equilibrador de carga configurado para enviar chamadas API para o Apigee

Aceda a problemas de encaminhamento com o Apigee Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Sintoma

Mensagem de erro

Causas possíveis

Causa: erros de TLS no balanceador de carga HTTPS

Diagnóstico

Resolução

Causa: o Cloud Armor está a bloquear os pedidos

Diagnóstico

Resolução

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

Diagnóstico

Resolução

Causa: configuração de rede incorreta

Diagnóstico

Resolução

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

Diagnóstico

Resolução

Tem de recolher informações de diagnóstico

Aceda a problemas de encaminhamento com o Apigee