Depurar la conectividad

Depura la conectividad

Configuraste la conectividad entre tus bases de datos de origen y de destino, pero ¿cómo sabes que están conectadas? Cuando falla la comunicación entre ellos, ¿cómo puedes averiguar 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 desde 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, el éxito no significa que tus paquetes puedan pasar, solo que, en general, se puede alcanzar el 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 de destino para comunicarse entre sí (la dirección IP saliente), completa los siguientes pasos:

  1. Ve a la página Instancias de SQL en la consola de Google Cloud .

    Ir a la página de instancias de Cloud SQL

  2. Haz clic en el nombre de la instancia asociada al trabajo de migración que estás depurando.
  3. Desplázate hacia abajo hasta que aparezca el panel Conectarse a esta instancia. En este panel, aparece la dirección IP saliente.

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 de PostgreSQL en ejecución, el puerto 5432 debería 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 de PostgreSQL, deberías poder conectarte a él con Telnet en el puerto 5432: telnet 35.193.198.159 5432.

Si se ejecuta de forma correcta, 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 Cloud SQL.

Cloud Logging

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

Console

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

gcloud

Usa el comando gcloud logging para ver las entradas de 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 devolverán.

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 con una dirección IP privada se autorizan de forma automática para los rangos de direcciones RFC 1918. Los rangos de direcciones que no son RFC 1918 deben configurarse en Cloud SQL como redes autorizadas. También debes actualizar el intercambio de tráfico entre redes a 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 de puente Docker. No se podrá acceder a las instancias de Cloud SQL que se crearon con una dirección IP de ese rango. Fallarán las conexiones desde cualquier dirección IP dentro de ese rango a instancias de Cloud SQL que usen una dirección IP privada.

Solución de problemas de VPN

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

Soluciona problemas del túnel SSH inverso

La tunelización SSH es un método para reenviar algunas comunicaciones sobre una conexión SSH. La tunelización SSH inversa permite configurar un túnel SSH, pero mantiene que la red de destino es 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:

Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

Se supone lo siguiente:

  • El Compute Engine VM bastion puede acceder al Cloud SQL DB.

  • La source network bastion puede acceder a la source DB (esto se logra intercambiando el tráfico de la red de Cloud SQL con la red de la VM de Compute Engine).

Luego, configura un túnel SSH desde el source network bastion hasta el Compute Engine VM bastion, que enruta las conexiones entrantes a un puerto en el Compute Engine VM bastion a través del túnel hasta el source DB.

Cada vínculo de 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 la 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]: Se espera ver las cadenas de conexión de telnet, que terminan con Connected to x.x.x.x.
    • psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name]: Deberías ver un mensaje para ingresar la contraseña o un mensaje de acceso denegado.

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

Compute Engine VM bastion ---> source DB

  1. Establece una conexión SSH a Compute Engine VM bastion (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]: Se espera ver las cadenas de conexión de telnet, que terminan con Connected to x.x.x.x.
    • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name]: Deberías ver un mensaje para ingresar la contraseña o un mensaje de acceso denegado.

Si esto falla, debes verificar que el túnel esté activo y funcionando correctamente. Si ejecutas sudo netstat -tupln, se mostrarán todos los procesos de escucha en esta VM, y deberías ver sshd listening on the tunnel_port.

Cloud SQL DB ---> source DB

La mejor manera de probar esto es con testing the migration job de Database Migration Service. Si esto falla, significa que hay algún problema con el intercambio de tráfico entre VPC o el enrutamiento entre la red de Cloud SQL 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 privada a servicios de la red de VPC que la instancia de destino de Cloud SQL 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 que creó servicenetworking-googleapis-com.

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 la VM de Compute Engine, busca el tráfico que proviene de la instancia de Cloud SQL. En los registros de la instancia de Cloud SQL, busca el tráfico de la VM de Compute Engine.