MariaDB über VPN: Welches user@host sieht der Server?

Geben Sie denselben Benutzernamen über zwei verschiedene Wege ein, und MariaDB authentifiziert Sie möglicherweise als zwei verschiedene Konten. Konten sind auf Benutzer und Host gemeinsam geschlüsselt, daher sind 'reporter'@'localhost' und 'reporter'@'10.90.0.23' getrennte Zeilen mit getrennten Passwörtern und getrennten Grants. Über ein VPN ist die interessante Frage nicht, welchen Namen der Benutzer eingegeben hat, sondern welche Quelladresse der Server gesehen hat.

Bestimmen Sie die Quelle, die der Server tatsächlich sieht

Arbeiten Sie rückwärts vom Datenbankhost, nicht vom Laptop. Die Adresse, die der Client zu haben glaubt, ist nur eine von mehreren Möglichkeiten:

Nutzen Sie serverseitige Belege, um das zu klären. Ein Verbindungsprotokoll, eine Liste aktiver Sitzungen oder ein temporärer Eintrag im allgemeinen Protokoll zeigt die Adresse, die der Server akzeptiert hat. Die öffentliche IP des Laptops aus einem Browser ist eine andere Tatsache und oft irreführend.

Ordnen Sie das Konto zu, das MariaDB ausgewählt hat

Die Kontoauswahl folgt einer dokumentierten Reihenfolge und nicht einer Vereinigung von Grants. Eine exakte Host-Übereinstimmung hat Vorrang vor einem Platzhalter, und Zeilen anonymer Benutzer nehmen an der Zuordnung auf Weisen teil, die Menschen überraschen, die annehmen, der Name allein entscheide. Der Server wählt eine Zeile; er führt nicht die Privilegien jeder gleichnamigen Zeile zusammen. Die Referenz einmal zu lesen ist mehr wert als ein Nachmittag voller Vermutungen.

Das heißt, das Hinzufügen eines Grants zu 'reporter'@'%' ändert möglicherweise nichts, wenn sich die Sitzung als 'reporter'@'10.90.0.23' authentifiziert hat. Die Korrektur muss auf der Zeile landen, die ausgewählt wurde, deshalb kommt die Identifizierung des Kontos vor dem Bearbeiten von Grants.

Lesen Sie das Konto, das die Sitzung tatsächlich verwendet

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

CURRENT_USER() benennt das Konto, das die Sitzung authentifiziert hat; USER() meldet, was der Client angefordert hat, und kann abweichen. Führen Sie diese als gewöhnliche Abfragen auf oberster Ebene aus, nicht aus einer gespeicherten Routine mit Definer-Kontext, sonst beschreiben die Antworten den Besitzer der Routine statt Ihrer Sitzung.

Eine fehlgeschlagene Anmeldung kann nichts davon ausführen, und das ist der Fall, in dem ein Administrator stattdessen die Kontodefinitionen und die Verbindungsbelege des Servers prüfen muss. Planen Sie das ein: Die Person, die eine abgelehnte Anmeldung debuggt, hat normalerweise keine SQL-Sitzung zum Abfragen.

Trennen Sie Erreichbarkeit von Authentifizierung

Der Fehlertext sagt Ihnen, in welcher Schicht Sie sich befinden. Eine abgelehnte Verbindung oder ein Timeout bedeutet, dass der Client nie einen Listener erreicht hat, das Konto und sein Passwort stehen also noch nicht in Frage. Eine Antwort über verweigerten Zugriff bedeutet, dass der Server geantwortet hat, was Erreichbarkeit beweist und auf das Konto, die Host-Übereinstimmung oder die Anmeldedaten zeigt.

Netzwerkvoraussetzungen sind ihre eigene Liste: ein Listener, der an die beabsichtigte Adresse gebunden ist und nicht nur an Loopback, erlaubter Datenverkehr zum konfigurierten Port und eine Rückroute für die Antwort. Jede kann unabhängig fehlschlagen, und ein funktionierender Tunnel impliziert keine davon. Ein Listener auf Loopback akzeptiert lokale Verbindungen und weist jede entfernte ab, was eine abgelehnte Verbindung erzeugt, die wie eine Firewallblockade aussieht.

Prüfen Sie die Bind-Adresse, bevor Sie ein Ticket beim Netzwerkteam eröffnen. ss -lntp auf dem Datenbankhost zeigt, welche Adresse und welcher Port tatsächlich lauschen, und diese eine Zeile schließt eine ganze Kategorie von Vermutungen aus.

Eng reparieren, dann beide Richtungen erneut testen

Erstellen Sie das beabsichtigte hostqualifizierte Konto über den genehmigten Prozess der Organisation, mit einem Anmeldedatum aus dem unterstützten Speicher statt einem geteilten, das in ein Ticket eingefügt wurde. Gewähren Sie nur die Schemaoperationen, die die Aufgabe benötigt. Eine fehlgeschlagene Remote-Anmeldung in ein Root-Konto, eine Alles-gewähren-Richtlinie oder einen pauschalen Platzhalter-Host zu verwandeln, lässt den Test bestehen und entfernt die Kontrolle, die Sie getestet haben. Der Grant, den Sie in Eile hinzugefügt haben, ist der, den später niemand entfernt.

Testen Sie mit einer frischen Sitzung über den beabsichtigten Weg erneut und prüfen Sie dann die Negativfälle. Ein Weg, der blockiert sein sollte, muss weiterhin blockiert sein, und eine Operation, die nicht gewährt wurde, muss weiterhin verweigert werden. Diese beiden Prüfungen unterscheiden ein repariertes Konto von einem erweiterten.

Zum Schluss halten Sie die beobachtete Quelladresse und den Kontonamen zusammen fest. Der Tunnel liefert Erreichbarkeit; MariaDB wählt und autorisiert weiterhin sein eigenes Konto, und die nächste Person braucht beide Fakten, um Ihr Ergebnis zu reproduzieren.