MySQL localhost a través de una VPN: sigue siendo el proceso local

La aplicación del servidor de oficina se conecta a MySQL en localhost, copias ese nombre de host en un cliente de escritorio y la conexión falla o abre otra base de datos. La VPN no cambió el significado de la palabra: localhost sigue refiriéndose a la máquina que ejecuta el cliente. La VPN movió paquetes, no interfaces. Decide a qué extremo debe llegar el portátil antes de tocar una ruta.

Paso 1: decide a qué extremo debe llegar el portátil

Los dos diseños son legítimos y responden a preguntas distintas. El acceso directo significa que la base de datos escucha en una dirección privada que el túnel alcanza, y el portátil se conecta a esa dirección. El acceso reenviado significa que la base de datos se queda en loopback y una sesión SSH lleva el puerto hasta tu máquina. Elige uno a propósito, porque mezclarlos produce una conexión que funciona por el motivo equivocado.

Para el acceso directo, consigue el nombre o la dirección privada propia del host de la base de datos y su puerto de quien la administra. La dirección de la puerta de enlace VPN no es la dirección de la base de datos salvo que sea la misma máquina. Luego confirma que el listener está realmente ligado a esa interfaz, porque una ruta hacia una interfaz no crea un listener en ella.

Paso 2: reenvía el puerto solo si el listener se queda local

Si la base de datos debe quedarse solo en loopback, reenvíala por SSH y liga también el extremo local a loopback. La dirección de enlace de la izquierda pertenece a tu portátil; el destino de la derecha se interpreta desde el lado del servidor SSH, como describe la referencia de OpenSSH. Invertir esos dos papeles es el motivo habitual de que un reenvío parezca funcionar pero no conecte con nada.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Si SSH aterriza en un host de salto en lugar del host de la base de datos, el loopback de la derecha se refiere al host de salto, y el destino tiene que cambiar a una dirección que ese host alcance. ExitOnForwardFailure detecta un fallo al establecer el reenvío, pero no demuestra que las conexiones posteriores al destino tengan éxito. Mantén activa la comprobación de la clave de host y no ofrezcas el puerto de reenvío a toda tu LAN ligándolo a todas las interfaces.

Detente si la base de datos debe quedarse solo en loopback y no puedes usar SSH. Entonces el acceso directo es el diseño equivocado, no una configuración que forzar.

Paso 3: fuerza el cliente a TCP

En Unix, un cliente de MySQL al que se da localhost elige un socket Unix por defecto, así que cambiar solo el puerto puede dejarlo buscando un socket que no tiene nada que ver con tu reenvío. Usa el protocolo TCP explícito y la dirección loopback para que el cliente abra una conexión a tu puerto de reenvío.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

La opción de contraseña sin valor pregunta en lugar de poner el secreto en la línea de comandos, y esa es la costumbre que vale la pena mantener. Otras herramientas tienen su propio interruptor para la misma distinción, y algunos controladores también tratan localhost de forma especial. Comprueba qué hace tu cliente en lugar de suponer que el indicador se mantuvo. La cuenta de la base de datos también necesita un permiso que coincida con el origen que ve el servidor, que es el host de reenvío y no tu portátil.

Detente si la herramienta no se puede forzar a TCP. Entonces usa otro cliente o el acceso directo al listener privado.

Paso 4: demuestra a qué extremo llegaste realmente

Pregunta al servidor qué cree que es la conexión. Las variables de nombre de host, puerto y socket te dicen si llegaste por TCP y qué listener respondió, y la lista de conexiones muestra la dirección de origen que registró el servidor. Esa evidencia es más útil que otro cambio de ruta.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Anota a qué extremo intentaste llegar: un socket Unix local, tu puerto de reenvío o el listener privado. Esos tres fallos tienen arreglos distintos, y cambiar la ruta de la VPN mientras el cliente sigue hablando con el localhost equivocado es esfuerzo perdido. Mantén también separadas en las notas la autenticación SSH y la autenticación de la base de datos, porque un fallo en una parece un fallo en la otra desde un cliente de escritorio. Después quita el reenvío cuando termines.

La lista termina cuando puedes nombrar el extremo, el protocolo del cliente, la dirección de origen que vio el servidor y el permiso que lo permitió. Cuatro hechos, y el siguiente problema de conexión tarda minutos en lugar de una tarde.