Depurar conectividad

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Depurar la conectividad

Has configurado la conectividad entre las bases de datos de origen y de destino, pero ¿cómo sabes si están conectadas? Si la comunicación entre ellos falla, ¿cómo puedes averiguar qué ha fallado 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 desde el origen. Ping envía un paquete ICMP Echo Request a un host remoto y espera recibir un paquete ICMP Echo Reply a cambio. Si ping no se completa, significa que no hay ninguna ruta desde el origen hasta el destino. Sin embargo, que se haya completado correctamente no significa que tus paquetes puedan llegar, sino que, en general, se puede acceder al host remoto.

Aunque ping puede saber si un host está activo y responde, no se garantiza que sea fiable. Algunos proveedores de redes bloquean ICMP como medida de seguridad, lo que puede dificultar la depuración de la conectividad.

Traceroute

Traceroute prueba la ruta completa que siguen los paquetes de red de un host a otro. Muestra todos los pasos ("saltos") que da el paquete por el camino y cuánto tiempo tarda en dar cada paso. Si el paquete no llega al destino, traceroute no se completa, sino que termina con una serie de asteriscos. En este caso, busca la última dirección IP a la que se haya podido acceder correctamente. Aquí es donde se ha interrumpido la conectividad.

Traceroute puede agotarse. También puede fallar si una pasarela del trayecto no está configurada correctamente para enviar el paquete al siguiente salto.

Si traceroute no se completa, puede que sepas dónde se ha detenido. Busca la última dirección IP que aparece en el traceroute resultado y haz una búsqueda en el navegador de who owns [IP_ADDRESS]. Es posible que los resultados muestren o no el propietario de la dirección, pero merece la pena intentarlo.

mtr

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

Localizar tu dirección IP local

Si no sabes la dirección local de tu host, ejecuta el comando ip -br address show. En Linux, se 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.

También puedes ejecutar ipconfig o ifconfig para ver el estado de tus interfaces de red.

Localiza la dirección IP de salida

Si no sabes la dirección IP que usan las bases de datos de origen y de destino para comunicarse entre sí (la dirección IP saliente), sigue estos pasos:

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

   Ir a la página Clústeres de AlloyDB

2. Busca el clúster asociado a la tarea de migración que estás depurando.

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

Abrir puertos locales

Para verificar que tu host está escuchando en los puertos que crees que son, ejecuta el comando ss -tunlp4. De esta forma, sabrás qué puertos están abiertos y en escucha. Por ejemplo, si tienes una base de datos de PostgreSQL en ejecución, el puerto 5432 debería estar activo y en escucha. En el caso de SSH, debería ver el puerto 22.

Toda la actividad de los puertos locales

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

Conectarse al host remoto mediante telnet

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

Por ejemplo, si tu host remoto ejecuta una base de datos PostgreSQL, deberías poder conectarte a él mediante telnet en el puerto 5432: telnet 35.193.198.159 5432.

Si la operación se realiza correctamente, verás lo siguiente:

Trying 35.193.198.159...

Connected to 35.193.198.159. .

Si falla, verás que telnet deja de responder hasta que fuerces el cierre del intento:

Trying 35.193.198.159...

^C. .

Autenticación del cliente

La autenticación de clientes se controla mediante un archivo de configuración llamado pg_hba.conf (HBA significa autenticación basada en el host).

Asegúrate de que la sección de conexiones de replicación del archivo pg_hba.conf de la base de datos de origen se haya actualizado para aceptar conexiones del intervalo 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 ejemplo de Cloud SQL.

Ver registros

Puedes ver los registros de las instancias de AlloyDB y de otros proyectos, como Cloud VPN o las instancias de Compute Engine. Google CloudPara ver los registros de tu instancia de AlloyDB, sigue estos pasos:

Consola

1. Ir al Explorador de registros
2. En la parte superior de la página, selecciona un proyecto de AlloyDB.
3. En el creador de consultas, añade lo siguiente:
• Recurso: selecciona Base de datos de AlloyDB. En el cuadro de diálogo, selecciona una instancia de AlloyDB.
• Nombres de los registros: desplázate hasta la sección AlloyDB y selecciona los archivos de registro adecuados para tu instancia. Por ejemplo:
  • alloydb.googlapis.com/postgres.log
• Gravedad: selecciona un nivel de registro.
• Intervalo de tiempo: seleccione un intervalo predefinido o cree uno personalizado.

gcloud

Usa el comando gcloud logging para ver las entradas de registro. En el ejemplo de abajo, sustituye PROJECT_ID. La marca limit es un parámetro opcional que indica el número máximo de entradas que se van a devolver.

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

Solución de problemas de VPN

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

Solucionar errores de proxy TCP

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

No se ha podido iniciar la máquina virtual (VM)

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

You do not currently have an active account selected.

Cosas que puedes probar

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

• Para obtener nuevas credenciales, ejecuta el siguiente comando:

  gcloud auth login
  

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

  gcloud config set account ACCOUNT
  

  Sustituye ACCOUNT por el nombre de la cuenta que quieras configurar.

No se ha podido conectar a la instancia de base de datos de origen

Aparece el siguiente mensaje de error al probar 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.

Cosas que puedes probar

Sigue los pasos que se indican a continuación para determinar dónde puede estar el problema:

1. Comprueba si la VM que aloja el contenedor de proxy TCP está en ejecución:

   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 o no se está ejecutando, configura tu proxy TCP desde cero y actualiza los ajustes 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, comprueba que no se haya producido ningún error al descargar la imagen del contenedor del proxy TCP:

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

   2. Si no ves la entrada Launching user container 'gcr.io/dms-images/tcp-proxy' en los registros, es posible que tu instancia no haya podido extraer la imagen de Container Registry. Para comprobar si es así, conéctate a la VM e intenta extraer manualmente la imagen de Container Registry con el siguiente comando:

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

      Si aparece 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 ha podido conectarse a Container Registry. Si tu VM solo tiene una dirección IP privada, debes habilitar Acceso privado de 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 se puede conectar 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 de proxy TCP no se ha podido conectar a la instancia de base de datos de origen. Esto puede deberse a varios motivos:

      • La dirección IP de la instancia de origen es incorrecta.
      • Hay una política de cortafuegos que rechaza las conexiones del proxy TCP a la instancia de origen.
      • La instancia de origen está en una red de nube privada virtual (VPC) diferente de la máquina virtual 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. Escribe el nombre de la prueba.

   4. Selecciona TCP como protocolo.

   5. Seleccione Dirección IP en la lista Endpoint de origen. Introduce la dirección IP pública del proxy TCP recién creado si se puede acceder a la base de datos de origen mediante una dirección IP pública. De lo contrario, introduce la dirección IP privada del proxy TCP.

   6. Selecciona Dirección IP en la lista Endpoint de destino e introduce la dirección IP de la base de datos de origen.

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

   8. Haz clic en Crear.

   Ejecuta la prueba de conectividad y soluciona los problemas que surjan. Una vez que hayas solucionado el problema de conectividad, comprueba que el proxy TCP puede 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.

No se puede conectar a la instancia de base de datos de destino

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

Depurar 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. Define los siguientes parámetros para la prueba:

   1. Escribe el nombre de la prueba.
   2. Selecciona TCP como protocolo.
   3. Selecciona Dirección IP en la lista Endpoint de origen e introduce la dirección IP del clúster de AlloyDB que acabas de crear.
   4. Selecciona Dirección IP en la lista Endpoint de destino e introduce la dirección IP privada del proxy TCP.
   5. Introduce 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 cortafuegos que deniega la comunicación entre la instancia de destino y la VM proxy TCP.

Cosas que puedes probar

Añade una regla de cortafuegos que permita que la instancia de destino se comunique con el proxy TCP mediante el puerto 5432.

Causas posibles

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

Cosas que puedes probar

Selecciona la misma VPC para la instancia de destino.

Solucionar problemas con túneles inversos SSH

El túnel SSH es un método para reenviar algunas comunicaciones a través de una conexión SSH. La tunelización inversa SSH 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 quieres abrir un puerto en tu red por motivos de seguridad.

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

Aunque el servicio de migración de bases de datos migra datos de un origen a un destino, debes habilitar la conectividad del destino al origen.

Se presupone que:

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

• El source network bastion puede acceder al source DB (para ello, se empareja la red de AlloyDB con la red de la VM de Compute Engine).

Después, configura un túnel SSH desde source network bastion hasta Compute Engine VM bastion, que dirige las conexiones entrantes a algún puerto de Compute Engine VM bastion a través del túnel hasta source DB.

Cada enlace del caso anterior se puede configurar de forma incorrecta e impedir que funcione todo el flujo. Soluciona los problemas de cada enlace, uno por uno:

source network bastion ---> source DB

1. Conéctate a la source network bastion mediante SSH o desde el terminal si se trata de la máquina local.
2. Pruebe la conectividad a la base de datos de origen mediante uno de los siguientes métodos:
   • telnet [source_db_host_or_ip] [source_db_port]: verás las cadenas de conexión telnet, que terminan en Connected to x.x.x.x.
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] - expect to see access denied

Si no funciona, debes verificar que has habilitado el acceso desde este bastion a la base de datos de origen.

Compute Engine VM bastion ---> source DB

1. Acceder a Compute Engine VM bastion mediante SSH (con gcloud compute ssh VM_INSTANCE_NAME)
2. Pruebe la conectividad a la base de datos de origen mediante uno de los siguientes métodos:
   • telnet 127.0.0.1 [tunnel_port]: verás las cadenas de conexión telnet, que terminan en Connected to x.x.x.x.
   • [db_client] -h127.0.0.1 -P[tunnel_port]: se deniega el acceso

Si no funciona, debes verificar que el túnel esté activo y funcione correctamente. Al ejecutar sudo netstat -tupln, se muestran todos los procesos de escucha de esta VM y deberías ver sshd listening on the tunnel_port.

AlloyDB DB ---> source DB

La mejor forma de probarlo es con testing the migration job de Database Migration Service. Si falla, significa que hay algún problema con el emparejamiento o el enrutamiento de VPC entre la red de AlloyDB y la red Compute Engine VM bastion.

El cortafuegos del servidor de la base de datos de origen debe configurarse para permitir todo el intervalo de IPs internas asignado a la conexión de servicio privada de la red de VPC que la instancia de destino de AlloyDB va a usar como campo privateNetwork de sus ajustes ipConfiguration.

Para encontrar el intervalo de IP internas en la consola, sigue estos pasos:

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

2. Selecciona la red de VPC que quieras usar.

3. Selecciona Acceso a servicios privados > Intervalos de direcciones IP asignados para los servicios.

4. Busca el intervalo de IPs internas asociado a 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 Cloud Logging del proyecto Cloud VPN gateway. En los registros de la VM de Compute Engine, busca el tráfico procedente de la instancia de AlloyDB. En los registros de la instancia de AlloyDB, busca el tráfico de la VM de Compute Engine.