Risoluzione dei problemi di configurazione del connettore on-premise

Questa pagina fornisce istruzioni dettagliate per 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 le 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 rete Google Cloud. Verifica la connettività eseguendo un ping dell'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 e in esecuzione, utilizzando 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 di log di Envoy sia creata in /var/log/envoy/.

  6. Assicurati che il bucket gce-mesh sia raggiungibile dalle VM, emettendo 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 Controlli di servizio VPC. Lo script di avvio nelle VM scarica l'immagine Envoy dal bucket gce-mesh. Se le regole dei 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 maggiori informazioni, consulta la sezione Regole in entrata e in 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 sia in grado di 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 questo 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 degli errori, verifica che Traffic Director sia abilitato e sia in grado di configurare Envoy eseguendo questo 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 Envoy, è possibile che tu non abbia impostato le autorizzazioni dell'account corrette.

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 deployment del connettore on-premise è stato eseguito correttamente ed è stato eseguito il provisioning del certificato, ma la connessione continua a non riuscire, è possibile che Envoy non sia stato installato correttamente sulle VM.

Per verificare se Envoy è installato, accedi tramite SSH a una delle VM ed esegui questo 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 nessuna delle azioni precedenti risolve il problema, esegui le seguenti azioni per attenuarlo:

  1. Assicurati che l'accesso privato Google sia abilitato nella subnet di cui si sta eseguendo il deployment.
  2. Assicurati che VM Manager (API OS Config) sia abilitato.

Risoluzione dei problemi di mancato deployment delle 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 attivi 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 visualizzi questi errori con il deployment, verifica che all'account di servizio Google APIs Service Agent sia stato concesso il ruolo OWNER e riprova.