MariaDB sobre VPN: ¿qué user@host ve el servidor?
La cuenta se elige por usuario y host juntos. Encuentre el origen que vio el servidor, lea CURRENT_USER() y luego repare esa fila, no el permiso.
Escriba el mismo nombre de usuario desde dos rutas distintas y MariaDB puede autenticarle como dos cuentas diferentes. Las cuentas se basan en el usuario y el host juntos, así que 'reporter'@'localhost' y 'reporter'@'10.90.0.23' son filas separadas con contraseñas separadas y permisos separados. Sobre una VPN, la pregunta interesante no es qué nombre escribió el usuario, sino qué dirección de origen vio el servidor.
Determine el origen que el servidor ve realmente
Trabaje hacia atrás desde el host de la base de datos, no desde el portátil. La dirección que el cliente cree tener es solo una de varias posibilidades:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
Use pruebas del lado del servidor para resolverlo. Un registro de conexiones, una lista de sesiones activas o una entrada temporal en el registro general muestran la dirección que el servidor aceptó. La IP pública del portátil desde un navegador es un hecho distinto y a menudo engañoso.
Empareje la cuenta que MariaDB seleccionó
La selección de cuenta sigue un orden documentado y no una unión de permisos. Una coincidencia exacta de host tiene prioridad sobre un comodín, y las filas de usuario anónimo participan en la coincidencia de formas que sorprenden a quienes asumen que el nombre por sí solo decide. El servidor elige una fila; no fusiona los privilegios de cada fila con nombre similar. Leer la referencia una vez vale más que una tarde probando conjeturas.
Eso significa que añadir un permiso a 'reporter'@'%' puede no cambiar nada si la sesión se autenticó como 'reporter'@'10.90.0.23'. La corrección debe recaer en la fila que se seleccionó, por eso identificar la cuenta va antes de editar permisos.
Lea la cuenta que la sesión usa realmente
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() nombra la cuenta que autenticó la sesión; USER() informa de lo que pidió el cliente y puede diferir. Ejecútelas como consultas normales de nivel superior, no desde dentro de una rutina almacenada con contexto de definidor, o las respuestas describirán al propietario de la rutina en lugar de su sesión.
Un inicio de sesión fallido no puede ejecutar nada de esto, y ese es el caso en que un administrador debe inspeccionar las definiciones de cuentas y las pruebas de conexión del servidor. Planifíquelo: quien depura un inicio de sesión rechazado normalmente no tiene ninguna sesión SQL para consultar.
Separe la alcanzabilidad de la autenticación
El texto del error le dice en qué capa está. Una conexión rechazada o un tiempo de espera agotado significa que el cliente nunca llegó a un escucha, así que la cuenta y su contraseña aún no están en cuestión. Una respuesta de acceso denegado significa que el servidor respondió, lo que demuestra alcanzabilidad y apunta a la cuenta, a la coincidencia de host o a la credencial.
Los requisitos de red son su propia lista: un escucha vinculado a la dirección prevista y no solo al loopback, tráfico permitido al puerto configurado y una ruta de retorno para la respuesta. Cada uno puede fallar de forma independiente, y un túnel que funciona no implica ninguno de ellos. Un escucha en loopback acepta conexiones locales y rechaza todas las remotas, lo que produce una conexión rechazada que parece un bloqueo del cortafuegos.
Compruebe la dirección de enlace antes de abrir un tique con el equipo de red. ss -lntp en el host de la base de datos muestra qué dirección y puerto están realmente escuchando, y esa sola línea descarta toda una categoría de conjeturas.
Repare de forma estrecha y vuelva a probar ambas direcciones
Cree la cuenta prevista cualificada por host mediante el proceso aprobado de la organización, con una credencial del almacén soportado y no una compartida pegada en un tique. Conceda solo las operaciones de esquema que la tarea necesita. Convertir un inicio de sesión remoto fallido en una cuenta root, una política de concederlo todo o un host comodín general hace que la prueba pase y elimina el control que estaba probando. El permiso que añadió con prisa es el que nadie retira después.
Vuelva a probar con una sesión nueva por la ruta prevista y luego compruebe los casos negativos. Una ruta que debería estar bloqueada debe seguir bloqueada, y una operación que no se concedió debe seguir denegada. Esas dos comprobaciones son lo que separa una cuenta reparada de una ampliada.
Por último, registre la dirección de origen observada y el nombre de la cuenta juntos. El túnel proporciona alcanzabilidad; MariaDB sigue eligiendo y autorizando su propia cuenta, y la siguiente persona necesita ambos hechos para reproducir su resultado.