Questa pagina è stata tradotta dall'API Cloud Translation.

Problemi di routing dell'accesso con Apigee

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste una documentazione Apigee Edge equivalente per questo argomento.

Sintomo

In alcuni casi, i client esterni non sono in grado di accedere/connettersi ad Apigee nel modo desiderato. Questi includono errori di connettività di rete (handshake TLS non riuscito) o risposte 4xx/5xx da Apigee.

Messaggio di errore

Quando invii una richiesta API dal client ad Apigee, visualizzi un errore di handshake TLS o una risposta 4xx/5xx anche se i proxy API potrebbero sembrare integri nella UI di Apigee.

Cause possibili

Causa	Descrizione	Codici di errore
Errori TLS nel bilanciatore del carico HTTPS	Gestisci la configurazione TLS del bilanciatore del carico HTTPS. Esamina eventuali errori TLS nei log del bilanciatore del carico HTTPS.	Errori di handshake TLS dall'indirizzo IP del bilanciatore del carico
Google Cloud Armor blocca le richieste	Se utilizzi Google Cloud Armor, potrebbe essere presente una regola che blocca la richiesta.	Il codice di risposta dell'API può variare in base alla configurazione di Google Cloud Armor. Le regole di negazione possono restituire una risposta `HTTP 403` (Non autorizzato), `404` (Accesso negato) o `502` (Bad Gateway) o anche un altro codice di risposta.
Le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee	È necessario esaminare la configurazione del proxy del router del traffico API Apigee e il suo stato	`502 Server Error`
Configurazione di rete errata	Assicurati che la rete corretta sia in peering con il VPC Apigee.	`502 Server error`
Ambienti scollegati nella nuova istanza Apigee creata nell'ambito dell'espansione della regione	Dopo aver creato una nuova istanza, ad esempio una seconda regione, devi collegare gli ambienti, altrimenti non può rispondere alle richieste API.	`503 error response`

Causa: errori TLS nel bilanciatore del carico HTTPS

Diagnosi

Trova il certificato TLS associato al bilanciatore del carico.

Utilizzando la console Google Cloud:
1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
  
  Vai a Bilanciamento del carico
2. Fai clic sul nome del bilanciatore del carico. Viene visualizzata la pagina Dettagli del bilanciatore del carico.
3. Nell'area Frontend, nella colonna IP:Porta, assicurati di esaminare il bilanciatore del carico corretto verificando l'indirizzo IP e la porta.
4. Nella colonna Certificato, fai clic sul nome del certificato per visualizzare il certificato TLS.

Utilizzo di un comando gcloud:

Elenca i bilanciatori del carico con il seguente comando gcloud. Questo comando mostra anche SSL_CERTIFICATES associato a ogni bilanciatore del carico.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Sostituisci PROJECT_NAME con il nome del progetto.

Viene restituito un risultato simile al seguente:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

Visualizza il certificato TLS con il seguente comando gcloud (presuppone che tu abbia

jq

o uno strumento simile installato sulla tua macchina):

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

Sostituisci CERTIFICATE_NAME con il nome del certificato. Ad esempio, example-ssl-cert.

Viene restituito un risultato simile al seguente:

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

Assicurati che il nome comune (CN) nel certificato corrisponda al nome host configurato in Apigee > Admin > Ambienti > Gruppi. Assicurati che il certificato sia valido e non scaduto. Puoi utilizzare openssl per eseguire questi controlli.

Per controllare il certificato TLS restituito dal bilanciatore del carico, esegui il seguente comando openssl dalla macchina client. Verifica che questo certificato corrisponda a quello restituito nel passaggio 1 riportato sopra.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
Sostituisci quanto segue:
- LB_HOSTNAME_OR_IP: il nome host o l'indirizzo IP del bilanciatore del carico. Ad esempio, my-load-balancer.
- LB_HOSTNAME: il nome host del bilanciatore del carico. Ad esempio, my-hostname.
Per verificare che i certificati corrispondano, esegui questo comando dal client:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Sostituisci HOST_NAME con il nome host configurato in Apigee (Amministrazione > Ambienti > Gruppi).

Verifica poi che md5 corrisponda eseguendo il seguente comando gcloud:
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
Sostituisci CERTIFICATE_NAME con il nome del certificato. Ad esempio, my-certificate
Se i certificati del passaggio 1 e del passaggio 2 corrispondono (ovvero se i valori md5 corrispondono), procedi alla raccolta di un packet capture sul lato client per analizzare l'errore di handshake TLS. Puoi eseguire l'acquisizione dei pacchetti sul lato client con strumenti come Wireshark, tcpdump o qualsiasi altro strumento affidabile.
Abilita i log sul bilanciatore del carico seguendo le istruzioni riportate in Abilitazione del logging su un servizio di backend esistente.
Controlla la presenza di errori nei log del bilanciatore del carico.

Risoluzione

Se il certificato autogestito sul bilanciatore del carico è scaduto o ha valori CN/SAN errati, potrebbe essere necessario sostituire il certificato sul bilanciatore del carico.
Se il certificato restituito dal bilanciamento del carico nel passaggio 1 e il certificato nel passaggio 2 non corrispondono, potrebbe significare che il bilanciamento del carico sta pubblicando un certificato obsoleto/errato e devi presentare un ticket all'assistenza clienti Google Cloud.
Se un tcpdump indica un errore di handshake TLS, verifica se l'errore di connessione proviene dal bilanciatore del carico o dal lato client.
- Se l'errore o il ripristino della connessione si verifica lato client, controlla l'applicazione client per capire perché non funziona correttamente. Ad esempio, puoi controllare la configurazione di rete sul lato client o verificare che l'applicazione client abbia la connettività con Apigee.
- Se visualizzi l'errore/il ripristino dal bilanciatore del carico stesso, consulta Risolvere i problemi generali di connettività e, se necessario, invia un ticket all'assistenza clienti Google Cloud.
Se visualizzi errori nei log del bilanciatore del carico, consulta Errori 5XX inspiegabili e, se necessario, invia un ticket all'assistenza clienti Google Cloud.

Se hai ancora bisogno di assistenza, consulta Informazioni di diagnostica da raccogliere.

Causa: Cloud Armor blocca le richieste

Diagnosi

Se visualizzi una risposta di errore 403, 404 o 502 in base alla configurazione di Cloud Armor, esamina la configurazione del bilanciatore del carico e del MIG per verificare che siano configurati correttamente e che appaiano integri.

Se utilizzi Google Cloud Armor nel tuo ambiente Google Cloud , esamina la configurazione di Google Cloud Armor per verificare la presenza di regole che potrebbero bloccare la richiesta. I criteri di sicurezza sono disponibili in Configura i criteri di sicurezza di Google Cloud Armor.
Se non sai quale regola nega il traffico, puoi provare ad attivare la registrazione nel bilanciatore del carico come descritto in Attivazione della registrazione in un servizio di backend esistente.
Una volta attivato il logging, esegui una query sui log per trovare eventuali richieste bloccate dalle policy di Google Cloud Armor:
1. Nella console Google Cloud , vai alla pagina Esplora log.
  
  Vai a Esplora log
2. Incolla quanto segue nel riquadro Query:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Fai clic su Esegui query.
4. Il nome della policy applicata viene visualizzato in jsonPayload.enforcedSecurityPolicy.name nel riquadro Risultati query:

Risoluzione

Modifica le regole/la configurazione di Google Cloud Armor in base alle tue esigenze per risolvere il problema. Se hai bisogno di assistenza, contatta l'assistenza clienti Google Cloud.

Causa: le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee

Diagnosi

Se i client API ricevono errori HTTP 502 con il seguente messaggio di errore, le VM proxy del router del traffico API Apigee potrebbero essere in uno stato non integro.

I client potrebbero ricevere errori 502 come i seguenti:
```
<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>
```
Esamina i log del bilanciatore del carico per individuare messaggi di errore come i seguenti:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
Esiste un insieme di VM (con un prefisso apigee-proxy) in esecuzione in un gruppo di istanze gestite (MIG) che inoltrano il traffico all'istanza Apigee. Se visualizzi messaggi come quello riportato sopra, controlla l'integrità delle VM apigee-proxy che fanno parte del gruppo di istanze seguendo questi passaggi:
1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
  
  Vai a Bilanciamento del carico
2. Fai clic sul nome del bilanciatore del carico. Viene visualizzata la pagina Dettagli del bilanciatore del carico.
3. Nella sezione Backend, verifica che tutti i backend del bilanciatore del carico siano contrassegnati da un segno di spunta verde nella colonna Stato integro.
Verifica che l'indirizzo IP dell'endpoint nel modello MIG corrisponda all'indirizzo IP dell'istanza Apigee.

Le VM apigee-proxy vengono create utilizzando un modello di istanza. Il modello definisce l'indirizzo IP ENDPOINT per la connessione all'indirizzo IP dell'istanza Apigee.
1. Ottieni l'indirizzo IP dell'istanza Apigee:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  Sostituisci quanto segue:
  - ORG_NAME: il nome della tua organizzazione. Ad esempio, my-org.
  - INSTANCE_NAME: il nome dell'istanza. Ad esempio, apigee-proxy-example.
2. In alternativa, recupera l'indirizzo IP dell'istanza Apigee utilizzando l'interfaccia utente Apigee:
  1. Nell'interfaccia utente Apigee, fai clic su Amministrazione > Istanze.
  2. La colonna Indirizzi IP elenca l'indirizzo IP:
3. Ottieni l'indirizzo IP di ENDPOINT dal modello:
  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
    
    Vai a Bilanciamento del carico
  2. Fai clic sul nome del bilanciatore del carico. Viene visualizzata la pagina Dettagli del bilanciatore del carico.
  3. Nell'area Backend, fai clic sul nome di un servizio di backend.
  4. Nell'area Membri del gruppo di istanze, fai clic sul nome di un template.
  5. Nella pagina del modello, scorri fino a Metadati personalizzati, dove vedrai l'indirizzo IP ENDPOINT:
Assicurati che l'indirizzo IP ENDPOINT corrisponda all'indirizzo IP di Apigee restituito nel passaggio 2. Se non corrisponde, vai a Risoluzione.

Risoluzione

Se le VM apigee-proxy nel gruppo di istanze mostrano uno stato non integro, assicurati di avere una regola firewall che consenta agli intervalli di indirizzi IP di bilanciamento del carico 130.211.0.0/22 e 35.191.0.0/16 di accedere al MIG.
Nella console Google Cloud , vai alla pagina Firewall.

Vai a Firewall
Assicurati che esista una regola firewall in entrata con target-tag come gke-apigee-proxy e intervalli IP di origine come 130.211.0.0/22 e 35.191.0.0/16 sulla porta 443 TCP:

Se il MIG ha un tag diverso da gke-apigee-proxy, assicurati che il tag venga aggiunto a target-tag nella regola firewall.

Se la regola firewall non esiste, aggiungila.
Se l'indirizzo IP ENDPOINT non corrisponde all'indirizzo IP dell'istanza Apigee, è possibile che l'istanza sia stata eliminata e ricreata, il che comporterebbe un indirizzo IP che non corrisponde più a quello nel modello. Per aggiornare il modello in modo che utilizzi il nuovo indirizzo IP, segui le istruzioni riportate in Modifica degli IP delle istanze.

Causa: configurazione di rete errata

Diagnosi

Individua il valore di authorizedNetwork eseguendo la seguente chiamata API:

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

Viene restituito un risultato simile al seguente:

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

In questo esempio, il valore di authorizedNetwork è predefinito.

Verifica che il valore di authorizedNetwork sia uguale alla rete in peering con servicenetworking:
1. Nella console Google Cloud del progetto host, vai alla pagina Peering di reti VPC.
  
  Vai al peering di rete VPC.
2. Il valore elencato per servicenetworking-googleapis-com in La tua rete VPC deve essere uguale al valore restituito dalla chiamata API. Ad esempio: default.
Se utilizzi un VPC condiviso, assicurati che il valore di authorizedNetwork sia quello del VPC effettivo nel progetto host in peering con servicenetworking.
1. Nella console Google Cloud , vai alla pagina VPC condiviso.
  
  Vai a VPC condiviso
2. Seleziona il progetto host.
3. Il valore elencato per servicenetworking-googleapis-com in La tua rete VPC deve essere uguale al valore authorizedNetwork restituito dalla chiamata API. Ad esempio: default.
Verifica che il gruppo di istanze associato al bilanciatore del carico si trovi nella stessa rete del valore authorizedNetwork:
1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
  
  Vai a Bilanciamento del carico
2. Fai clic sul nome di un bilanciatore del carico. Viene visualizzata la pagina Dettagli del bilanciatore del carico. Nell'area Backend viene visualizzato un elenco di gruppi di istanze:
3. Fai clic sul nome di un gruppo di istanze. Viene visualizzata la pagina Panoramica del gruppo di istanze.
4. Fai clic sulla scheda Dettagli.
5. Scorri fino alla sezione Networking:
6. Verifica che la Rete principale qui sia la stessa del valore authorizedNetwork. Ad esempio: default.
7. Fai clic sulla scheda Panoramica.
8. Nella sezione Membri del gruppo di istanze, fai clic sul nome di un'istanza. Viene visualizzata la pagina Dettagli.
9. Scorri fino alla sezione Interfacce di rete:
10. Verifica che il valore di Network sia uguale al valore di authorizedNetwork. Ad esempio: default.
11. Vai alla scheda Panoramica e ripeti i passaggi da h a j per ogni istanza nella sezione Membri del gruppo di istanze.

Risoluzione

Se nel passaggio 2 o nel passaggio 3, il valore di authorizedNetwork non corrisponde alla rete in peering con servicenetworking, assicurati di aver eseguito il peering della rete VPC corretta con servicenetworking seguendo i passaggi descritti nel passaggio 4: configura il networking di servizi.
Se nei passaggi 4f e 4j i valori di rete non corrispondono al valore di authorizedNetwork, verifica che authorizedNetwork sia la rete in peering con servicenetworking. . Se il peering è corretto e la rete non corrisponde ancora a authorizedNetwork,, significa che il gruppo di istanze è stato creato in modo errato e devi contattare l'assistenza clienti Google Cloud.

Causa: ambiente scollegato nella nuova istanza Apigee creata nell'ambito dell'espansione della regione

Diagnosi

Visualizzi un errore 503 sul lato client. Ad esempio:
```
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:questo errore 503 non viene visualizzato nella traccia di debug perché le richieste non raggiungono mai il processore di messaggi di runtime.
Se visualizzi errori 503 nella seconda regione subito dopo un' espansione della regione:
1. Assicurati che gli ambienti siano collegati alla nuova istanza eseguendo la seguente chiamata API:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  Ad esempio:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  Viene restituito un risultato simile al seguente:
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  In questo esempio, l'istanza denominata apigee-proxy-example è collegata a due ambienti: dev e prod.
2. Assicurati che il gruppo di istanze gestite (MIG) per la seconda regione sia stato creato e venga visualizzato come integro:
  1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.
    
    Vai a Bilanciamento del carico
  2. Fai clic sul nome del bilanciatore del carico. Viene visualizzata la pagina Dettagli del bilanciatore del carico.
  3. In Backend, dovresti vedere due MIG: uno per la regione 1 e uno per la regione 2. Verifica che entrambi siano integri:
  4. Convalida il secondo MIG seguendo i passaggi descritti in Le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee.

Risoluzione

Se la nuova istanza non è collegata all'ambiente, collegala seguendo le istruzioni riportate in Collegare gli ambienti alla nuova istanza.

Un'altra opzione è assicurarsi che il bilanciatore del carico indirizzi la richiesta al backend corretto a cui è già collegato l'ambiente. Ad esempio, di un ambiente non di produzione. Potresti voler collegare questo certificato a una sola regione, ma il bilanciatore del carico potrebbe indirizzare la richiesta alla regione sbagliata. Devi aggiornare la configurazione del bilanciatore del carico per assicurarti che il routing venga eseguito verso la regione corretta.
Se un MIG non è integro, consulta Diagnosi e Risoluzione in Le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e poi contatta l'assistenza clienti Google Cloud:

Organizzazione Apigee
Ambiente e proxy API in cui si verifica il problema
Sessione di debug scaricata (se il problema è intermittente)
Output dettagliato di curl di una richiesta non riuscita.
Bilanciatore del carico configurato per inviare chiamate API ad Apigee

Problemi di routing dell'accesso con Apigee Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Sintomo

Messaggio di errore

Cause possibili

Causa: errori TLS nel bilanciatore del carico HTTPS

Diagnosi

Risoluzione

Causa: Cloud Armor blocca le richieste

Diagnosi

Risoluzione

Causa: le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee

Diagnosi

Risoluzione

Causa: configurazione di rete errata

Diagnosi

Risoluzione

Causa: ambiente scollegato nella nuova istanza Apigee creata nell'ambito dell'espansione della regione

Diagnosi

Risoluzione

Deve raccogliere informazioni diagnostiche

Problemi di routing dell'accesso con Apigee