MariaDB över VPN: vilken user@host ser servern?
Kontot väljs av användare och värd tillsammans. Hitta källan som servern såg, läs CURRENT_USER() och reparera sedan den raden, inte tilldelningen.
Skriv samma användarnamn via två olika vägar och MariaDB kan autentisera dig som två olika konton. Konton är nycklade på användare och värd tillsammans, så 'reporter'@'localhost' och 'reporter'@'10.90.0.23' är separata rader med separata lösenord och separata behörigheter. Över en VPN är den intressanta frågan inte vilket namn användaren skrev, utan vilken källadress servern såg.
Bestäm källan som servern faktiskt ser
Arbeta baklänges från databasvärden, inte från den bärbara datorn. Adressen som klienten tror sig ha är bara en av flera möjligheter:
| 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 |
Använd bevis från serversidan för att avgöra det. En anslutningslogg, en lista över aktiva sessioner eller en tillfällig post i den allmänna loggen visar adressen som servern accepterade. Den bärbara datorns publika IP från en webbläsare är ett annat faktum och ofta missvisande.
Matcha kontot som MariaDB valde
Kontovalet följer en dokumenterad ordning och inte en förening av tilldelningar. En exakt värdmatchning går före ett jokertecken, och rader med anonym användare deltar i matchningen på sätt som överraskar folk som antar att namnet ensamt avgör. Servern väljer en rad; den slår inte ihop privilegierna för varje likanamnad rad. Att läsa referensen en gång är värt mer än en eftermiddag med gissningar.
Det betyder att det att lägga till en tilldelning på 'reporter'@'%' kanske inte ändrar något om sessionen autentiserade sig som 'reporter'@'10.90.0.23'. Rättelsen måste landa på raden som valdes, därför kommer identifieringen av kontot före redigering av tilldelningar.
Läs kontot som sessionen faktiskt använder
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() namnger kontot som autentiserade sessionen; USER() rapporterar vad klienten begärde och kan skilja sig. Kör dem som vanliga frågor på översta nivån, inte inifrån en lagrad rutin med definierande kontext, annars beskriver svaren rutinens ägare i stället för din session.
En misslyckad inloggning kan inte köra något av detta, och det är fallet där en administratör måste granska kontodefinitionerna och serverns anslutningsbevis i stället. Planera för det: personen som felsöker en avvisad inloggning har vanligtvis ingen SQL-session att fråga i.
Skilj nåbarhet från autentisering
Feltexten säger vilket lager du är i. En avvisad anslutning eller en timeout betyder att klienten aldrig nådde en lyssnare, så kontot och lösenordet är ännu inte i fråga. Ett svar om nekad åtkomst betyder att servern svarade, vilket bevisar nåbarhet och pekar på kontot, värdmatchningen eller autentiseringsuppgiften.
Nätverksförutsättningarna är sin egen lista: en lyssnare bunden till den avsedda adressen och inte bara till loopback, tillåten trafik till den konfigurerade porten och en returväg för svaret. Var och en kan misslyckas oberoende, och en fungerande tunnel innebär ingen av dem. En lyssnare på loopback accepterar lokala anslutningar och avvisar varje fjärranslutning, vilket ger en avvisad anslutning som ser ut som en brandväggsblockering.
Kontrollera bindningsadressen innan du öppnar ett ärende hos nätverksteamet. ss -lntp på databasvärden visar vilken adress och port som faktiskt lyssnar, och den enda raden utesluter en hel kategori av gissningar.
Reparera snävt och testa sedan båda riktningarna
Skapa det avsedda värdkvalificerade kontot genom organisationens godkända process, med en autentiseringsuppgift från den stödda lagringen i stället för en delad som klistrats in i ett ärende. Bevilja bara de schemaoperationer som uppgiften behöver. Att göra en misslyckad fjärrinloggning till ett root-konto, en ge-allt-policy eller en generell jokerteckenvärd får testet att passera och tar bort den kontroll du testade. Den tilldelning du lade till i hast är den som ingen tar bort senare.
Testa igen med en färsk session via den avsedda vägen och kontrollera sedan de negativa fallen. En väg som ska vara blockerad måste förbli blockerad, och en operation som inte beviljades måste förbli nekad. Dessa två kontroller skiljer ett reparerat konto från ett utökat.
Slutligen registrerar du den observerade källadressen och kontonamnet tillsammans. Tunneln ger nåbarhet; MariaDB väljer och auktoriserar fortfarande sitt eget konto, och nästa person behöver båda fakta för att återskapa ditt resultat.