Depurar la conectividad

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Depura la conectividad

Ya configuraste la conectividad entre tus bases de datos de origen y destino, pero ¿cómo sabes que están conectadas? Cuando falla la comunicación entre ellos, ¿cómo puedes saber qué salió mal y dónde?

Las herramientas más básicas son ping y traceroute.

Ping

Ping realiza una prueba básica para determinar si el destino ("host remoto") está disponible en el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera un ICMP Echo Reply a cambio. Si ping no funciona, significa que no hay una ruta del origen al destino. Sin embargo, tener éxito no significa que tus paquetes puedan pasar, solo que, en general, se puede acceder al host remoto.

Si bien ping puede saber si un host está activo y responde, no se garantiza que sea confiable. Algunos proveedores de red bloquean ICMP como una precaución de seguridad, lo que puede dificultar la depuración de la conectividad.

Traceroute

Traceroute prueba la ruta completa que los paquetes de red toman de un host a otro. Muestra todos los pasos ("saltos") que el paquete realiza en el camino y cuánto tiempo lleva cada paso. Si el paquete no realiza el recorrido completo al destino, traceroute no se completa, pero termina con una serie de asteriscos. En este caso, busca la última dirección IP a la que se llegó con éxito durante el proceso. Aquí es donde se interrumpió la conectividad.

Traceroute puede agotar el tiempo de espera. 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, puedes saber dónde se detuvo. Busca la última dirección IP que aparece en el resultado traceroute y busca who owns [IP_ADDRESS] en el navegador. Los resultados pueden mostrar o no al propietario de la dirección, pero vale la pena intentarlo.

mtr

La herramienta mtr es una forma de traceroute que permanece activa y se actualiza continuamente, de forma similar a cómo funciona el comando top para los procesos locales.

Ubica tu dirección IP local

Si no conoces la dirección local del host, ejecuta el comando ip -br address show. En Linux, este muestra la interfaz de red, el estado de la interfaz, la IP local y las direcciones MAC. Por ejemplo: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64

Como alternativa, puedes ejecutar ipconfig o ifconfig para ver el estado de tus interfaces de red.

Ubica la dirección IP saliente

Si no conoces la dirección IP que usan las bases de datos de origen y destino para comunicarse entre sí (la dirección IP saliente), completa los siguientes pasos:

1. Ve a la página Clústeres de AlloyDB en Google Cloud console.

   Ir a la página Clústeres de AlloyDB

2. Ubica el clúster asociado con el trabajo de migración que estás depurando.

3. La IP saliente debería aparecer junto al nombre de la instancia principal del clúster.

Abre puertos locales

Para verificar que tu host esté escuchando en los puertos que crees que está, ejecuta el comando ss -tunlp4. Este te indica qué puertos están abiertos y escuchando. Por ejemplo, si tienes una base de datos PostgreSQL en ejecución, el puerto 5432 debe estar activo y escuchando. Para SSH, deberías ver el puerto 22.

Toda la actividad del puerto local

Usa el comando netstat para ver toda la actividad del puerto local. Por ejemplo, netstat -lt muestra todos los puertos activos en el momento.

Conéctate al host remoto con telnet

Para verificar que puedes conectarte al host remoto con TCP, ejecuta el comando telnet. Telnet intenta conectarse a la dirección IP y al puerto que le proporcionas.

Por ejemplo, si tu host remoto ejecuta una base de datos PostgreSQL, deberías poder ejecutar telnet en ella en el puerto 5432: telnet 35.193.198.159 5432.

Si el proceso se completa correctamente, verás lo siguiente:

Trying 35.193.198.159...

Connected to 35.193.198.159.

Si se produce un error, verás que telnet deja de responder hasta que fuerces el cierre del intento:

Trying 35.193.198.159...

^C.

Autenticación de clientes

La autenticación del cliente se controla mediante un archivo de configuración, que se denomina pg_hba.conf (HBA significa autenticación basada en host).

Asegúrate de que la sección de conexiones de replicación del archivo pg_hba.conf en la base de datos de origen se actualice para aceptar conexiones del rango de direcciones IP de la VPC de AlloyDB.

Cloud Logging

Database Migration Service y AlloyDB usan 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 los registros de las instancias de AlloyDB y otros proyectos de Google Cloud, como instancias de Cloud VPN o Compute Engine. Sigue estos pasos para ver los registros de las entradas de registro de tu instancia de AlloyDB:

Console

1. Ir al Explorador de registros.
2. Selecciona un proyecto existente de AlloyDB en la parte superior de la página.
3. En el compilador de consultas, agrega lo siguiente:
• Recurso: Selecciona Base de datos de AlloyDB. En el cuadro de diálogo, selecciona una instancia de AlloyDB.
• Nombres de registros: Desplázate a la sección de AlloyDB y selecciona los archivos de registro apropiados para tu instancia. Por ejemplo:
  • alloydb.googlapis.com/postgres.log
• Gravedad: Selecciona un nivel de registro.
• Intervalo de tiempo: Selecciona un ajuste predeterminado o crea un intervalo personalizado.

gcloud

Usa el comando gcloud logging para ver las entradas del registro. En el siguiente ejemplo, reemplaza PROJECT_ID. La marca limit es un parámetro opcional que indica la cantidad máxima de entradas que se mostrarán.

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

Solución de problemas de VPN

Consulta la página de Google Cloud solución de problemas de Cloud VPN.

Soluciona problemas de errores del proxy TCP

La forma en que se configura el proxy TCP también puede generar errores. Para solucionar un error del proxy TCP, consulta los siguientes ejemplos de problemas y cómo se pueden resolver:

No se pudo iniciar la máquina virtual (VM)

Cuando inicias la instancia de VM en Compute Engine, ves el siguiente mensaje:

You do not currently have an active account selected.

Qué puedes probar

Ejecuta uno de los siguientes comandos para configurar una cuenta activa:

• Para obtener credenciales nuevas, ejecuta el siguiente comando:

  gcloud auth login
  

• Para seleccionar una cuenta ya autenticada, ejecuta el siguiente comando:

  gcloud config set account ACCOUNT
  

  Reemplaza ACCOUNT por el nombre de la cuenta que deseas configurar.

Falla en la conexión a la instancia de la base de datos de origen

Verás el siguiente mensaje de error cuando pruebes el trabajo de migración:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

Qué puedes probar

Sigue estos pasos para comprender dónde podría estar el problema:

1. Verifica si se está ejecutando la VM que aloja el contenedor del proxy TCP:

   1. En la consola, ve a la página Instancias de VM de Compute Engine.

      Ir a Instancias de VM

   2. Busca la VM que se creó como parte del proceso de configuración del proxy. Si no aparece en la lista o no se está ejecutando, configura tu proxy TCP desde cero y actualiza la configuración de la instancia de origen en el trabajo de migración con la dirección IP correcta.

2. Si la VM está en ejecución, verifica que no haya habido ningún error al descargar la imagen del contenedor del proxy de TCP:

   1. Selecciona la VM que se creó como parte del proceso de configuración del proxy TCP. En Registros, haz clic en Puerto en serie 1 (consola).

   2. Si no ves la entrada Launching user container 'gcr.io/dms-images/tcp-proxy' en los registros, es posible que el problema sea que tu instancia no pudo extraer la imagen de Container Registry. Para verificar si este es el caso, conéctate a la VM y, de forma manual, intenta extraer la imagen de Container Registry con el siguiente comando:

      docker pull gcr.io/dms-images/tcp-proxy

      Si ves el siguiente error: Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), significa que tu VM no pudo conectarse a Container Registry. Si tu VM solo tiene una dirección IP privada, debes habilitar el Acceso privado a Google en la subred a la que pertenece la dirección IP. De lo contrario, la VM no tendrá acceso a las APIs de Google Enterprise, como Container Registry.

3. Verifica que el contenedor pueda conectarse a la instancia de origen:

   1. Selecciona la VM que se creó como parte del proceso de configuración del proxy. En Registros, haz clic en Cloud Logging.

   2. Si ves el siguiente mensaje: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, significa que el contenedor del proxy de TCP no pudo conectarse a la instancia de la base de datos de origen. Esto puede suceder por varios motivos:

      • La dirección IP de la instancia de origen es incorrecta.
      • Hay una política de firewall que rechaza las conexiones del proxy TCP a la instancia de origen.
      • La instancia de origen se encuentra en una red de nube privada virtual (VPC) diferente de la VM que aloja el proxy TCP.

   Puedes depurar el problema de conectividad con las pruebas de conectividad de Google Cloudpara asegurarte de que haya conectividad entre la base de datos de destino y la VM que aloja el proxy TCP:

   1. En la consola, ve a la página Pruebas de conectividad.

      Ir a Pruebas de conectividad

   2. Haz clic en Crear prueba de conectividad.

   3. Ingresa un nombre para la prueba.

   4. Selecciona TCP como el protocolo.

   5. Selecciona Dirección IP en la lista Extremo de origen. Ingresa la dirección IP pública del proxy TCP recién creado si se puede acceder a la base de datos de origen con una dirección IP pública. De lo contrario, ingresa la dirección IP privada del proxy TCP.

   6. Selecciona Dirección IP en la lista Extremo de destino y, luego, ingresa la dirección IP de la base de datos de origen.

   7. Ingresa el número de puerto que se usa para conectarse a la base de datos de origen en el campo Puerto de destino.

   8. Haz clic en Crear.

   Ejecuta la prueba de conectividad y soluciona los problemas que surjan. Después de solucionar el problema de conectividad, verifica que el proxy TCP pueda conectarse a la instancia de origen:

   1. Ve a Instancias de VM en Compute Engine.

      Ir a Instancias de VM

   2. Selecciona la VM que se creó como parte del proceso de configuración del proxy. En Registros, haz clic en Cloud Logging.

   3. Si ves la entrada de registro Connection to source DB verified, significa que el proxy TCP ahora puede conectarse a la instancia de origen.

4. Verifica que la prueba de migración no falle debido a problemas de conexión.

Falla en la conexión a la instancia de la base de datos de destino

Si el contenedor de proxy TCP se puede conectar a la instancia de origen, pero la prueba de migración sigue fallando debido a problemas de conexión, el problema podría ser la conectividad entre la instancia de destino y la VM que aloja el contenedor de proxy TCP.

Depura el problema

Para depurar el problema, puedes usar las pruebas de conectividad de Google Cloudpara asegurarte de que haya conectividad entre la base de datos de destino y la VM que aloja el proxy TCP:

1. En la consola, ve a la página Pruebas de conectividad.

   Ir a Pruebas de conectividad

2. Haz clic en Crear prueba de conectividad.

3. Establece los siguientes parámetros para tu prueba:

   1. Ingresa un nombre para la prueba.
   2. Selecciona TCP como el protocolo.
   3. Selecciona Dirección IP en la lista Extremo de origen y, luego, ingresa la dirección IP del clúster de AlloyDB recién creado.
   4. Selecciona Dirección IP en la lista Extremo de destino y, luego, ingresa la dirección IP privada del proxy TCP.
   5. Ingresa 5432 en el campo Puerto de destino.

4. Haz clic en Crear.

5. Ejecuta la prueba de conectividad y soluciona los problemas que surjan.

Causas posibles

Hay una regla de firewall que deniega la comunicación entre la instancia de destino y la VM del proxy TCP.

Qué puedes probar

Agrega una regla de firewall que permita que la instancia de destino se comunique con el proxy TCP a través del puerto 5432.

Causas posibles

Hay una discrepancia de VPC entre la instancia de destino y la VM que ejecuta el contenedor del proxy TCP.

Qué puedes probar

Selecciona la misma VPC para la instancia de destino.

Soluciona problemas relacionados con el túnel SSH inverso

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 mantiene la red de destino como la que inicia la conexión del túnel. Esto es útil cuando no quieres abrir un puerto en tu propia red por motivos de seguridad.

Lo que intentas lograr es configurar lo siguiente: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Aunque Database Migration Service migra datos de un origen a un destino, debes habilitar la conectividad del destino al origen.

Se supone lo siguiente:

• El AlloyDB destination puede acceder al Compute Engine VM bastion.

• El source network bastion puede acceder al source DB (esto se logra a través de la interconexión de la red de AlloyDB con la red de la VM de Compute Engine).

Luego, configuras un túnel SSH desde source network bastion hasta Compute Engine VM bastion, que enruta cualquier conexión entrante a algún puerto en Compute Engine VM bastion a través del túnel hasta source DB.

Cada vínculo en la situación anterior se puede configurar de forma incorrecta y evitar que funcione todo el flujo. Soluciona los problemas de cada vínculo, uno por uno:

source network bastion ---> source DB

1. Conéctate a source network bastion con SSH o desde la terminal si es la máquina local.
2. Prueba la conectividad a la base de datos de origen con uno de los siguientes métodos:
   • telnet [source_db_host_or_ip] [source_db_port]: Deberías ver las cadenas de conexión de Telnet, que terminan con Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port]: Se espera que se muestre el mensaje de acceso denegado.

Si esto falla, debes verificar que habilitaste el acceso desde este host bastión a la base de datos de origen.

Compute Engine VM bastion ---> source DB

1. Conéctate a Compute Engine VM bastion a través de SSH (con gcloud compute ssh VM_INSTANCE_NAME)
2. Prueba la conectividad a la base de datos de origen con uno de los siguientes métodos:
   • telnet 127.0.0.1 [tunnel_port]: Deberías ver las cadenas de conexión de Telnet, que terminan con Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port]: Se espera que se deniegue el acceso

Si esto falla, debes verificar que el túnel esté activado y funcionando correctamente. La ejecución de sudo netstat -tupln muestra todos los procesos de escucha en esta VM, y deberías ver sshd listening on the tunnel_port.

AlloyDB DB ---> source DB

testing the migration job de Database Migration Service es quien mejor puede probar esto. Si esto falla, significa que hay algún problema con el intercambio de tráfico entre VPC o el enrutamiento entre la red de AlloyDB y la red de Compute Engine VM bastion.

El firewall del servidor de la base de datos de origen debe configurarse para permitir todo el rango de IP interna asignado a la conexión de servicio privada de la red de VPC que la instancia de destino de AlloyDB usará como el campo privateNetwork de su configuración de ipConfiguration.

Para encontrar el rango de IP interna en la consola, sigue estos pasos:

1. Ve a la página Redes de VPC en la consola de Google Cloud .

2. Selecciona la red de VPC que deseas usar.

3. Selecciona Acceso privado a servicios > Rangos de IP asignados para servicios.

4. Busca el rango de IP interna asociado con la conexión creada por servicenetworking-googleapis-com.

También puedes ver el tráfico entre la instancia de AlloyDB y la instancia de VM de Compute Engine en la consola de Cloud Logging en el proyecto Cloud VPN gateway. En los registros de la VM de Compute Engine, busca el tráfico proveniente de la instancia de AlloyDB. En los registros de la instancia de AlloyDB, busca el tráfico de la VM de Compute Engine.