Conectividad de depuración
Ha configurado la conectividad entre sus bases de datos de origen y de destino, pero ¿cómo sabe que están conectadas? Cuando fallan las comunicaciones entre ellos, ¿cómo puedes saber qué salió mal y dónde?
Las herramientas más básicas son ping y traceroute .
Silbido
Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera a cambio una ICMP Echo Reply . Si ping no tiene éxito, entonces no hay ruta desde el origen al destino. Sin embargo, el éxito no significa que sus paquetes puedan pasar, sólo que, en general, se puede alcanzar el host remoto.
Si bien ping puede indicar si un host está activo y respondiendo, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.
ruta de seguimiento
Traceroute prueba la ruta completa que toman los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que realiza el paquete a lo largo del camino y cuánto tiempo lleva cada paso. Si el paquete no llega hasta el destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busque la última dirección IP a la que se llegó con éxito en el camino. Aquí es donde se rompió la conectividad.
Traceroute puede expirar. También puede no completarse si una puerta de enlace en el camino no está configurada correctamente para pasar el paquete al siguiente salto.
Cuando traceroute no se completa, es posible que puedas averiguar dónde se detuvo. Encuentre la última dirección IP que aparece en la salida traceroute y realice una búsqueda en el navegador para saber who owns [IP_ADDRESS] . Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.
metro
La herramienta mtr es una forma de traceroute que permanece activa y actualizada continuamente, de forma similar a cómo funciona el comando top para procesos locales.
Localice su dirección IP local
Si no conoce la dirección local de su host, ejecute el comando ip -br address show . En Linux, esto muestra la interfaz de red, el estado de la interfaz, las direcciones IP y MAC locales. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64 .
Alternativamente, puede ejecutar ipconfig o ifconfig para ver el estado de sus interfaces de red.
Localice la dirección IP saliente
Si no conoce la dirección IP que utilizan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), complete los siguientes pasos:
Vaya a la página Instancias SQL en el Google Cloud console.
Haga clic en el nombre de la instancia asociada con el trabajo de migración que está depurando.
Desplácese hacia abajo hasta que aparezca el panel Conectarse a esta instancia . En este panel, aparece la dirección IP saliente.
Abrir puertos locales
Para verificar que su host esté escuchando en los puertos que cree, ejecute el comando ss -tunlp4 . Esto le indica qué puertos están abiertos y escuchando. Por ejemplo, si tiene una base de datos PostgreSQL en ejecución, entonces el puerto 5432 debería estar activo y escuchando. Para SSH, debería ver el puerto 22.
Toda la actividad portuaria local
Utilice el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos actualmente activos.
Conéctese al host remoto usando telnet
Para verificar que puede conectarse al host remoto mediante TCP , ejecute el comando telnet . Telnet intenta conectarse a la dirección IP y al puerto que usted le proporciona.
telnet 35.193.198.159 5432 .Si tiene éxito, verá lo siguiente: Intentando 35.193.198.159...
Conectado al 35.193.198.159. .
En caso de error, verá que telnet deja de responder hasta que fuerce el cierre del intento: Intentando 35.193.198.159...
^C. .
Autenticación de cliente
La autenticación del cliente está controlada por un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en host).
Asegúrese de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen esté actualizada para aceptar conexiones del rango de direcciones IP de Cloud SQL VPC.
Registro en la nube
El servicio de migración de bases de datos y Cloud SQL utilizan Cloud Logging. Consulta la documentación de Cloud Logging para obtener información completa y revisa las consultas de muestra de Cloud SQL .Ver registros
Puedes ver registros de instancias de Cloud SQL y otros Google Cloudproyectos como Cloud VPN o instancias de Compute Engine. Para ver registros de las entradas de registro de tu instancia de Cloud SQL:Consola
- Vaya al Explorador de registros
- Selecciona un proyecto de Cloud SQL existente en la parte superior de la página.
- En el generador de consultas, agregue lo siguiente:
- Recurso: seleccione Base de datos Cloud SQL . En el cuadro de diálogo, seleccione una instancia de Cloud SQL.
- Nombres de registro: desplácese hasta la sección Cloud SQL y seleccione los archivos de registro apropiados para su instancia. Por ejemplo:
- cloudsql.googleapis.com/postgres.log
- Gravedad: seleccione un nivel de registro.
- Rango de tiempo: seleccione un ajuste preestablecido o cree un rango personalizado.
nube de gcloud
Usa el comando gcloud logging para ver las entradas del registro. En el siguiente ejemplo, reemplace PROJECT_ID . El indicador limit es un parámetro opcional que indica el número máximo de entradas a devolver.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Direcciones IP privadas
Las conexiones a una instancia de Cloud SQL que utilizan una dirección IP privada se autorizan automáticamente para los rangos de direcciones RFC 1918 . Los rangos de direcciones que no son RFC 1918 se deben configurar en Cloud SQL como redes autorizadas . También debe actualizar el emparejamiento de red con Cloud SQL para exportar cualquier ruta que no sea RFC 1918. Por ejemplo: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
El rango de IP 172.17.0.0/16 está reservado para la red del puente Docker. Cualquier instancia de Cloud SQL creada con una dirección IP en ese rango será inaccesible. Las conexiones desde cualquier dirección IP dentro de ese rango a instancias de Cloud SQL que utilicen una dirección IP privada fallarán.
Solución de problemas de VPN
Ver elGoogle Cloud Página de solución de problemas de Cloud VPN .
Solución de problemas del túnel SSH inverso
El túnel SSH es un método para reenviar alguna comunicación sobre una conexión SSH. El túnel SSH inverso permite configurar un túnel SSH, pero manteniendo que la red de destino sea la que inicie la conexión del túnel. Esto es útil cuando no desea abrir un puerto en su propia red por motivos de seguridad.
Lo que está tratando de lograr es configurar lo siguiente: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Se supone que:
El Compute Engine VM bastion puede acceder a la Cloud SQL DB .
El source network bastion puede acceder a la source DB (esto se logra emparejando la red de Cloud SQL con la red de VM de Compute Engine).
Luego, configura un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion , que enruta cualquier conexión entrante a algún puerto en el Compute Engine VM bastion a través del túnel hasta la source DB .
Cada enlace en el escenario anterior se puede configurar incorrectamente e impedir que funcione todo el flujo. Solucione los problemas de cada enlace, uno por uno:
source network bastion ---> source DB
- Conéctese al source network bastion mediante SSH, o desde la terminal si es la máquina local.
- Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet [source_db_host_or_ip] [source_db_port]- espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que haya habilitado el acceso desde este bastión a la base de datos de origen.
Compute Engine VM bastion ---> source DB
- SSH al Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet 127.0.0.1 [tunnel_port]: espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que el túnel esté funcionando correctamente. La ejecución sudo netstat -tupln muestra todos los procesos de escucha en esta máquina virtual y debería ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Esto se prueba mejor testing the migration job desde el Servicio de migración de bases de datos. Si esto falla, significa que hay algún problema con el emparejamiento o el enrutamiento de VPC entre la red Cloud SQL y la red Compute Engine VM bastion .
El firewall del servidor de la base de datos de origen debe configurarse para permitir todo el rango de IP interno asignado para la conexión de servicio privado de la red VPC que la instancia de destino de Cloud SQL va a utilizar como el campo privateNetwork de sus ajustes de ipConfiguration .
Para encontrar el rango de IP interno en la consola:
Vaya a la página de redes VPC en el Google Cloud consola.
Seleccione la red VPC que desea utilizar.
Seleccione la pestaña CONEXIÓN DE SERVICIO PRIVADO .
También puedes ver el tráfico entre la instancia de Cloud SQL y la instancia de VM de Compute Engine en la consola de Cloud Logging en el proyecto Cloud VPN gateway . En los registros de VM de Compute Engine, busque el tráfico proveniente de la instancia de Cloud SQL. En los registros de la instancia de Cloud SQL, busque el tráfico de la VM de Compute Engine.
Conectividad de depuración
Ha configurado la conectividad entre sus bases de datos de origen y de destino, pero ¿cómo sabe que están conectadas? Cuando fallan las comunicaciones entre ellos, ¿cómo puedes saber qué salió mal y dónde?
Las herramientas más básicas son ping y traceroute .
Silbido
Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera a cambio una ICMP Echo Reply . Si ping no tiene éxito, entonces no hay ruta desde el origen al destino. Sin embargo, el éxito no significa que sus paquetes puedan pasar, sólo que, en general, se puede alcanzar el host remoto.
Si bien ping puede indicar si un host está activo y respondiendo, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.
ruta de seguimiento
Traceroute prueba la ruta completa que toman los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que realiza el paquete a lo largo del camino y cuánto tiempo lleva cada paso. Si el paquete no llega hasta el destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busque la última dirección IP a la que se llegó con éxito en el camino. Aquí es donde se rompió la conectividad.
Traceroute puede expirar. También puede no completarse si una puerta de enlace en el camino no está configurada correctamente para pasar el paquete al siguiente salto.
Cuando traceroute no se completa, es posible que puedas averiguar dónde se detuvo. Encuentre la última dirección IP que aparece en la salida traceroute y realice una búsqueda en el navegador para saber who owns [IP_ADDRESS] . Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.
metro
La herramienta mtr es una forma de traceroute que permanece activa y actualizada continuamente, de forma similar a cómo funciona el comando top para procesos locales.
Localice su dirección IP local
Si no conoce la dirección local de su host, ejecute el comando ip -br address show . En Linux, esto muestra la interfaz de red, el estado de la interfaz, las direcciones IP y MAC locales. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64 .
Alternativamente, puede ejecutar ipconfig o ifconfig para ver el estado de sus interfaces de red.
Localice la dirección IP saliente
Si no conoce la dirección IP que utilizan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), complete los siguientes pasos:
Vaya a la página Instancias SQL en el Google Cloud console.
Haga clic en el nombre de la instancia asociada con el trabajo de migración que está depurando.
Desplácese hacia abajo hasta que aparezca el panel Conectarse a esta instancia . En este panel, aparece la dirección IP saliente.
Abrir puertos locales
Para verificar que su host esté escuchando en los puertos que cree, ejecute el comando ss -tunlp4 . Esto le indica qué puertos están abiertos y escuchando. Por ejemplo, si tiene una base de datos PostgreSQL en ejecución, entonces el puerto 5432 debería estar activo y escuchando. Para SSH, debería ver el puerto 22.
Toda la actividad portuaria local
Utilice el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos activos actualmente.
Conéctese al host remoto usando telnet
Para verificar que puede conectarse al host remoto mediante TCP , ejecute el comando telnet . Telnet intenta conectarse a la dirección IP y al puerto que usted le proporciona.
telnet 35.193.198.159 5432 .Si tiene éxito, verá lo siguiente: Intentando 35.193.198.159...
Conectado al 35.193.198.159. .
En caso de error, verá que telnet deja de responder hasta que fuerce el cierre del intento: Intentando 35.193.198.159...
^C. .
Autenticación de cliente
La autenticación del cliente está controlada por un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en host).
Asegúrese de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen esté actualizada para aceptar conexiones del rango de direcciones IP de Cloud SQL VPC.
Registro en la nube
El servicio de migración de bases de datos y Cloud SQL utilizan Cloud Logging. Consulta la documentación de Cloud Logging para obtener información completa y revisa las consultas de muestra de Cloud SQL .Ver registros
Puedes ver registros de instancias de Cloud SQL y otros Google Cloudproyectos como Cloud VPN o instancias de Compute Engine. Para ver registros de las entradas de registro de tu instancia de Cloud SQL:Consola
- Vaya al Explorador de registros
- Selecciona un proyecto de Cloud SQL existente en la parte superior de la página.
- En el generador de consultas, agregue lo siguiente:
- Recurso: seleccione Base de datos Cloud SQL . En el cuadro de diálogo, seleccione una instancia de Cloud SQL.
- Nombres de registro: desplácese hasta la sección Cloud SQL y seleccione los archivos de registro apropiados para su instancia. Por ejemplo:
- cloudsql.googleapis.com/postgres.log
- Gravedad: seleccione un nivel de registro.
- Rango de tiempo: seleccione un ajuste preestablecido o cree un rango personalizado.
nube de gcloud
Usa el comando gcloud logging para ver las entradas del registro. En el siguiente ejemplo, reemplace PROJECT_ID . El indicador limit es un parámetro opcional que indica el número máximo de entradas a devolver.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Direcciones IP privadas
Las conexiones a una instancia de Cloud SQL que utilizan una dirección IP privada se autorizan automáticamente para los rangos de direcciones RFC 1918 . Los rangos de direcciones que no son RFC 1918 se deben configurar en Cloud SQL como redes autorizadas . También debe actualizar el emparejamiento de red con Cloud SQL para exportar cualquier ruta que no sea RFC 1918. Por ejemplo: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
El rango de IP 172.17.0.0/16 está reservado para la red del puente Docker. Cualquier instancia de Cloud SQL creada con una dirección IP en ese rango será inaccesible. Las conexiones desde cualquier dirección IP dentro de ese rango a instancias de Cloud SQL que utilicen una dirección IP privada fallarán.
Solución de problemas de VPN
Ver elGoogle Cloud Página de solución de problemas de Cloud VPN .
Solución de problemas del túnel SSH inverso
El túnel SSH es un método para reenviar alguna comunicación sobre una conexión SSH. El túnel SSH inverso permite configurar un túnel SSH, pero manteniendo que la red de destino es la que inicia la conexión del túnel. Esto es útil cuando no desea abrir un puerto en su propia red por motivos de seguridad.
Lo que está tratando de lograr es configurar lo siguiente: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Se supone que:
El Compute Engine VM bastion puede acceder a la Cloud SQL DB .
El source network bastion puede acceder a la source DB (esto se logra emparejando la red de Cloud SQL con la red de VM de Compute Engine).
Luego, configura un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion , que enruta cualquier conexión entrante a algún puerto en el Compute Engine VM bastion a través del túnel hasta la source DB .
Cada enlace en el escenario anterior se puede configurar incorrectamente e impedir que funcione todo el flujo. Solucione los problemas de cada enlace, uno por uno:
source network bastion ---> source DB
- Conéctese al source network bastion mediante SSH, o desde la terminal si es la máquina local.
- Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet [source_db_host_or_ip] [source_db_port]- espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que haya habilitado el acceso desde este bastión a la base de datos de origen.
Compute Engine VM bastion ---> source DB
- SSH al Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet 127.0.0.1 [tunnel_port]: espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que el túnel esté funcionando correctamente. La ejecución sudo netstat -tupln muestra todos los procesos de escucha en esta máquina virtual y debería ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Esto se prueba mejor testing the migration job desde el Servicio de migración de bases de datos. Si esto falla, significa que hay algún problema con el emparejamiento o el enrutamiento de VPC entre la red Cloud SQL y la red Compute Engine VM bastion .
El firewall del servidor de la base de datos de origen debe configurarse para permitir todo el rango de IP interno asignado para la conexión de servicio privado de la red VPC que la instancia de destino de Cloud SQL va a utilizar como el campo privateNetwork de sus ajustes de ipConfiguration .
Para encontrar el rango de IP interno en la consola:
Vaya a la página de redes VPC en el Google Cloud consola.
Seleccione la red VPC que desea utilizar.
Seleccione la pestaña CONEXIÓN DE SERVICIO PRIVADO .
También puedes ver el tráfico entre la instancia de Cloud SQL y la instancia de VM de Compute Engine en la consola de Cloud Logging en el proyecto Cloud VPN gateway . En los registros de VM de Compute Engine, busque el tráfico proveniente de la instancia de Cloud SQL. En los registros de la instancia de Cloud SQL, busque el tráfico de la VM de Compute Engine.
Conectividad de depuración
Ha configurado la conectividad entre sus bases de datos de origen y de destino, pero ¿cómo sabe que están conectadas? Cuando fallan las comunicaciones entre ellos, ¿cómo puedes saber qué salió mal y dónde?
Las herramientas más básicas son ping y traceroute .
Silbido
Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera a cambio una ICMP Echo Reply . Si ping no tiene éxito, entonces no hay ruta desde el origen al destino. Sin embargo, el éxito no significa que sus paquetes puedan pasar, sólo que, en general, se puede alcanzar el host remoto.
Si bien ping puede indicar si un host está activo y respondiendo, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.
ruta de seguimiento
Traceroute prueba la ruta completa que toman los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que realiza el paquete a lo largo del camino y cuánto tiempo lleva cada paso. Si el paquete no llega hasta el destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busque la última dirección IP a la que se llegó con éxito en el camino. Aquí es donde se rompió la conectividad.
Traceroute puede expirar. También puede no completarse si una puerta de enlace en el camino no está configurada correctamente para pasar el paquete al siguiente salto.
Cuando traceroute no se completa, es posible que puedas averiguar dónde se detuvo. Encuentre la última dirección IP que aparece en la salida traceroute y realice una búsqueda en el navegador para saber who owns [IP_ADDRESS] . Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.
metro
La herramienta mtr es una forma de traceroute que permanece activa y actualizada continuamente, de forma similar a cómo funciona el comando top para procesos locales.
Localice su dirección IP local
Si no conoce la dirección local de su host, ejecute el comando ip -br address show . En Linux, esto muestra la interfaz de red, el estado de la interfaz, las direcciones IP y MAC locales. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64 .
Alternativamente, puede ejecutar ipconfig o ifconfig para ver el estado de sus interfaces de red.
Localice la dirección IP saliente
Si no conoce la dirección IP que utilizan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), complete los siguientes pasos:
Vaya a la página Instancias SQL en el Google Cloud console.
Haga clic en el nombre de la instancia asociada con el trabajo de migración que está depurando.
Desplácese hacia abajo hasta que aparezca el panel Conectarse a esta instancia . En este panel, aparece la dirección IP saliente.
Abrir puertos locales
Para verificar que su host esté escuchando en los puertos que cree, ejecute el comando ss -tunlp4 . Esto le indica qué puertos están abiertos y escuchando. Por ejemplo, si tiene una base de datos PostgreSQL en ejecución, entonces el puerto 5432 debería estar activo y escuchando. Para SSH, debería ver el puerto 22.
Toda la actividad portuaria local
Utilice el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos actualmente activos.
Conéctese al host remoto usando telnet
Para verificar que puede conectarse al host remoto mediante TCP , ejecute el comando telnet . Telnet intenta conectarse a la dirección IP y al puerto que usted le proporciona.
telnet 35.193.198.159 5432 .Si tiene éxito, verá lo siguiente: Intentando 35.193.198.159...
Conectado al 35.193.198.159. .
En caso de error, verá que telnet deja de responder hasta que fuerce el cierre del intento: Intentando 35.193.198.159...
^C. .
Autenticación de cliente
La autenticación del cliente está controlada por un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en host).
Asegúrese de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen esté actualizada para aceptar conexiones del rango de direcciones IP de Cloud SQL VPC.
Registro en la nube
El servicio de migración de bases de datos y Cloud SQL utilizan Cloud Logging. Consulta la documentación de Cloud Logging para obtener información completa y revisa las consultas de muestra de Cloud SQL .Ver registros
Puedes ver registros de instancias de Cloud SQL y otros Google Cloudproyectos como Cloud VPN o instancias de Compute Engine. Para ver registros de las entradas de registro de tu instancia de Cloud SQL:Consola
- Vaya al Explorador de registros
- Selecciona un proyecto de Cloud SQL existente en la parte superior de la página.
- En el generador de consultas, agregue lo siguiente:
- Recurso: seleccione Base de datos Cloud SQL . En el cuadro de diálogo, seleccione una instancia de Cloud SQL.
- Nombres de registro: desplácese hasta la sección Cloud SQL y seleccione los archivos de registro apropiados para su instancia. Por ejemplo:
- cloudsql.googleapis.com/postgres.log
- Gravedad: seleccione un nivel de registro.
- Rango de tiempo: seleccione un ajuste preestablecido o cree un rango personalizado.
nube de gcloud
Usa el comando gcloud logging para ver las entradas del registro. En el siguiente ejemplo, reemplace PROJECT_ID . El indicador limit es un parámetro opcional que indica el número máximo de entradas a devolver.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Direcciones IP privadas
Las conexiones a una instancia de Cloud SQL que utilizan una dirección IP privada se autorizan automáticamente para los rangos de direcciones RFC 1918 . Los rangos de direcciones que no son RFC 1918 se deben configurar en Cloud SQL como redes autorizadas . También debe actualizar el emparejamiento de red con Cloud SQL para exportar cualquier ruta que no sea RFC 1918. Por ejemplo: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
El rango de IP 172.17.0.0/16 está reservado para la red del puente Docker. Cualquier instancia de Cloud SQL creada con una dirección IP en ese rango será inaccesible. Las conexiones desde cualquier dirección IP dentro de ese rango a instancias de Cloud SQL que utilicen una dirección IP privada fallarán.
Solución de problemas de VPN
Ver elGoogle Cloud Página de solución de problemas de Cloud VPN .
Solución de problemas del túnel SSH inverso
El túnel SSH es un método para reenviar alguna comunicación sobre una conexión SSH. El túnel SSH inverso permite configurar un túnel SSH, pero manteniendo que la red de destino es la que inicia la conexión del túnel. Esto es útil cuando no desea abrir un puerto en su propia red por motivos de seguridad.
Lo que está tratando de lograr es configurar lo siguiente: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Se supone que:
El Compute Engine VM bastion puede acceder a la Cloud SQL DB .
El source network bastion puede acceder a la source DB (esto se logra emparejando la red de Cloud SQL con la red de VM de Compute Engine).
Luego, configura un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion , que enruta cualquier conexión entrante a algún puerto en el Compute Engine VM bastion a través del túnel hasta la source DB .
Cada enlace en el escenario anterior se puede configurar incorrectamente e impedir que funcione todo el flujo. Solucione los problemas de cada enlace, uno por uno:
source network bastion ---> source DB
- Conéctese al source network bastion mediante SSH, o desde la terminal si es la máquina local.
- Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet [source_db_host_or_ip] [source_db_port]- espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que haya habilitado el acceso desde este bastión a la base de datos de origen.
Compute Engine VM bastion ---> source DB
- SSH al Compute Engine VM bastion (usando
gcloud compute ssh VM_INSTANCE_NAME) - Pruebe la conectividad con la base de datos de origen utilizando uno de los siguientes métodos:
-
telnet 127.0.0.1 [tunnel_port]: espere ver las cadenas de conexión de telnet, que terminan enConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]- espera ver acceso denegado
-
Si esto falla, entonces deberá verificar que el túnel esté funcionando correctamente. La ejecución sudo netstat -tupln muestra todos los procesos de escucha en esta máquina virtual y debería ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Esto se prueba mejor testing the migration job desde el Servicio de migración de bases de datos. Si esto falla, significa que hay algún problema con el emparejamiento o el enrutamiento de VPC entre la red Cloud SQL y la red Compute Engine VM bastion .
El firewall del servidor de la base de datos de origen debe configurarse para permitir todo el rango de IP interno asignado para la conexión de servicio privado de la red VPC que la instancia de destino de Cloud SQL va a utilizar como el campo privateNetwork de sus ajustes de ipConfiguration .
Para encontrar el rango de IP interno en la consola:
Vaya a la página de redes VPC en el Google Cloud consola.
Seleccione la red VPC que desea utilizar.
Seleccione la pestaña CONEXIÓN DE SERVICIO PRIVADO .
También puedes ver el tráfico entre la instancia de Cloud SQL y la instancia de VM de Compute Engine en la consola de Cloud Logging en el proyecto Cloud VPN gateway . En los registros de VM de Compute Engine, busque el tráfico proveniente de la instancia de Cloud SQL. En los registros de la instancia de Cloud SQL, busque el tráfico de la VM de Compute Engine.
Conectividad de depuración
Ha configurado la conectividad entre sus bases de datos de origen y de destino, pero ¿cómo sabe que están conectadas? Cuando fallan las comunicaciones entre ellos, ¿cómo puedes saber qué salió mal y dónde?
Las herramientas más básicas son ping y traceroute .
Silbido
Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera a cambio una ICMP Echo Reply . Si ping no tiene éxito, entonces no hay ruta desde el origen al destino. Sin embargo, el éxito no significa que sus paquetes puedan pasar, sólo que, en general, se puede alcanzar el host remoto.
Si bien ping puede indicar si un host está activo y respondiendo, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.
ruta de seguimiento
Traceroute prueba la ruta completa que toman los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que realiza el paquete a lo largo del camino y cuánto tiempo lleva cada paso. Si el paquete no llega hasta el destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busque la última dirección IP a la que se llegó con éxito en el camino. Aquí es donde se rompió la conectividad.
Traceroute puede expirar. También puede no completarse si una puerta de enlace en el camino no está configurada correctamente para pasar el paquete al siguiente salto.
Cuando traceroute no se completa, es posible que puedas averiguar dónde se detuvo. Encuentre la última dirección IP que aparece en la salida traceroute y realice una búsqueda en el navegador para saber who owns [IP_ADDRESS] . Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.
metro
La herramienta mtr es una forma de traceroute que permanece activa y actualizada continuamente, de forma similar a cómo funciona el comando top para procesos locales.
Localice su dirección IP local
Si no conoce la dirección local de su host, ejecute el comando ip -br address show . En Linux, esto muestra la interfaz de red, el estado de la interfaz, las direcciones IP y MAC locales. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64 .
Alternativamente, puede ejecutar ipconfig o ifconfig para ver el estado de sus interfaces de red.
Localice la dirección IP saliente
Si no conoce la dirección IP que utilizan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), complete los siguientes pasos:
Vaya a la página Instancias SQL en el Google Cloud console.
Haga clic en el nombre de la instancia asociada con el trabajo de migración que está depurando.
Desplácese hacia abajo hasta que aparezca el panel Conectarse a esta instancia . En este panel, aparece la dirección IP saliente.
Abrir puertos locales
Para verificar que su host esté escuchando en los puertos que cree, ejecute el comando ss -tunlp4 . Esto le indica qué puertos están abiertos y escuchando. Por ejemplo, si tiene una base de datos PostgreSQL en ejecución, entonces el puerto 5432 debería estar activo y escuchando. Para SSH, debería ver el puerto 22.
Toda la actividad portuaria local
Utilice el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos activos actualmente.
Conéctese al host remoto usando telnet
Para verificar que puede conectarse al host remoto mediante TCP , ejecute el comando telnet . Telnet intenta conectarse a la dirección IP y al puerto que usted le proporciona.
telnet 35.193.198.159 5432 .Si tiene éxito, verá lo siguiente: Intentando 35.193.198.159...
Conectado al 35.193.198.159. .
En caso de error, verá que telnet deja de responder hasta que fuerce el cierre del intento: Intentando 35.193.198.159...
^C. .
Autenticación de cliente
La autenticación del cliente está controlada por un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en host).
Asegúrese de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen esté actualizada para aceptar conexiones del rango de direcciones IP de Cloud SQL VPC.
Registro en la nube
El servicio de migración de la base de datos y la nube SQL utilizan el registro en la nube. Consulte la documentación de registro en la nube para obtener información completa y revise las consultas de muestra de Cloud SQL .Ver registros
Puede ver registros para instancias SQL en la nube y otras Google CloudProyectos como Cloud VPN o instancias de motor de cómputo. Para ver registros para sus entradas de registro de instancia SQL en la nube:Consola
- Ir al explorador de registros
- Seleccione un proyecto Cloud SQL existente en la parte superior de la página.
- En el constructor de consultas, agregue lo siguiente:
- Recurso: Seleccione la base de datos de Cloud SQL . En el cuadro de diálogo, seleccione una instancia de SQL en la nube.
- Nombres de registro: desplácese a la sección SQL de la nube y seleccione los archivos de registro apropiados para su instancia. Por ejemplo:
- Cloudsql.googleapis.com/postgres.log
- Severidad: seleccione un nivel de registro.
- Rango de tiempo: seleccione un preajuste o cree un rango personalizado.
nube de gcloud
Use el comando gcloud logging para ver las entradas de registro. En el ejemplo a continuación, reemplace PROJECT_ID . El indicador limit es un parámetro opcional que indica el número máximo de entradas para devolver.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Direcciones IP privadas
Las conexiones a una instancia de Cloud SQL utilizando una dirección IP privada se autorizan automáticamente para los rangos de direcciones RFC 1918 . Los rangos de direcciones no RFC 1918 deben configurarse en la nube SQL como redes autorizadas . También debe actualizar la red Peering a Cloud SQL para exportar cualquier ruta no RFC 1918. Por ejemplo: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
El rango IP 172.17.0.0/16 está reservado para la red Docker Bridge. Cualquier instancia SQL en la nube creada con una dirección IP en ese rango será inalcanzable. Las conexiones desde cualquier dirección IP dentro de ese rango a las instancias de SQL en la nube utilizando la dirección IP privada fallarán.
Solución de problemas de VPN
Ver elGoogle Cloud Página de solución de problemas de Cloud VPN .
Solución de problemas de problemas de túnel SSH inversa
El túnel SSH es un método para reenviar cierta comunicación sobre una conexión SSH. El túnel SSH inverso permite configurar un túnel SSH, pero mantener que la red de destino es la que inicia la conexión del túnel. Esto es útil cuando no desea abrir un puerto en su propia red para fines de seguridad.
Lo que está tratando de lograr es configurar lo siguiente: Cloud SQL DB ---> Compute Engine VM bastion ----> tunnel ---> source network bastion ---> source DB
Se supone que:
El Compute Engine VM bastion puede acceder a la Cloud SQL DB .
El source network bastion puede acceder al source DB (esto se logra mirando la red SQL de la nube a la red Compute Engine VM).
Luego configuró un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion , que enruta cualquier conexión entrante a algún puerto en el Compute Engine VM bastion a través del túnel a la source DB .
Cada enlace en el escenario anterior se puede configurar de manera incorrecta y evitar que todo el flujo funcione. Solucionar problemas de cada enlace, uno por uno:
source network bastion ---> source DB
- Conéctese al source network bastion usando SSH, o desde el terminal si es la máquina local.
- Pruebe la conectividad al DB de origen utilizando uno de los siguientes métodos:
-
telnet [source_db_host_or_ip] [source_db_port]: espere ver las cadenas de conexión de Telnet, terminando conConnected to xxxx. -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]-Espere ver el acceso denegado
-
Si esto falla, entonces debe verificar que habilitó el acceso desde este bastión al origen DB.
Compute Engine VM bastion ---> source DB
- SSH al Compute Engine VM bastion (Uso de
gcloud compute ssh VM_INSTANCE_NAME) - Pruebe la conectividad al DB de origen utilizando uno de los siguientes métodos:
-
telnet 127.0.0.1 [tunnel_port]- Espere ver las cadenas de conexión de Telnet, terminando conConnected to xxxx. -
[db_client] -h127.0.0.1 -P[tunnel_port]-Espere ver el acceso denegado
-
Si esto falla, entonces debe verificar que el túnel esté funcionando correctamente. La ejecución sudo netstat -tupln muestra todos los procesos de escucha en esta VM, y debería ver sshd listening on the tunnel_port .
Cloud SQL DB ---> source DB
Esto se prueba mejor testing the migration job desde el servicio de migración de bases de datos. Si esto falla, entonces significa que hay algún problema con la observación o el enrutamiento de VPC entre la red SQL Cloud y la red de Compute Engine VM bastion .
El firewall del servidor de la base de datos Source debe configurarse para permitir que todo el rango IP interno se asigne para la conexión de servicio privado de la red VPC que la instancia de destino de Cloud SQL utilizará como el campo PrivateNetwork de su configuración de Conconfiguración IPCONFIGURACIÓN .
Para encontrar el rango de IP interno en la consola:
Vaya a la página de redes VPC en el Google Cloud consola.
Seleccione la red VPC que desea utilizar.
Seleccione la pestaña CONEXIÓN DE SERVICIO PRIVADO .
También puede ver el tráfico entre la instancia de Cloud SQL y la instancia de VM de Compute Engine en la consola de registro de la nube en el proyecto Cloud VPN gateway . En los registros de VM de Compute Engine, busque el tráfico proveniente de la instancia de Cloud SQL. En los registros de la instancia de SQL de la nube, busque el tráfico de la VM del motor Compute.
A menos que se indique lo contrario, el contenido de esta página está sujeto a la licencia Reconocimiento 4.0 de Creative Commons y las muestras de código están sujetas a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio web de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-05-15 (UTC).