MariaDB přes VPN: který user@host server vidí?

Zadejte stejné uživatelské jméno ze dvou různých cest a MariaDB vás může ověřit jako dva různé účty. Účty se klíčují podle uživatele a hostitele společně, takže 'reporter'@'localhost' a 'reporter'@'10.90.0.23' jsou samostatné řádky se samostatnými hesly a samostatnými granty. Přes VPN není zajímavá otázka, jaké jméno uživatel zadal, ale kterou zdrojovou adresu server viděl.

Určete zdroj, který server skutečně vidí

Postupujte zpětně od hostitele databáze, ne od notebooku. Adresa, o které si klient myslí, že ji má, je jen jedna z několika možností:

K rozhodnutí použijte důkazy na straně serveru. Protokol připojení, seznam aktivních relací nebo dočasný záznam v obecném protokolu ukazuje adresu, kterou server přijal. Veřejná IP notebooku z prohlížeče je jiný fakt a často zavádějící.

Spojte účet, který MariaDB vybrala

Výběr účtu se řídí dokumentovaným pořadím, nikoli sjednocením grantů. Přesná shoda hostitele má přednost před zástupným znakem a řádky anonymního uživatele se účastní párování způsoby, které překvapí ty, kdo předpokládají, že rozhoduje samo jméno. Server vybere jeden řádek; neslučuje oprávnění všech stejnojmenných řádků. Přečíst referenci jednou má větší cenu než odpoledne zkoušení odhadů.

To znamená, že přidání grantu na 'reporter'@'%' nemusí nic změnit, pokud se relace ověřila jako 'reporter'@'10.90.0.23'. Oprava musí dopadnout na řádek, který byl vybrán, a proto identifikace účtu předchází úpravě grantů.

Přečtěte účet, který relace skutečně používá

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

CURRENT_USER() pojmenovává účet, který relaci ověřil; USER() hlásí, co klient požadoval, a může se lišit. Spouštějte je jako běžné dotazy nejvyšší úrovně, ne z uložené rutiny s kontextem definujícího uživatele, jinak odpovědi popisují vlastníka rutiny místo vaší relace.

Neúspěšné přihlášení nemůže nic z toho spustit, a to je případ, kdy musí správce prozkoumat definice účtů a důkazy o připojení na serveru. Počítejte s tím: člověk ladící odmítnuté přihlášení obvykle nemá žádnou SQL relaci k dotazování.

Oddělte dostupnost od autentizace

Text chyby vám říká, ve které vrstvě jste. Odmítnuté připojení nebo vypršení času znamená, že klient nikdy nedosáhl posluchače, takže účet a jeho heslo zatím nejsou ve hře. Odpověď o odepřeném přístupu znamená, že server odpověděl, což dokazuje dostupnost a ukazuje na účet, shodu hostitele nebo přihlašovací údaj.

Síťové předpoklady jsou samostatný seznam: posluchač vázaný na zamýšlenou adresu, ne jen na loopback, povolený provoz na nakonfigurovaný port a zpětná trasa pro odpověď. Každý může selhat nezávisle a fungující tunel neznamená žádný z nich. Posluchač na loopbacku přijímá místní připojení a odmítá každé vzdálené, což vytváří odmítnuté připojení, které vypadá jako blokace firewallem.

Zkontrolujte adresu vazby, než otevřete tiket síťovému týmu. ss -lntp na hostiteli databáze ukazuje, která adresa a port skutečně naslouchají, a ten jediný řádek vylučuje celou kategorii odhadů.

Opravujte úzce, pak otestujte oba směry

Vytvořte zamýšlený účet kvalifikovaný hostitelem schváleným procesem organizace, s přihlašovacím údajem z podporovaného úložiště, nikoli sdíleným vloženým do tiketu. Udělte jen operace se schématem, které úkol potřebuje. Přeměna neúspěšného vzdáleného přihlášení na root účet, politiku udělení všeho nebo plošný zástupný hostitel nechá test projít a odstraní kontrolu, kterou jste testovali. Grant, který jste přidali ve spěchu, je ten, který později nikdo neodebere.

Otestujte znovu s čerstvou relací zamýšlenou cestou a pak zkontrolujte negativní případy. Cesta, která má být blokována, musí zůstat blokována, a operace, která nebyla udělena, musí zůstat odepřena. Tyto dvě kontroly odlišují opravený účet od rozšířeného.

Nakonec zaznamenejte pozorovanou zdrojovou adresu a jméno účtu společně. Tunel poskytuje dostupnost; MariaDB stále volí a autorizuje svůj vlastní účet a další člověk potřebuje oba fakty, aby reprodukoval váš výsledek.