MariaDB via VPN: welke user@host ziet de server?

Typ dezelfde gebruikersnaam via twee verschillende paden en MariaDB kan je als twee verschillende accounts authenticeren. Accounts zijn gebaseerd op gebruiker en host samen, dus 'reporter'@'localhost' en 'reporter'@'10.90.0.23' zijn aparte rijen met aparte wachtwoorden en aparte rechten. Via een VPN is de interessante vraag niet welke naam de gebruiker typte, maar welk bronadres de server heeft gezien.

Bepaal de bron die de server werkelijk ziet

Werk terug vanaf de databasehost, niet vanaf de laptop. Het adres waarvan de client denkt dat hij het heeft, is slechts een van meerdere mogelijkheden:

Gebruik bewijs aan de serverkant om het te beslechten. Een verbindingslog, een lijst met actieve sessies of een tijdelijke regel in het algemene log tonen het adres dat de server heeft geaccepteerd. Het openbare IP van de laptop uit een browser is een ander feit en vaak misleidend.

Koppel het account dat MariaDB koos

Accountkeuze volgt een gedocumenteerde volgorde en niet een samenvoeging van rechten. Een exacte hostmatch gaat voor een jokerteken, en rijen van anonieme gebruikers doen op manieren mee aan de matching die mensen verrassen die aannemen dat de naam alleen beslist. De server kiest één rij; hij voegt niet de privileges van elke gelijknamige rij samen. De referentie één keer lezen is meer waard dan een middag gokken testen.

Dat betekent dat het toevoegen van een recht aan 'reporter'@'%' niets kan veranderen als de sessie zich als 'reporter'@'10.90.0.23' heeft geauthenticeerd. De reparatie moet op de rij landen die is gekozen, daarom komt het identificeren van het account vóór het bewerken van rechten.

Lees het account dat de sessie werkelijk gebruikt

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

CURRENT_USER() noemt het account dat de sessie heeft geauthenticeerd; USER() meldt wat de client vroeg en kan afwijken. Voer ze uit als gewone queries op het hoogste niveau, niet vanuit een opgeslagen routine met definer-context, anders beschrijven de antwoorden de eigenaar van de routine in plaats van je sessie.

Een mislukte login kan hier niets van uitvoeren, en dat is het geval waarin een beheerder de accountdefinities en het verbindingsbewijs van de server moet inspecteren. Plan daarvoor: de persoon die een geweigerde login debugt, heeft meestal geen SQL-sessie om in te vragen.

Scheid bereikbaarheid van authenticatie

De fouttekst vertelt je in welke laag je zit. Een geweigerde verbinding of een time-out betekent dat de client nooit een listener heeft bereikt, dus het account en het wachtwoord zijn nog niet in het geding. Een antwoord over geweigerde toegang betekent dat de server antwoordde, wat bereikbaarheid bewijst en wijst op het account, de hostmatch of de inloggegevens.

Netwerkvereisten zijn hun eigen lijst: een listener die aan het bedoelde adres is gebonden en niet alleen aan loopback, toegestaan verkeer naar de geconfigureerde poort en een retourroute voor het antwoord. Elk kan onafhankelijk falen, en een werkende tunnel impliceert geen van alle. Een listener op loopback accepteert lokale verbindingen en weigert elke externe, wat een geweigerde verbinding oplevert die op een firewallblokkade lijkt.

Controleer het bindadres voordat je een ticket bij het netwerkteam opent. ss -lntp op de databasehost toont welk adres en welke poort werkelijk luisteren, en die ene regel sluit een hele categorie gissingen uit.

Repareer smal en test daarna beide richtingen

Maak het bedoelde hostgekwalificeerde account aan via het goedgekeurde proces van de organisatie, met inloggegevens uit de ondersteunde opslag in plaats van een gedeelde die in een ticket is geplakt. Verleen alleen de schema-bewerkingen die de taak nodig heeft. Een mislukte externe login omzetten in een root-account, een alles-toestaan-beleid of een algemene jokerhost laat de test slagen en verwijdert de controle die je testte. Het recht dat je haastig toevoegde, is degene die niemand later verwijdert.

Test opnieuw met een verse sessie via het bedoelde pad en controleer daarna de negatieve gevallen. Een pad dat geblokkeerd zou moeten zijn, moet geblokkeerd blijven, en een bewerking die niet is verleend, moet geweigerd blijven. Die twee controles onderscheiden een gerepareerd account van een verruimd account.

Ten slotte leg je het waargenomen bronadres en de accountnaam samen vast. De tunnel levert bereikbaarheid; MariaDB kiest en autoriseert nog steeds zijn eigen account, en de volgende persoon heeft beide feiten nodig om je resultaat te reproduceren.