MariaDB prin VPN: ce user@host vede serverul?

Tastați același nume de utilizator pe două căi diferite și MariaDB vă poate autentifica ca două conturi diferite. Conturile sunt cheiate pe utilizator și gazdă împreună, așa că 'reporter'@'localhost' și 'reporter'@'10.90.0.23' sunt rânduri separate cu parole separate și permisiuni separate. Printr-un VPN, întrebarea interesantă nu este ce nume a tastat utilizatorul, ci ce adresă sursă a văzut serverul.

Determinați sursa pe care serverul o vede efectiv

Lucrați invers de la gazda bazei de date, nu de la laptop. Adresa despre care clientul crede că o are este doar una dintre mai multe posibilități:

Folosiți dovezi din partea serverului pentru a decide. Un jurnal de conexiuni, o listă de sesiuni active sau o intrare temporară în jurnalul general arată adresa pe care serverul a acceptat-o. IP-ul public al laptopului dintr-un browser este un alt fapt și adesea înșelător.

Potriviți contul pe care MariaDB l-a selectat

Selecția contului urmează o ordine documentată, nu o uniune de permisiuni. O potrivire exactă a gazdei are prioritate față de un metacaracter, iar rândurile utilizatorului anonim participă la potrivire în moduri care îi surprind pe cei care presupun că doar numele decide. Serverul alege un singur rând; nu fuzionează privilegiile fiecărui rând cu același nume. Citirea referinței o dată valorează mai mult decât o după-amiază de încercat presupuneri.

Asta înseamnă că adăugarea unei permisiuni la 'reporter'@'%' poate să nu schimbe nimic dacă sesiunea s-a autentificat ca 'reporter'@'10.90.0.23'. Corecția trebuie să ajungă pe rândul care a fost selectat, de aceea identificarea contului precede editarea permisiunilor.

Citiți contul pe care sesiunea îl folosește efectiv

SELECT USER(), CURRENT_USER();
SHOW GRANTS;

CURRENT_USER() numește contul care a autentificat sesiunea; USER() raportează ce a cerut clientul și poate diferi. Executați-le ca interogări obișnuite de nivel superior, nu din interiorul unei rutine stocate cu context de definitor, altfel răspunsurile descriu proprietarul rutinei în locul sesiunii dvs.

O autentificare eșuată nu poate executa nimic din toate acestea, iar acesta este cazul în care un administrator trebuie să inspecteze definițiile conturilor și dovezile de conectare ale serverului. Planificați pentru asta: persoana care depanează o autentificare respinsă de obicei nu are nicio sesiune SQL în care să întrebe.

Separați accesibilitatea de autentificare

Textul erorii vă spune în ce strat sunteți. O conexiune refuzată sau un timeout înseamnă că clientul nu a ajuns niciodată la un ascultător, deci contul și parola lui nu sunt încă în discuție. Un răspuns de acces refuzat înseamnă că serverul a răspuns, ceea ce dovedește accesibilitatea și indică spre cont, potrivirea gazdei sau acreditarea.

Cerințele de rețea sunt o listă proprie: un ascultător legat de adresa dorită și nu doar de loopback, trafic permis către portul configurat și o rută de întoarcere pentru răspuns. Fiecare poate eșua independent, iar un tunel funcțional nu implică niciunul dintre ele. Un ascultător pe loopback acceptă conexiuni locale și refuză orice conexiune la distanță, ceea ce produce o conexiune refuzată care arată ca un blocaj de firewall.

Verificați adresa de legare înainte de a deschide un tichet la echipa de rețea. ss -lntp pe gazda bazei de date arată ce adresă și port ascultă efectiv, iar acea singură linie elimină o întreagă categorie de presupuneri.

Reparați îngust, apoi testați ambele direcții

Creați contul dorit calificat de gazdă prin procesul aprobat al organizației, cu o acreditare din depozitul acceptat, nu una partajată lipită într-un tichet. Acordați doar operațiile de schemă de care are nevoie sarcina. Transformarea unei autentificări la distanță eșuate într-un cont root, o politică de acordare totală sau o gazdă metacaracter generală face testul să treacă și elimină controlul pe care îl testați. Permisiunea adăugată în grabă este cea pe care nimeni nu o mai elimină.

Retestați cu o sesiune nouă pe calea dorită, apoi verificați cazurile negative. O cale care ar trebui blocată trebuie să rămână blocată, iar o operație care nu a fost acordată trebuie să rămână refuzată. Aceste două verificări separă un cont reparat de unul extins.

În final, înregistrați împreună adresa sursă observată și numele contului. Tunelul oferă accesibilitate; MariaDB încă își alege și își autorizează propriul cont, iar următoarea persoană are nevoie de ambele fapte pentru a reproduce rezultatul dvs.