En esta página, se describe cómo solucionar problemas de conexión de salida para instancias de Looker (Google Cloud Core) que usan una configuración de IP privada con Private Service Connect.
Si tienes una falla con tu conexión de Private Service Connect de salida, usa el siguiente árbol de decisiones para comenzar a solucionar el problema.
Para obtener más información, consulta la documentación de acceso de salida de Looker (Google Cloud Core) a servicios externos con Private Service Connect.
Soluciona problemas de errores de conexión
Incluso si el estado de la conexión de Private Service Connect es Accepted, es posible que aún encuentres errores de conexión cuando Looker (Google Cloud Core) intente comunicarse con tu servicio.
Problemas de resolución de nombres de host
Si recibes un error "Unknown host" en la IU de Looker (Google Cloud Core) cuando pruebas una conexión de base de datos o cuando Looker (Google Cloud Core) intenta conectarse a tu servicio, esto puede indicar que falló la resolución de DNS para el nombre de host que configuraste para la conexión de Private Service Connect de salida.
En este caso, sigue los siguientes pasos para solucionar el problema:
- Verifica que el nombre de host configurado en Looker (Google Cloud Core) para el servicio sea correcto y que coincida con el nombre de host para el que debería existir un registro DNS.
- Verifica que tu balanceador de cargas y el servicio de backend estén en buen estado.
- Prueba la conectividad desde una VM dentro de tu VPC de productor para asegurarte de que se pueda acceder al servicio de backend a través de la regla de reenvío del balanceador de cargas. Puedes crear una VM temporal en la misma VPC y región que tu balanceador de cargas y usar una herramienta como
curlotelnetpara probar la conectividad a la dirección IP y el puerto del servicio.
Si persisten los problemas de resolución de nombres de host, comunícate con Atención al cliente de Cloud para obtener ayuda.
Tiempos de espera de conexión
Si se agota el tiempo de espera de las conexiones de Looker (Google Cloud Core) a tu servicio, esto puede deberse a las reglas de firewall de tu VPC de productor que bloquean el tráfico de la subred NAT de Private Service Connect o a otros problemas de red.
- Revisa tus reglas de firewall para asegurarte de que se permita el tráfico de entrada desde la subred NAT de Private Service Connect a los backends del balanceador de cargas.
- Usa los registros de flujo de la nube privada virtual y el registro del balanceador de cargas (como el registro del balanceador de cargas de aplicaciones interno o el registro del balanceador de cargas de red de transferencia interno) para ayudar a diagnosticar problemas de conexión. Los registros de flujo de la nube privada virtual pueden ayudarte a determinar si el tráfico de la subred NAT llega a tu balanceador de cargas, y los registros del balanceador de cargas pueden proporcionar detalles sobre si el tráfico se reenvía correctamente a los backends en buen estado.
Verifica la configuración de Private Service Connect de salida
Para verificar que la conexión entre la instancia de Looker (Google Cloud Core) y tu red se establezca correctamente, sigue estos pasos:
Verifica el estado del extremo de Private Service Connect de la instancia de Looker (Google Cloud Core)
Para verificar el estado de la conexión del adjunto de servicio de salida desde la configuración de la instancia de Looker (Google Cloud Core), haz lo siguiente:
- En la Google Cloud consola de, ve a la página Looker.
- Haz clic en el nombre de la instancia para la que deseas verificar la conexión.
- En la sección Herramientas de redes, en Adjunto de servicio, busca el extremo que estás solucionando.
- Comprueba que el Estado sea
Accepted.
Si el estado es Pending, es posible que se deba a una de las siguientes razones:
- La preferencia de conexión del adjunto de servicio no está establecida en "Aceptar automáticamente todas las conexiones" y la conexión no se aprobó de forma manual.
- El proyecto de la instancia de Looker (Google Cloud Core) no está en la lista de entidades permitidas del adjunto de servicio.
Para resolver un estado Pending, verifica la configuración del adjunto de servicio y asegúrate de que la preferencia de conexión esté establecida en Automatically accept all connections o que el proyecto de Looker (Google Cloud Core) se haya permitido de forma explícita.
Si el dominio o el URI del adjunto son incorrectos, vuelve a ejecutar el comando gcloud looker instances update con los valores correctos. Este comando reemplaza todos los adjuntos existentes, por lo que se deben incluir todos los adjuntos seleccionados. Consulta Edita la configuración de la instancia de Looker (Google Cloud Core) para obtener más información.
Verifica la configuración del adjunto de servicio del productor
También debes verificar la configuración del adjunto de servicio en tu proyecto de productor para asegurarte de que esté configurado correctamente para recibir conexiones de Looker (Google Cloud Core).
En la Google Cloud consola de, ve a Servicios de red > Private Service Connect y haz clic en la pestaña Servicios publicados. Haz clic en el adjunto de servicio que se usa para la conexión para ver sus detalles.
Verifica que se cumplan los siguientes requisitos:
- El adjunto de servicio está configurado con una regla de reenvío de destino válida y una subred NAT de Private Service Connect dedicada.
- La Preferencia de conexión está establecida en
Accept automatically. Si la preferencia de conexión esAccept for selected networksoAccept for selected projects, asegúrate de que se haya aprobado la conexión del proyecto de Looker (Google Cloud Core). - El servicio de destino apunta a la regla de reenvío correcta.
- La subred NAT está configurada correctamente y tiene suficiente espacio de IP.
- El URI del adjunto de servicio proporcionado a la instancia de Looker (Google Cloud Core) es correcto.
Puedes actualizar la configuración del adjunto de servicio con la Google Cloud consola de o ejecutando el gcloud compute service-attachments update comando.
Verifica las reglas de firewall
El tráfico de Looker (Google Cloud Core) ingresa a tu VPC a través de la subred NAT de Private Service Connect. Debes tener reglas de firewall que permitan que este tráfico llegue a los backends del balanceador de cargas.
Para verificar tus reglas de firewall, haz lo siguiente:
- Identifica el rango de IP de la subred NAT de Private Service Connect que está configurada en tu adjunto de servicio.
- En la Google Cloud consola de, ve a la página Firewall en tu VPC de productor.
- Verifica que haya una regla de firewall de entrada que permita el tráfico de TCP desde la subred NAT de Private Service Connect a los backends del balanceador de cargas en el puerto que usa tu servicio. La regla debe cumplir con los siguientes criterios:
- Filtro de origen: Los rangos de IP de origen incluyen el rango de subred NAT de Private Service Connect.
- Destinos: La regla se aplica a los backends del balanceador de cargas interno (por ejemplo, a través de etiquetas de red).
- Protocolos y puertos: La regla permite el tráfico de TCP en el puerto del servicio de destino.
Si no existe esa regla o si una regla de mayor prioridad deniega este tráfico, crea una regla de firewall de entrada para permitir el tráfico desde la subred NAT de Private Service Connect.
Verifica la configuración del balanceador de cargas y del grupo de extremos de red
Tu servicio se expone a Looker (Google Cloud Core) a través de un balanceador de cargas interno y un grupo de extremos de red (NEG) que apunta a tu servicio. Verifica que estos componentes estén en buen estado y configurados correctamente.
Para verificar la configuración de NEG, haz lo siguiente:
- En la Google Cloud consola de, ve a Servicios de red > Balanceo de cargas.
- Haz clic en tu balanceador de cargas y, luego, en el servicio de backend para ver sus detalles.
- En los detalles del servicio de backend, haz clic en el nombre del grupo de extremos de red.
- Verifica el Tipo de grupo de extremos de red:
- Para los servicios locales o de múltiples nubes a los que se puede acceder a través de Cloud VPN o Cloud Interconnect, el tipo debe ser NEG de conectividad híbrida (
NON_GCP_PRIVATE_IP_PORT). - Para los servicios públicos de Internet, como los proveedores de Git, el tipo debe ser un NEG de Internet (
INTERNET_FQDN_PORT).
- Para los servicios locales o de múltiples nubes a los que se puede acceder a través de Cloud VPN o Cloud Interconnect, el tipo debe ser NEG de conectividad híbrida (
- En la sección Extremos de red, verifica que la dirección IP y el puerto (para los NEG híbridos) o el FQDN y el puerto (para los NEG de Internet) coincidan correctamente con tu servicio de destino.
Si el NEG está mal configurado, es posible que debas actualizarlo o crear uno nuevo.
Verifica la resolución de DNS y el enrutamiento
Si no puedes conectarte desde Looker (Google Cloud Core), pero otros pasos para solucionar problemas no muestran problemas, prueba la conectividad desde la VPC de productor para aislar el problema:
- Crea una VM temporal de Compute Engine en la misma VPC y subred de productor que tu balanceador de cargas interno.
- Desde esa VM, usa herramientas como
telnetoncpara probar la conectividad a la dirección IP de la regla de reenvío del balanceador de cargas en el puerto de tu servicio, por ejemplo:telnet LOAD_BALANCER_IP TARGET_PORT.
Si puedes conectarte correctamente desde la VM, es probable que el problema esté en la ruta de Looker (Google Cloud Core) a tu VPC. Vuelve a verificar la configuración del adjunto de servicio y de la instancia de Looker (Google Cloud Core).
Si no puedes conectarte desde la VM, es probable que el problema esté en tu VPC de productor. Verifica la regla de reenvío del balanceador de cargas, el estado del servicio de backend y las reglas de firewall dentro de tu VPC.
Investiga problemas específicos de conexión de servicio
Ciertos servicios de destino tienen requisitos o dependencias únicos cuando se conectan a través de Private Service Connect.
Snowflake: Extremos de almacenamiento secundario
El controlador JDBC de Snowflake suele descargar conjuntos de resultados o metadatos desde una ubicación de almacenamiento en la nube intermedia (como Amazon S3 o Azure Blob Storage), en lugar de hacerlo desde el host de la base de datos principal. Si Looker (Google Cloud Core) no puede acceder a estos extremos secundarios, es posible que fallen las conexiones o las consultas, en especial para conjuntos de resultados grandes.
Para solucionar este problema, haz lo siguiente:
- Verifica los registros de Looker (Google Cloud Core) en busca de errores de tiempo de espera que hagan referencia a dominios de almacenamiento externos, como
s3.amazonaws.comoblob.core.windows.net. - Identifica el FQDN exacto del extremo de almacenamiento que requiere tu instancia de Snowflake. Puedes encontrar esta información en tus registros de Snowflake o comunicándote con el equipo de asistencia de Snowflake.
- Cada FQDN externo debe configurarse como una conexión de salida independiente. Crea una nueva configuración de Private Service Connect (NEG de Internet, balanceador de cargas y adjunto de servicio) para el FQDN del extremo de almacenamiento.
- Agrega el nuevo adjunto de servicio a la configuración de la instancia de Looker (Google Cloud Core).
Proveedores públicos de Git: Salida a Internet
Las instancias de Looker (Google Cloud Core) con una configuración de IP privada no tienen una ruta predeterminada a la Internet pública. Para conectarte a proveedores públicos de Git, como GitHub o GitLab, debes configurar de forma explícita una ruta de salida.
Para solucionar este problema, haz lo siguiente:
- Verifica si intentas conectarte a un proveedor público de Git desde una instancia de IP privada. Las fallas de conexión suelen manifestarse como tiempos de espera genéricos o errores de protocolo de enlace SSL.
- Crea una conexión de Private Service Connect de salida con un NEG de Internet.
- Asegúrate de que el NEG de Internet esté configurado para el puerto correcto (por ejemplo, el puerto 22 para SSH o el puerto 443 para HTTPS).
- Si tienes una política de anulación de DNS en tu VPC que crea un bucle de enrutamiento con un NEG de Internet basado en FQDN, considera usar un NEG de Internet basado en IP (
INTERNET_IP_PORT).
Centro de acciones y Marketplace
El Marketplace y el Centro de acciones predeterminados alojados en Google de Looker (Google Cloud Core) son servicios públicos de Internet y no se puede acceder a ellos desde instancias de IP privada de forma predeterminada.
- Centro de acciones: Para usar el Centro de acciones con una instancia de IP privada, debes implementar un servidor del Centro de acciones privado y autoalojado, y conectarte a él con una conexión de Private Service Connect de salida.
- Marketplace: Para conectarte a Looker Marketplace, puedes habilitar la conexión a Marketplace en la configuración de conexiones de salida de tu instancia. Cuando está habilitado, Looker (Google Cloud Core) usa un
Secure Web Proxy para conectarse directamente a la
Marketplace y
github.com. Para obtener más información, consulta Conéctate a Looker Marketplace. Si no habilitas esta conexión, debes descargar de forma manual las extensiones o los bloques de sus repositorios de Git y, luego, instalarlos como proyectos locales.
Verifica los registros
Los registros de flujo de la nube privada virtual y el registro del balanceador de cargas (como el registro del balanceador de cargas de aplicaciones interno o el registro del balanceador de cargas de red de transferencia interno) pueden proporcionar más información sobre los problemas de conectividad.
Habilita los registros de flujo de la nube privada virtual en las subredes que usa el balanceador de cargas y habilita el registro en el servicio de backend de tu balanceador de cargas interno. Luego, intenta conectarte desde Looker (Google Cloud Core) para reproducir el error.
En Cloud Logging, consulta los registros de flujo de la nube privada virtual y filtra el tráfico del rango de IP de la subred NAT de Private Service Connect a la dirección IP del balanceador de cargas. Si el tráfico llega al balanceador de cargas, consulta los registros del balanceo de cargas para obtener información sobre el estado de la conexión al backend.