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:
Ve a la página Instancias de SQL en la Google Cloud console.
Haz clic en el nombre de la instancia asociada a la tarea de migración que estás depurando.
Desplázate hacia abajo hasta que aparezca el panel Conectarse a esta instancia. En este panel, aparece la dirección IP de salida.
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.
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 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 ejemplo de Cloud SQL.Ver registros
Puedes ver los registros de las instancias de Cloud SQL y de otros proyectos, como las instancias de Cloud VPN o Compute Engine. Google Cloud Para ver los registros de tu instancia de Cloud SQL, sigue estos pasos:Consola
- Ir al Explorador de registros
- En la parte superior de la página, selecciona un proyecto de Cloud SQL.
- En el creador de consultas, añade lo siguiente:
- Recurso: selecciona Base de datos de Cloud SQL. En el cuadro de diálogo, selecciona una instancia de Cloud SQL.
- Nombres de registro: desplázate hasta la sección Cloud SQL y selecciona los archivos de registro adecuados para tu instancia. Por ejemplo:
- cloudsql.googleapis.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/cloudsql.googleapis.com/postgres.log" --limit=10
Direcciones IP privadas
Las conexiones a una instancia de Cloud SQL mediante una dirección IP privada se autorizan automáticamente para los intervalos de direcciones RFC 1918. Los intervalos de direcciones que no sean RFC 1918 deben configurarse en Cloud SQL como redes autorizadas. También debes actualizar el peering de red a Cloud SQL para exportar las rutas que no sean RFC 1918. Por ejemplo:
gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
El intervalo de IPs 172.17.0.0/16 está reservado para la red de puente de Docker. No se podrá acceder a las instancias de Cloud SQL creadas con una dirección IP de ese intervalo. Las conexiones desde cualquier dirección IP de ese intervalo a instancias de Cloud SQL que usen una dirección IP privada fallarán.
Solución de problemas de VPN
Consulta la página Google Cloud Solución de problemas de Cloud VPN.
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: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Se presupone que:
El Compute Engine VM bastion puede acceder al Cloud SQL DB.
La source network bastion puede acceder a la source DB (esto se consigue emparejando la red de Cloud SQL 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
- Conéctate a la source network bastion mediante SSH o desde el terminal si se trata de la máquina local.
- 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 enConnected 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
- Acceder a Compute Engine VM bastion mediante SSH (con
gcloud compute ssh VM_INSTANCE_NAME) - 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 enConnected 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.
Cloud SQL 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 Cloud SQL 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 va a usar la instancia de destino de Cloud SQL como campo privateNetwork de sus ajustes de ipConfiguration.
Para encontrar el intervalo de IP internas en la consola, sigue estos pasos:
Ve a la página Redes de VPC de la consola de Google Cloud .
Selecciona la red de VPC que quieras usar.
Selecciona Acceso a servicios privados > Intervalos de direcciones IP asignados para los servicios.
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 Cloud SQL y la de máquina virtual 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 Cloud SQL. En los registros de la instancia de Cloud SQL, busca el tráfico de la máquina virtual de Compute Engine.