Risoluzione dei problemi di configurazione del connettore on-premise

Questa pagina fornisce istruzioni dettagliate per aiutarti a risolvere i problemi di configurazione del connettore on-premise IAP. Per ulteriori informazioni sulla risoluzione dei problemi, consulta Debug di Traffic Director.

Risolvere i problemi relativi all'errore 500

Di seguito sono riportati vari problemi e possibili soluzioni per aiutarti a risolvere un errore 500 che ricevi quando tenti di accedere alla tua applicazione.

L'applicazione on-premise non è connessa alla rete Google Cloud

L'applicazione on-premise potrebbe non essere connessa alla Google Cloud rete. Verifica la connettività eseguendo un ping all'applicazione on-premise da una delle istanze Compute Engine del connettore on-premise. Se l'endpoint del connettore on-premise non è raggiungibile, esegui il debug della connettività e delle impostazioni di rete prima di continuare.

Envoy non è installato correttamente nelle VM

Per verificare che Envoy sia installato correttamente:

  1. Accedi a una delle VM Compute Engine dal connettore on-premise. Il nome della VM del connettore on-premise inizia con opc-on-prem-app-deployment-ig-${app}.
  2. Nella console Cloud, verifica che i controlli di integrità del servizio di backend del bilanciamento del carico opc-on-prem-app-deployment-gclb-urlmap siano verdi.
  3. Se il servizio di backend non viene visualizzato come integro, accedi tramite SSH a una delle istanze: 
     gcloud compute ssh instance-name --zone=zone name

  4. Verifica che Envoy sia attivo ed eseguito eseguendo il seguente comando: 

     ps aux | grep envoy
    Dovrebbero essere in esecuzione più di un processo, a parte grep envoy.

    Un esempio di output:

    envoy      943  0.0  0.0   5488  3076 ?        Ss   06:25   0:00 /bin/bash /usr/local/bin/run-proxy.sh
envoy      944  0.1  1.5 178928 57352 ?        Sl   06:25   1:23 /usr/local/bin/envoy --config-path /usr/local/etc/
envoy/envoy-proxy-bootstrap.json --allow-unknown-static-fields --disable-hot-restart --log-level info --drain-time-
s 60

  5. Verifica che la directory dei log di Envoy sia stata creata in /var/log/envoy/.

  6. Assicurati che il bucket gce-mesh sia raggiungibile dalle VM eseguendo il seguente comando: 

    gcloud storage cp gs://gce-mesh/service-proxy-agent/releases/service-proxy-agent-0.2.tgz .

Se una delle convalide in questo passaggio non è riuscita, Envoy non è installato correttamente. Per ulteriori informazioni, esamina i log di avvio all'indirizzo /var/log/daemon.log.

Se hai notato che Envoy non è in esecuzione dai passaggi precedenti, uno dei motivi potrebbe essere i Controlli di servizio VPC. Lo script di avvio nelle VM scarica l'immagine Envoy dal bucket gce-mesh. Se le regole di Controlli di servizio VPC non consentono la connessione, il deployment del connettore on-premise non funzionerà.

Per assicurarti che Envoy venga installato correttamente, consenti l'accesso al bucket di archiviazione gce-mesh in Controlli di servizio VPC nel progetto host. Inoltre, assicurati che la VPC abbia una regola di routing per consentire il traffico verso internet pubblico. In questo modo è possibile eseguire il deployment di Envoy. Per ulteriori informazioni, vedi Regole di ingresso e uscita.

L'applicazione on-premise non è collegata a Envoy

Se riesci a eseguire un ping dell'applicazione on-premise dalla VM, ma non riesci a utilizzare il connettore on-premise, è possibile che Envoy non riesca a connettersi all'applicazione.

Per verificare che Envoy possa connettersi alla tua applicazione on-premise, prova a effettuare una chiamata a Envoy dalla macchina su cui è in esecuzione. Accedi tramite SSH alla VM opc-on-prem-app-deployment-ig-${app} ed esegui il seguente comando. Puoi trovare il numero di porta di Envoy in Gruppi di istanze > Dettagli > Mappatura dei nomi di porta. 

shell curl -x -v localhost:${envoy_port}

Se l'endpoint non è raggiungibile, controlla quanto segue:

  • /var/log/envoy/envoy.err.log per eventuali log degli errori. Se non sono presenti log di errore, controlla se Traffic Director è abilitato ed è in grado di configurare Envoy eseguendo il seguente comando: 
    sudo curl 0.0.0.0:15000/config_dump
  • Verifica che TRAFFICDIRECTOR_INTERCEPTION_LISTENER sia impostato. Se TRAFFICDIRECTOR_INTERCEPTION_LISTENER non è impostato, Traffic Director non ha potuto configurare Envoy.
  • Controlla se sono presenti messaggi di errore in ogni ascoltatore.

Le autorizzazioni dell'account Envoy e Traffic Director non sono impostate

Se viene visualizzato l'errore GRPC 403 in envoy.err.log o se non vedi TRAFFICDIRECTOR_INTERCEPTION_LISTENER nella configurazione di Envoy, è possibile che le autorizzazioni dell'account non siano impostate correttamente.

Verifica che l'account di servizio della VM abbia autorizzazioni di accesso TD per xDS v3:

  • Verifica le autorizzazioni: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#grant
  • Verifica l'account: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#enable-service

Risolvere i problemi relativi agli errori ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Se il browser mostra l'errore ERR_SSL_VERSION_OR_CIPHER_MISMATCH senza reindirizzare alla pagina di accesso, verifica lo stato dei certificati nella pagina dei dettagli del bilanciatore del carico. Google Cloud

Tieni presente che il provisioning di un certificato gestito da Google potrebbe richiedere fino a 60 minuti.

Risoluzione dei problemi di installazione di Envoy

Se il connettore on-premise è stato implementato correttamente e il certificato è stato eseguito, ma la connessione continua a non riuscire, è possibile che Envoy non sia installato correttamente sulle VM.

Per verificare se Envoy è installato, accedi tramite SSH a una delle VM ed esegui il seguente comando:

  •  ps aux | grep envoy
    Dovrebbero essere in esecuzione più di un processo, a parte grep envoy.
  •  netstat -tlpn
    La porta di amministrazione di Envoy 127.0.0.1:15000 deve essere in ascolto.

Se una delle azioni precedenti non risolve il problema, esegui le seguenti azioni per attenuarlo:

  1. Assicurati che l'accesso privato Google sia abilitato nella subnet in cui viene eseguito il deployment del connettore.
  2. Assicurati che VM Manager (API OS Config) sia abilitato.

Risoluzione dei problemi di mancato deployment nelle risorse IamMemberBinding

Se il connettore on-premise viene implementato o aggiornato e si verifica un errore PERMISSION_DENIED relativo alle risorse IamMemberBinding, è possibile che all'account di servizio Google APIs Service Agent non sia stato assegnato il ruolo OWNER come richiesto quando viene attivato l'IAP per le app on-premise.

Esempi di errori di deployment:

bind-iam-policy: {"ResourceType":"gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding","ResourceErrorCode":"403","ResourceErrorMessage":{"code":403,"message":"Policy update access denied.","status":"PERMISSION_DENIED","statusMessage":"Forbidden","requestPath":"https://cloudresourcemanager.googleapis.com/v1/projects/<project-ID>:setIamPolicy","httpMethod":"POST"}}

bind-storage-admin-account-iam-policy: {"ResourceType":"gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding","ResourceErrorCode":"403","ResourceErrorMessage":{"code":403,"message":"Policy update access denied.","status":"PERMISSION_DENIED","statusMessage":"Forbidden","requestPath":"https://cloudresourcemanager.googleapis.com/v1/projects/<project-ID>:setIamPolicy","httpMethod":"POST"}}

Se si verificano questi errori durante il deployment, verifica che all'account di servizio Google APIs Service Agent sia stato concesso il ruolo OWNER e riprova.