MariaDB per VPN: quin user@host veu el servidor?
El compte es tria per usuari i host alhora. Trobeu l’origen que el servidor ha vist, llegiu CURRENT_USER() i després repareu aquella fila, no el permís.
Escriviu el mateix nom d’usuari des de dos camins diferents i MariaDB us pot autenticar com a dos comptes diferents. Els comptes es basen en l’usuari i l’host alhora, de manera que 'reporter'@'localhost' i 'reporter'@'10.90.0.23' són files separades amb contrasenyes separades i permisos separats. Per VPN, la pregunta interessant no és quin nom ha escrit l’usuari, sinó quina adreça d’origen ha vist el servidor.
Determineu l’origen que el servidor veu realment
Treballeu cap enrere des de l’host de la base de dades, no des del portàtil. L’adreça que el client creu que té només és una de diverses possibilitats:
| 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 |
Feu servir proves del costat del servidor per resoldre-ho. Un registre de connexions, una llista de sessions actives o una entrada temporal al registre general mostren l’adreça que el servidor ha acceptat. La IP pública del portàtil des d’un navegador és un fet diferent i sovint enganyós.
Emparelleu el compte que MariaDB ha seleccionat
La selecció del compte segueix un ordre documentat, no una unió de permisos. Una coincidència exacta d’host té prioritat sobre un comodí, i les files d’usuari anònim participen en la coincidència de maneres que sorprenen qui assumeix que el nom sol decideix. El servidor tria una fila; no fusiona els privilegis de cada fila amb un nom semblant. Llegir la referència una vegada val més que una tarda provant suposicions.
Això vol dir que afegir un permís a 'reporter'@'%' pot no canviar res si la sessió s’ha autenticat com a 'reporter'@'10.90.0.23'. La reparació ha de recaure en la fila que s’ha seleccionat, i per això identificar el compte va abans d’editar permisos.
Llegiu el compte que la sessió fa servir realment
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() anomena el compte que ha autenticat la sessió; USER() informa del que el client ha demanat i pot diferir. Executeu-les com a consultes normals de primer nivell, no des de dins d’una rutina emmagatzemada amb context de definidor, o les respostes descriuran el propietari de la rutina en lloc de la vostra sessió.
Una entrada fallida no pot executar res d’això, i aquest és el cas en què un administrador ha d’inspeccionar les definicions dels comptes i les proves de connexió del servidor. Planifiqueu-ho: qui depura una entrada rebutjada normalment no té cap sessió SQL per consultar.
Separeu l’abastabilitat de l’autenticació
El text de l’error us diu en quina capa sou. Una connexió refusada o un temps d’espera esgotat vol dir que el client no ha arribat mai a un oient, així que el compte i la seva contrasenya encara no estan en qüestió. Una resposta d’accés denegat vol dir que el servidor ha respost, cosa que demostra abastabilitat i apunta al compte, a la coincidència d’host o a la credencial.
Els requisits de xarxa són una llista pròpia: un oient lligat a l’adreça prevista i no només al loopback, trànsit permès cap al port configurat i una ruta de tornada per a la resposta. Cadascun pot fallar de manera independent, i un túnel que funciona no implica cap d’ells. Un oient al loopback accepta connexions locals i refusa totes les remotes, cosa que produeix una connexió refusada que sembla un bloqueig de tallafoc.
Comproveu l’adreça d’enllaç abans d’obrir un tiquet a l’equip de xarxa. ss -lntp a l’host de la base de dades mostra quina adreça i quin port estan realment escoltant, i aquesta sola línia descarta tota una categoria de suposicions.
Repareu de manera estreta i torneu a provar les dues direccions
Creeu el compte previst qualificat per host mitjançant el procés aprovat de l’organització, amb una credencial del magatzem suportat i no una de compartida enganxada en un tiquet. Concediu només les operacions d’esquema que la tasca necessita. Convertir una entrada remota fallida en un compte root, una política de concedir-ho tot o un host comodí general fa passar la prova i elimina el control que estàveu provant. El permís que heu afegit de pressa és el que ningú no retira després.
Torneu a provar amb una sessió nova pel camí previst i després comproveu els casos negatius. Un camí que hauria d’estar bloquejat ha de continuar bloquejat, i una operació que no s’ha concedit ha de continuar denegada. Aquestes dues comprovacions són el que separa un compte reparat d’un compte ampliat.
Finalment, anoteu l’adreça d’origen observada i el nom del compte junts. El túnel proporciona abastabilitat; MariaDB continua triant i autoritzant el seu propi compte, i la propera persona necessita tots dos fets per reproduir el vostre resultat.