MariaDB sobre VPN: que user@host ve o servidor?
A conta elíxese por usuario e host xuntos. Atope a orixe que viu o servidor, lea CURRENT_USER() e despois repare esa fila, non o permiso.
Escriba o mesmo nome de usuario desde dúas rutas distintas e MariaDB pode autenticalo como dúas contas diferentes. As contas baséanse no usuario e o host xuntos, así que 'reporter'@'localhost' e 'reporter'@'10.90.0.23' son filas separadas con contrasinais separados e permisos separados. Sobre unha VPN, a pregunta interesante non é que nome escribiu o usuario, senón que dirección de orixe viu o servidor.
Determine a orixe que o servidor ve realmente
Traballe cara atrás desde o host da base de datos, non desde o portátil. A dirección que o cliente cre ter é só unha 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 probas do lado do servidor para resolvelo. Un rexistro de conexións, unha lista de sesións activas ou unha entrada temporal no rexistro xeral mostran a dirección que o servidor aceptou. O IP público do portátil desde un navegador é un feito distinto e a miúdo enganoso.
Emparexe a conta que MariaDB seleccionou
A selección de conta segue unha orde documentada e non unha unión de permisos. Unha coincidencia exacta de host ten prioridade sobre un comodín, e as filas de usuario anónimo participan na coincidencia de formas que sorprenden a quen asume que o nome só decide. O servidor escolle unha fila; non fusiona os privilexios de cada fila co mesmo nome. Ler a referencia unha vez vale máis que unha tarde probando conxecturas.
Isto significa que engadir un permiso a 'reporter'@'%' pode non cambiar nada se a sesión se autenticou como 'reporter'@'10.90.0.23'. A corrección debe recaer na fila que se seleccionou, por iso identificar a conta vai antes de editar permisos.
Lea a conta que a sesión usa realmente
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() nomea a conta que autenticou a sesión; USER() informa do que pediu o cliente e pode diferir. Execúteas como consultas normais de nivel superior, non desde dentro dunha rutina almacenada con contexto de definidor, ou as respostas describirán o propietario da rutina en lugar da súa sesión.
Un inicio de sesión fallido non pode executar nada disto, e ese é o caso en que un administrador debe inspeccionar as definicións de contas e as probas de conexión do servidor. Planifíqueo: quen depura un inicio de sesión rexeitado normalmente non ten ningunha sesión SQL para consultar.
Separe a alcanzabilidade da autenticación
O texto do erro dille en que capa está. Unha conexión rexeitada ou un tempo de espera esgotado significa que o cliente nunca chegou a un escoitante, así que a conta e o seu contrasinal aínda non están en cuestión. Unha resposta de acceso denegado significa que o servidor respondeu, o que demostra alcanzabilidade e apunta á conta, á coincidencia de host ou á credencial.
Os requisitos de rede son a súa propia lista: un escoitante vinculado á dirección prevista e non só ao loopback, tráfico permitido ao porto configurado e unha ruta de retorno para a resposta. Cada un pode fallar de forma independente, e un túnel que funciona non implica ningún deles. Un escoitante en loopback acepta conexións locais e rexeita todas as remotas, o que produce unha conexión rexeitada que parece un bloqueo do devasado.
Comprobe a dirección de enlace antes de abrir un tícket co equipo de rede. ss -lntp no host da base de datos mostra que dirección e porto están realmente escoitando, e esa soa liña descarta toda unha categoría de conxecturas.
Repare de forma estreita e volva probar ambas as direccións
Cree a conta prevista cualificada por host mediante o proceso aprobado da organización, cunha credencial do almacén soportado e non unha compartida pegada nun tícket. Conceda só as operacións de esquema que a tarefa necesita. Converter un inicio de sesión remoto fallido nunha conta root, unha política de concedelo todo ou un host comodín xeral fai que a proba pase e elimina o control que estaba probando. O permiso que engadiu con présa é o que ninguén retira despois.
Volva probar cunha sesión nova pola ruta prevista e despois comprobe os casos negativos. Unha ruta que debería estar bloqueada debe seguir bloqueada, e unha operación que non se concedeu debe seguir denegada. Esas dúas comprobacións son o que separa unha conta reparada dunha ampliada.
Por último, rexistre a dirección de orixe observada e o nome da conta xuntos. O túnel proporciona alcanzabilidade; MariaDB segue elixindo e autorizando a súa propia conta, e a seguinte persoa necesita ambos os feitos para reproducir o seu resultado.