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 documentazione equivalente di Apigee Edge per questo argomento.

Sintomo

In alcuni casi, i client esterni non riescono ad accedere/connettersi ad Apigee nel modo desiderato. Sono inclusi errori di connettività di rete (errori di handshake TLS) o risposte 4xx/5xx di Apigee.

Messaggio di errore

Quando invii una richiesta API dal tuo client ad Apigee, viene visualizzato un errore di handshake TLS o una risposta 4xx/5xx anche se i proxy API potrebbero sembrare funzionanti nell'interfaccia utente 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, è possibile che una regola blocchi la richiesta.	Il codice di risposta dell'API può variare in base alla configurazione di Google Cloud Armor. Le regole di rifiuto 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 forwardare il traffico all'istanza Apigee	È necessario esaminare la configurazione del proxy del router del traffico API di Apigee e il relativo stato	`502 Server Error`
Configurazione di rete errata	Assicurati che la rete corretta sia in coppia con il VPC Apigee.	`502 Server error`
Ambienti non associati nella nuova istanza Apigee creata nell'ambito dell'espansione della regione	Dopo aver creato una nuova istanza, ad esempio una seconda regione, devi collegarvi gli ambienti, altrimenti non potrà 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 al 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:Port, assicurati di esaminare il bilanciatore del carico corretto verificandone l'indirizzo IP e la porta.
4. Nella colonna Certificato, fai clic sul nome del certificato per visualizzarlo.

Utilizzando un comando gcloud:

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

Viene restituito qualcosa di 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 (si presume 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 qualcosa di 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 > Amministrazione > Ambienti > Gruppi. Assicurati che il certificato sia valido e non sia 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 qui 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 la corrispondenza dei certificati, esegui il seguente 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).

Quindi verifica 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 raccogliendo un packet capture lato client per esaminare il fallimento dell'handshake TLS. Puoi eseguire l'acquisizione dei pacchetti 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 se nei log del bilanciatore del carico sono presenti errori.

Risoluzione

Se il certificato autogestito sul bilanciatore del carico è scaduto o presenta valori CN/SAN errati, potrebbe essere necessario sostituire il certificato sul bilanciatore del carico.
Se il certificato restituito dal bilanciatore del carico nel passaggio 1 e il certificato nel passaggio 2 non corrispondono, è possibile che il bilanciatore del carico stia pubblicando un certificato obsoleto/errato e devi aprire un ticket con l'assistenza clienti Google Cloud.
Se un tcpdump indica un errore di handshake TLS, esamina 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é si comporta in modo anomalo. Ad esempio, puoi controllare la configurazione di rete lato client o verificare che l'applicazione client abbia connettività con Apigee.
- Se visualizzi l'errore/il ripristino dal bilanciatore del carico stesso, consulta Risolvere i problemi di connettività generali e, se necessario, invia un ticket all'assistenza clienti Google Cloud.
Se noti 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 Devi raccogliere informazioni di diagnostica.

Causa: Cloud Armor blocca le richieste

Diagnosi

Se visualizzi una risposta di errore 403, 404 o 502 basata sulla configurazione di Cloud Armor, controlla la configurazione del bilanciatore del carico e del gruppo di istanze gestite per verificare che siano configurati correttamente e siano operativi.

Se utilizzi Google Cloud Armor nel tuo ambiente Google Cloud, controlla la configurazione di Google Cloud Armor per verificare la presenza di eventuali 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 con certezza quale regola nega il traffico, puoi provare a attivare la registrazione nel bilanciatore del carico come descritto in Attivare la registrazione in un servizio di backend esistente.
Una volta attivato il logging, esegui una query sui log per trovare eventuali richieste bloccate dai criteri 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 del criterio applicato viene visualizzato in jsonPayload.enforcedSecurityPolicy.name nel riquadro Risultati query:

Risoluzione

Per risolvere il problema, modifica le regole/la configurazione di Google Cloud Armor in base alle tue esigenze. 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 dell'API Apigee potrebbero non essere in uno stato corretto.

I client possono 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 verificare la presenza di 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 inoltra il traffico all'istanza Apigee. Se visualizzi messaggi come quelli riportati sopra, controlla lo stato 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 al 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 abbiano 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, ottieni l'indirizzo IP dell'istanza Apigee utilizzando la UI di Apigee:
  1. Nell'interfaccia utente di Apigee, fai clic su Amministrazione > Istanze.
  2. La colonna Indirizzi IP elenca l'indirizzo IP:
3. Ottieni l'indirizzo IP ENDPOINT dal modello:
  1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
    
    Vai al 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 modello.
  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 c'è corrispondenza, vai a Risoluzione.

Risoluzione

Se le VM apigee-proxy nel gruppo di istanze mostrano uno stato non corretto, assicurati di avere configurato una regola firewall che consenta agli intervalli di indirizzi IP per il bilanciamento del carico 130.211.0.0/22 e 35.191.0.0/16 di accedere al gruppo di istanze gestite.
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 gruppo 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ù all'indirizzo IP nel modello. Per aggiornare il modello in modo che utilizzi il nuovo indirizzo IP, segui le istruzioni riportate in Modificare gli 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 qualcosa di 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 authorizedNetwork corrisponda alla rete in coppia con servicenetworking:
1. Nella console Google Cloud del progetto host, vai alla pagina Peering di rete 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 authorizedNetwork corrisponda al valore del VPC effettivo nel progetto host associato a servicenetworking.
1. Nella console Google Cloud, vai alla pagina VPC condivisa.
  
  Vai a Rete VPC condivisa
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 all'API. Ad esempio: default.
Verifica che il gruppo di istanze associato al bilanciatore del carico sia sulla stessa rete del valore authorizedNetwork:
1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
  
  Vai al 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 uguale al 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 Rete sia uguale al valore authorizedNetwork. Ad esempio: default.
11. Vai alla scheda Panoramica e ripeti il passaggio h fino al passaggio j per ogni istanza nella sezione Membri del gruppo di istanze.

Risoluzione

Se nel passaggio 2 o nel passaggio 3 il valore authorizedNetwork non corrisponde alla rete con il 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 della rete non corrispondono al valore 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 non collegato nella nuova istanza Apigee creata nell'ambito dell'espansione della regione

Diagnosi

Visualizzi un errore 503 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 poiché 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 qualcosa di 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 sia visualizzato come integro:
  1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
    
    Vai al 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 gruppi di istanze gestite: uno per la regione 1 e uno per la regione 2. Verifica che entrambi siano integri:
  4. Convalida il secondo gruppo di istanze gestite seguendo i passaggi descritti in Le VM proxy Apigee non sono in grado di forward il traffico all'istanza Apigee.

Risoluzione

Se la nuova istanza non è collegata all'ambiente, collegala all'ambiente 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. Ti consigliamo di collegarlo a una sola regione. Tuttavia, il bilanciatore del carico potrebbe inoltrare la richiesta alla regione sbagliata. Dovrai aggiornare la configurazione del bilanciatore del carico per assicurarti che indirizzi alla regione corretta.
Se un gruppo di istanze gestite non è integro, consulta la sezione Diagnosi e Risoluzione in Le VM proxy Apigee non riescono a inoltrare il traffico all'istanza Apigee.

Deve raccogliere informazioni di diagnostica

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica 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