Questa pagina è stata tradotta dall'API Cloud Translation.

Problemi di routing degli accessi con Apigee

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

Sintomo

In alcuni casi, i client esterni non sono in grado di accedere/connettersi ad Apigee nel modo desiderato. Sono inclusi errori di connettività di rete (handshake TLS non riuscito) o risposte 4xx/5xx da 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 a Google Cloud Armor configurazione. Le regole di negazione possono restituire un valore `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 forward 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 sia in peering la rete corretta con il VPC di 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.

Utilizzo della 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 da per visualizzare il certificato TLS.

Con un comando gcloud:

Elenca i bilanciatori del carico con quanto segue gcloud. Questo comando mostra anche SSL_CERTIFICATES associati a ogni bilanciatore del carico.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Sostituisci PROJECT_NAME con il nome del tuo 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 le seguenti informazioni gcloud (questo presuppone che tu abbia

jq

o uno strumento simile installato sul tuo computer):

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 queste controlli.

Per verificare il certificato TLS restituito dal bilanciatore del carico, esegui seguendo il comando openssl dal tuo computer 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 (Amministratore > 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 di md5 corrispondono), procedi raccogliendo un packet capture lato client per esaminare il fallimento dell'handshake TLS. Puoi acquisire il pacchetto sul lato client con strumenti quali Wireshark tcpdump o qualsiasi altro strumento i nostri strumenti.
Abilita i log sul bilanciatore del carico seguendo le istruzioni riportate in Abilitazione del logging su un servizio di backend esistente.
Esamina il bilanciatore del carico log per individuare eventuali 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 in passaggio 1 e il certificato nel passaggio 2 non corrispondono, allora potrebbe significare che il bilanciatore del carico gestisce un è scaduto/non corretto e dovresti inviare un ticket all'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. Per Ad esempio, puoi controllare la configurazione della rete sul lato client o verificare che l'applicazione client disponga di connettività con Apigee.
- Se noti un errore o un ripristino dal bilanciatore del carico stesso, consulta Risolvi i problemi generali di connettività e invia un ticket a Assistenza clienti Google Cloud, se necessario.
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, vedi Devi raccogliere dati diagnostici.

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, rivedi la configurazione di Google Cloud Armor per le regole che potrebbero bloccare 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 su un servizio di backend esistente.
Una volta abilitato il logging, esegui una query sui log per trovare le richieste bloccata 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 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 HTTP 502 errori con i seguenti errori le VM del proxy del router del traffico dell'API Apigee potrebbe essere in uno stato non integro.

502 errori come i seguenti potrebbero essere ricevuti dal clienti:
```
<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 che inoltrano il traffico l'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 a Bilanciamento del carico .
  
  Vai al bilanciamento del carico
2. Fai clic sul Nome del bilanciatore del carico. I dettagli del bilanciatore del carico si apre una pagina.
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 alla Indirizzo IP dell'istanza Apigee.

Le VM apigee-proxy vengono create utilizzando un'istanza modello. Il modello definisce l'indirizzo IP di ENDPOINT per e 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'UI di Apigee, fai clic su Amministratore > Istanze.
  2. Nella colonna Indirizzi IP sono elencati gli indirizzi 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 dell'ENDPOINT corrisponda ad Apigee Indirizzo IP restituito nel passaggio 2. Se non c'è corrispondenza, vai a Risoluzione.

Risoluzione

Se le VM apigee-proxy nel gruppo di istanze mostrano un'istanza non integro, quindi assicurati di avere impostato una regola firewall che consente agli intervalli di indirizzi IP del bilanciamento del carico 130.211.0.0/22 e 35.191.0.0/16 accedono 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 in Porta 443 TCP:

Se il gruppo di istanze gestite ha un tag diverso da gke-apigee-proxy, assicurati che il tag venga aggiunto alla sezione target-tag nel una 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 in Modifica degli IP delle istanze.

Causa: configurazione di rete errata

Diagnosi

Individua il valore per authorizedNetwork eseguendo il comando persone che seguo: 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 authorizedNetwork corrisponda al valore rete connessa in peering con servicenetworking:
1. Nella console Google Cloud del progetto host, vai alla Peering di rete VPC.
  
  Vai al peering di rete VPC
2. Il valore elencato per servicenetworking-googleapis-com in La rete VPC deve essere uguale al valore restituito da la chiamata API. Ad esempio: default.
Se utilizzi un VPC condiviso, assicurati che Il valore authorizedNetwork contiene il valore del VPC effettivo in il progetto host connesso in peering con servicenetworking.
1. Nella console Google Cloud, vai alla pagina VPC condivisa.
  
  Vai al VPC condiviso
2. Seleziona il progetto host.
3. Il valore elencato per servicenetworking-googleapis-com in La 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 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. Nel backend viene visualizzato un elenco di gruppi di istanze area:
3. Fai clic sul nome di un gruppo di istanze. Il gruppo di istanze Panoramica .
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 di Google Cloud.

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

Diagnosi

Viene visualizzato 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 poiché le richieste non raggiungono mai il Message Processor 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 i seguenti comandi 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 è collegato 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. La Si apre la pagina Dettagli 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, collega la risorsa all'ambiente seguendo le istruzioni in Collega gli ambienti alla nuova istanza.

Un'altra opzione è assicurarsi che il bilanciatore del carico inoltri la richiesta il backend corretto a cui l'ambiente è già collegato. Ad esempio, di in un ambiente non di produzione. Ti consigliamo di collegarlo a una sola regione, tuttavia, il bilanciatore del carico potrebbe instradare la richiesta alla regione errata. Ti servirebbero per aggiornare la configurazione del bilanciatore del carico e assicurarti che venga instradata regione.
Se un gruppo di istanze gestite non è integro, consulta 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 riporta le seguenti informazioni diagnostiche e 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 curl dettagliato di una richiesta non riuscita.
Bilanciatore del carico configurato per inviare chiamate API ad Apigee