Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Problemi di routing dell'accesso con Apigee

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Sintomo

In alcuni casi, i client esterni non riescono ad accedere/connettersi ad Apigee nel modo desiderato. Questi includono errori di connettività di rete (errore di handshake TLS) 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	È possibile gestire la configurazione TLS del bilanciatore di 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 esserci 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` (Gateway non valido) 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 di traffico API di Apigee e il suo stato di salute.	`502 Server Error`
Configurazione di rete errata	Assicurati che la rete corretta sia in peering con il VPC di 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 collegarvi gli ambienti, altrimenti non può rispondere alle richieste API.	`503 error response`

Causa: errori TLS nel bilanciatore di carico HTTPS

Diagnosi

Trova il certificato TLS associato al bilanciatore del carico.

Utilizzo della Google Cloud console:
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 (questo 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

Sostituire 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 verificare il certificato TLS restituito dal bilanciatore di carico, eseguire 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 di carico. Ad esempio, my-load-balancer.
- LB_HOSTNAME: il nome host del bilanciatore di 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
```
SostituireHOST_NAME con il nome host configurato in Apigee (Amministratore> Ambienti> Gruppi ).

E poi 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
```
Sostituire 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. È possibile acquisire i pacchetti sul lato client con strumenti come Wireshark, tcpdump o qualsiasi altro strumento affidabile.
Abilita i log sul bilanciatore del carico seguendo le istruzioni in Abilitazione della registrazione 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 presenta 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 inviare 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 bilanciamento del carico stesso, consulta Risolvere i problemi di connettività generali e, se necessario, apri un ticket con l'assistenza clienti Google Cloud.
Se riscontri errori nei log del bilanciatore di carico, consulta Errori 5XX non spiegati e, se necessario, apri un ticket con 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 , controlla la configurazione di Google Cloud Armor per individuare eventuali regole che potrebbero bloccare la richiesta. Le politiche di sicurezza sono reperibili in Configura le politiche di sicurezza di Google Cloud Armor.
Se non sei sicuro di quale regola stia bloccando il traffico, potresti provare ad abilitare la registrazione sul bilanciatore di carico come descritto in Abilitazione della registrazione su un servizio backend esistente.
Una volta abilitata la registrazione, esegui una query sui log per trovare le 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.

502 I client potrebbero ricevere errori 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 bilanciatore di carico Nome. 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 la UI di Apigee:
  1. Nella UI di 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:
Assicurarsi che l'indirizzo IP dell'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
Assicurarsi che esista una regola firewall in ingresso contarget-tag Piacegke-apigee-proxy e intervalli IP di origine come130.211.0.0/22 E35.191.0.0/16 oltre il443 TCP porta:

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 per 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 per authorizedNetwork è quello predefinito.

Verificare che il valore authorizedNetwork sia lo stesso della rete che è collegata tramite 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 stai utilizzando una VPC condiviso, assicurati che il valore authorizedNetwork abbia il valore della VPC effettiva nel progetto host che è in peering con servicenetworking.
1. Nella console Google Cloud , vai alla pagina VPC condiviso.
  
  Vai a VPC condiviso
2. Selezionare il progetto host.
3. Il valore indicato per servicenetworking-googleapis-com nella rete VPC dovrebbe essere lo stesso del valore authorizedNetwork restituito dalla chiamata API. Ad esempio: default.
Verificare che il gruppo di istanze associato al bilanciatore di carico sia la 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 di carico. Si apre la pagina Dettagli del bilanciatore di carico. Un elenco di gruppi di istanze viene visualizzato nell'area Backend:
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. Verificare che la rete Primary network 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 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 authorizedNetwork non è uguale 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

Sul lato client viene visualizzato un errore 503. 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. Sotto Backend, dovresti vedere due MIG; uno per la regione 1 e uno per la regione 2. Verificate che entrambi siano in buona salute:
  4. Convalidare il secondo MIG seguendo i passaggi descritti in Le VM proxy di Apigee non sono in grado di inoltrare il traffico all'istanza di Apigee.

Risoluzione

Se la nuova istanza non è collegata all'ambiente, collegala seguendo le istruzioni riportate in Collega 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 instradare la richiesta alla regione sbagliata. È necessario aggiornare la configurazione del bilanciatore di carico per assicurarsi che instradi il traffico 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 di 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