[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eThis page guides users through troubleshooting 500 errors and other issues when configuring the IAP On-premises Connector, offering step-by-step instructions to diagnose and resolve problems.\u003c/p\u003e\n"],["\u003cp\u003eConnectivity issues between the on-premises application, the Google Cloud network, and Envoy can be debugged by pinging the application from connector VMs, checking load balancer health, and verifying Envoy processes.\u003c/p\u003e\n"],["\u003cp\u003eImproper Envoy installation can be identified by checking logs, ensuring gce-mesh bucket access, and verifying VPC Service Controls rules allow connections, also check the VPC for routing rules that allows traffic to the public internet.\u003c/p\u003e\n"],["\u003cp\u003eTo resolve issues where Envoy cannot connect to the application, check Envoy error logs, confirm Traffic Director is configuring Envoy correctly, and verify that \u003ccode\u003eTRAFFICDIRECTOR_INTERCEPTION_LISTENER\u003c/code\u003e is set.\u003c/p\u003e\n"],["\u003cp\u003eDeployment failures related to \u003ccode\u003eIamMemberBinding\u003c/code\u003e resources can be resolved by ensuring that the \u003ccode\u003eGoogle APIs Service Agent\u003c/code\u003e Service Account has been granted the \u003ccode\u003eOWNER\u003c/code\u003e role, as required when enabling IAP for on-premises applications.\u003c/p\u003e\n"]]],[],null,["# Troubleshooting your on-premises connector setup\n\nThis page provides step by step instructions to help you troubleshoot your IAP On-premises Connector configuration. For additional troubleshooting information, see [Traffic Director debugging](https://cloud.google.com/traffic-director/docs/troubleshooting).\n\nTroubleshooting error 500 issues\n--------------------------------\n\nFollowing are various issues and possible solutions to help you resolve a 500 error that you receive when attempting to access your application.\n\n**The on-premises application is not connected to the Google Cloud network**\n\nYour on-premises application might not be connected to the Google Cloud network. Verify connectivity by pinging the on-premises application from one of the on-premises connector Compute Engine instances. If the on-premises connector endpoint is unreachable, debug the network connectivity and settings before continuing.\n\n\u003cbr /\u003e\n\n\n**Envoy is not properly installed in the VMs**\n\nComplete the following steps to verify that Envoy is properly installed:\n\n1. Log on to one of the Compute Engine VMs from the on-premises connector. The on-premises connector VM name starts with `opc-on-prem-app-deployment-ig-${app}`.\n2. In the Cloud console, verify that the `opc-on-prem-app-deployment-gclb-urlmap` load balancing backend service health checks are green.\n3. If the backend service does not show up as healthy, SSH into one of the instances: \n\n ```\n gcloud compute ssh instance-name --zone=\u003cvar translate=\"no\"\u003ezone name\u003c/var\u003e\n ```\n4. Verify that Envoy is up and running, by issuing the following command:\n\n ```\n ps aux | grep envoy\n ```\n There should be more than one process running, other than the `grep envoy`.\n\n \u003cbr /\u003e\n\n An example output: \n\n envoy 943 0.0 0.0 5488 3076 ? Ss 06:25 0:00 /bin/bash /usr/local/bin/run-proxy.sh\n envoy 944 0.1 1.5 178928 57352 ? Sl 06:25 1:23 /usr/local/bin/envoy --config-path /usr/local/etc/\n envoy/envoy-proxy-bootstrap.json --allow-unknown-static-fields --disable-hot-restart --log-level info --drain-time-\n s 60\n\n5. Verify that the Envoy log directory is created at `/var/log/envoy/`.\n\n6. Ensure the gce-mesh bucket is reachable by the VMs, by issuing the following command:\n\n ```\n gcloud storage cp gs://gce-mesh/service-proxy-agent/releases/service-proxy-agent-0.2.tgz .\n ```\n\n \u003cbr /\u003e\n\nIf any of the validations in this step failed, Envoy is not properly installed. Review the startup logs at `/var/log/daemon.log` for more information.\n\nIf you've observed that the Envoy isn't running from the earlier steps, one of the reasons could be VPC Service Controls. The start-up script in the VMs download the Envoy image from the `gce-mesh` bucket. If the VPC Service Controls rules don't allow the connection, the on-premises connector deployment will not work.\n\nTo ensure Envoy installs correctly, allow access to the `gce-mesh` storage bucket in VPC Service Controls in the host project. Also, ensure the VPC has a routing rule to allow traffic to the public internet. This allows Envoy to be deployed. For more information, see [Ingress and egress rules](https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules).\n\n**Your on-premises application is not connected to Envoy**\n\nIf you can ping the on-premises application from the VM but cannot use the on-premises connector, it's possible that Envoy cannot connect to the application.\n\nTo verify that Envoy can connect to your on-premises application, try making a call to Envoy from the machine where Envoy is running. SSH into the VM `opc-on-prem-app-deployment-ig-${app}` and run the following command. You can find the Envoy port number in **Instance Groups \\\u003e Details \\\u003e Port Name Mapping**. \n\n```\nshell curl -x -v localhost:${envoy_port}\n```\n\n\u003cbr /\u003e\n\nIf the endpoint is not reachable, check the following:\n\n- `/var/log/envoy/envoy.err.log` for any error logs. If there are no error logs, check if Traffic Director is enabled and is able to configure Envoy, by running the following command: \n\n ```\n sudo curl 0.0.0.0:15000/config_dump \n ```\n- Verify that `TRAFFICDIRECTOR_INTERCEPTION_LISTENER` is set. If `TRAFFICDIRECTOR_INTERCEPTION_LISTENER` is not set, the Traffic Director could not configure Envoy.\n- Check for any error messages in each listener.\n\n**The Envoy and Traffic Director account permissions aren't set**\n\nIf you see the `GRPC 403` error in the `envoy.err.log` or if you do not see `TRAFFICDIRECTOR_INTERCEPTION_LISTENER` in the Envoy configuration, you might not have the correct account permissions set.\n\nVerify that the VM service account has `TD` access permissions for `xDS v3`:\n\n- Verify the permissions: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#grant\n- Verify the account: https://cloud.google.com/traffic-director/docs/prepare-for-envoy-setup#enable-service\n\nTroubleshooting `ERR_SSL_VERSION_OR_CIPHER_MISMATCH` errors\n-----------------------------------------------------------\n\nIf the browser shows the error `ERR_SSL_VERSION_OR_CIPHER_MISMATCH` without redirecting to the login page, verify the status of the certificates on the Google Cloud load balancer details page.\n\nNote that provisioning a Google-managed certificate might take up to 60 minutes.\n\nTroubleshooting Envoy installation issue\n----------------------------------------\n\nIf the on-premises connector is deployed successfully and the certificate has been provisioned, but the connection is still failing, this might indicate that Envoy might not be installed correctly on the VMs.\n\nTo verify if that Envoy is installed, SSH to one of the VMs and run the following command:\n\n-\n\n ```\n ps aux | grep envoy \n ```\n There should be more than one process running, other than the `grep envoy`.\n-\n\n ```\n netstat -tlpn \n ```\n The Envoy admin port 127.0.0.1:15000 should be listening.\n\nIf any of the previous actions fail, take the following actions to mitigate the issue:\n\n1. Make sure [Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) is enabled on the subnet the connector is being deployed.\n2. Make sure [VM Manager (OS Config API)](https://console.cloud.google.com/marketplace/product/google/osconfig.googleapis.com) is enabled.\n\nTroubleshooting Deployment Failure on IamMemberBinding Resources\n----------------------------------------------------------------\n\nIf the on-premises connector is being deployed or updated and encounters a `PERMISSION_DENIED` error related to `IamMemberBinding` resources, it may be because the `Google APIs Service Agent` Service Account has not been granted the `OWNER` role as required when [enabling IAP for on-premises apps](https://cloud.google.com/iap/docs/enabling-on-prem-howto).\n\nExample Deployment Errors: \n\n 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/\u003cproject-ID\u003e:setIamPolicy\",\"httpMethod\":\"POST\"}}\n\n 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/\u003cproject-ID\u003e:setIamPolicy\",\"httpMethod\":\"POST\"}}\n\nIf you are seeing these errors with the deployment, verify the `Google APIs Service Agent` Service Account is granted the `OWNER` role and retry."]]
