Problemi di routing degli accessi con Apigee

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
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, vedi TLS errore di handshake o risposta 4xx/5xx anche se l'API potrebbe sembrare integro nella UI di Apigee.

Cause possibili

Causa Descrizione Codici di errore
Errori TLS nel bilanciatore del carico HTTPS Sei tu a gestire 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 esserci una regola di blocco 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 inoltrare il traffico all'istanza Apigee La configurazione del proxy del router per il traffico dell'API Apigee e la relativa integrità che richiedono un'indagine 502 Server Error
Configurazione di rete errata Assicurati che sia in peering la rete corretta con il VPC di Apigee. 502 Server error
Gli ambienti non collegati nuova istanza Apigee creata nell'ambito dell'espansione della regione Dopo aver creato una nuova istanza, ad esempio una seconda regione, devi gli ambienti, altrimenti non potrà rispondere alle richieste API. 503 error response

Causa: errori TLS nel bilanciatore del carico HTTPS

Diagnosi

  1. Trova il certificato TLS associato al bilanciatore del carico.
    1. Uso della console Google Cloud:
      1. Nella console Google Cloud, vai a Bilanciamento del carico .

        Vai al bilanciamento del carico

      2. Fai clic sul Nome del bilanciatore del carico. Il bilanciatore del carico dei dettagli.

      3. Nell'area Frontend, nella colonna IP:Porta, assicurati che 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.
    2. Con un comando gcloud:
      1. 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: 
      2. 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 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 corrisponde al Nome host configurato in Apigee > Amministratore > Ambienti > Gruppi. Assicurati che il certificato sia valido e non scaduto. Puoi utilizzare openssl per eseguire queste controlli.

  2. Per verificare il certificato TLS restituito dal bilanciatore del carico, esegui seguendo il comando openssl dal tuo computer client. Controlla se questo certificato corrisponde a quello restituito in passaggio 1 qui sopra.
    openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts

    Sostituisci quanto segue:

    • LB_HOSTNAME_OR_IP: nome host o 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 questo comando del tuo cliente:

    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).

    Poi verifica che md5 corrisponda eseguendo questo comando 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

  3. Se il passaggio 1 e il passaggio 2 i certificati corrispondono (ad es. se i valori di md5 corrispondono), procedi alla raccolta di packet capture sul lato client per esamina l'errore di TLS handshake. Puoi acquisire il pacchetto sul lato client con strumenti quali Wireshark, tcpdump o qualsiasi altro strumento i nostri strumenti.
  4. Abilita i log sul bilanciatore del carico seguendo le istruzioni in Abilitazione del logging su un servizio di backend esistente.
  5. Esamina il bilanciatore del carico log per individuare eventuali errori.

Risoluzione

  1. Se il certificato autogestito sul bilanciatore del carico è scaduto o è stato valori CN/SAN errati, potresti dover il certificato sul bilanciatore del carico.
  2. 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.
  3. Se tcpdump indica un errore di TLS handshake, indaga se l'errore di connessione proviene dal bilanciatore del carico o lato client.
    • Se l'errore o la reimpostazione della connessione avviene dal lato client, controlla l'applicazione client per capire il motivo del malfunzionamento. 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.
  4. 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 un errore 403, 404 o 502 risposta basata su Cloud Armor la configurazione del bilanciatore del carico e del gruppo di istanze gestite per verificare che siano configurate correttamente e siano in stato integro.

  1. 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.
  2. Se non sai con certezza quale regola stia negando il traffico, puoi provare a: abilitare il logging nel bilanciatore del carico, come descritto in Abilitazione del logging su un servizio di backend esistente.
  3. 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 il codice seguente 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 in Riquadro Risultati query:

Risoluzione

Modifica le regole/la configurazione di Google Cloud Armor per allinearle alle tue esigenze risolvere il problema. 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

  1. 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 ricevi messaggi di questo tipo, controlla l'integrità della parte delle VM apigee-proxy dell'istanza eseguire i seguenti 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 tutto il bilanciatore del carico hanno un segno di spunta verde nella colonna Stato integro.

  2. 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 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. Oppure, ottieni l'indirizzo IP dell'istanza Apigee utilizzando Interfaccia utente di Apigee:

      1. Nell'UI di Apigee, fai clic su Amministratore &gt; 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. Il bilanciatore del carico dei dettagli.
      3. Nell'area Backend, fai clic sul nome di un servizio di backend.
      4. Nell'area Membri del gruppo di istanze, fai clic su un Modello .

      5. Nella pagina del modello, scorri fino a Metadati personalizzati, dove vedrai l'indirizzo IP di ENDPOINT:

    Assicurati che l'indirizzo IP dell'ENDPOINT corrisponda ad Apigee Indirizzo IP restituito nel passaggio 2. In caso contrario corrispondenza, vai a Risoluzione.

Risoluzione

  1. 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.
  2. Nella console Google Cloud, vai alla pagina Firewall.

    Vai a Firewall

  3. 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.

  4. Se l'indirizzo IP di ENDPOINT non corrisponde all'IP dell'istanza Apigee di destinazione, è possibile che l'istanza sia stata eliminata e ricreata, l'indirizzo IP non corrisponde più all'indirizzo IP della 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

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

  2. 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.
  3. 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 condiviso.

      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.
  4. Verifica che il gruppo di istanze associato al bilanciatore del carico sia 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. Pagina Dettagli bilanciatore del carico si apre. 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 indicata corrisponda a quella della rete authorizedNetwork valore. Ad esempio: default.
    7. Fai clic sulla scheda Panoramica.
    8. Nella sezione Membri del gruppo di istanze, fai clic sul nome di un in esecuzione in un'istanza Compute Engine. Viene visualizzata la pagina Dettagli.
    9. Scorri fino alla sezione Interfacce di rete:

    10. Verifica che il valore Network sia uguale a authorizedNetwork valore. Ad esempio: default.
    11. Vai alla scheda Panoramica e ripeti il passaggio h tramite il passaggio j per ogni istanza nella sezione Membri del gruppo di istanze.

Risoluzione

  1. Se nel passaggio 2 o nel passaggio 3, la Il valore authorizedNetwork non è uguale alla rete, ha eseguito il peering con servicenetworking, quindi verifica di avere ha eseguito il peering della rete VPC corretta con servicenetworking tramite seguendo i passaggi Passaggio 4: configura il networking di servizi.
  2. Se ai passaggi 4f e 4j la rete non corrispondono al valore authorizedNetwork, verifica che authorizedNetwork sia la rete in peering con servicenetworking. Se è connesso in peering correttamente e la rete non è ancora uguale a authorizedNetwork,, significa il gruppo di istanze è stato creato in modo errato. Contatta Assistenza clienti Google Cloud.

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

Diagnosi

  1. 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
    
  2. Se visualizzi immediatamente 503 errore nella seconda regione dopo un di 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 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 è collegato a due ambienti: dev e prod.

    2. Assicurati che il gruppo di istanze gestite per la seconda regione abbia e viene visualizzato in stato 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 MIG: 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 in Le VM proxy Apigee non sono in grado il traffico all'istanza Apigee.

Risoluzione

  1. 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.

  2. Se un gruppo di istanze gestite non è integro, consulta la diagnosi e Risoluzione in Le VM proxy Apigee non sono in grado di inoltrare il traffico all'istanza Apigee.

Raccogliere dati diagnostici

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 che rilevano 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