MariaDB przez VPN: który user@host widzi serwer?
Konto jest wybierane według użytkownika i hosta razem. Znajdź źródło, które zobaczył serwer, odczytaj CURRENT_USER() i napraw ten wiersz, a nie uprawnienie.
Wpisz tę samą nazwę użytkownika dwiema różnymi drogami, a MariaDB może uwierzytelnić cię jako dwa różne konta. Konta są oparte na użytkowniku i hoście razem, więc 'reporter'@'localhost' i 'reporter'@'10.90.0.23' to osobne wiersze z osobnymi hasłami i osobnymi uprawnieniami. Przez VPN interesującym pytaniem nie jest to, jaką nazwę wpisał użytkownik, ale jaki adres źródłowy zobaczył serwer.
Ustal źródło, które serwer naprawdę widzi
Pracuj wstecz od hosta bazy danych, a nie od laptopa. Adres, który klient uważa, że ma, jest tylko jedną z kilku możliwości:
| 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 |
Użyj dowodów po stronie serwera, aby to rozstrzygnąć. Dziennik połączeń, lista aktywnych sesji lub tymczasowy wpis w dzienniku ogólnym pokazują adres, który serwer zaakceptował. Publiczny adres IP laptopa widziany z przeglądarki to inny fakt i często mylący.
Dopasuj konto, które wybrała MariaDB
Wybór konta przebiega według udokumentowanej kolejności, a nie sumy uprawnień. Dokładne dopasowanie hosta ma pierwszeństwo przed znakiem wieloznacznym, a wiersze anonimowego użytkownika uczestniczą w dopasowaniu w sposób, który zaskakuje ludzi zakładających, że decyduje sama nazwa. Serwer wybiera jeden wiersz; nie scala uprawnień każdego wiersza o tej samej nazwie. Jedno przeczytanie dokumentacji jest warte więcej niż popołudnie prób i domysłów.
Oznacza to, że dodanie uprawnienia do 'reporter'@'%' może nic nie zmienić, jeśli sesja uwierzytelniła się jako 'reporter'@'10.90.0.23'. Poprawka musi trafić w wiersz, który został wybrany, dlatego identyfikacja konta poprzedza edycję uprawnień.
Odczytaj konto, którego sesja naprawdę używa
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() wskazuje konto, które uwierzytelniło sesję; USER() zgłasza, o co prosił klient, i może się różnić. Uruchamiaj je jako zwykłe zapytania najwyższego poziomu, a nie z wnętrza procedury składowanej z kontekstem definiującego, w przeciwnym razie odpowiedzi opiszą właściciela procedury zamiast twojej sesji.
Nieudane logowanie nie może wykonać niczego z tego i właśnie wtedy administrator musi sprawdzić definicje kont oraz dowody połączenia serwera. Zaplanuj to: osoba debugująca odrzucone logowanie zwykle nie ma sesji SQL do odpytywania.
Oddziel osiągalność od uwierzytelniania
Tekst błędu mówi, w której warstwie jesteś. Odrzucone połączenie lub przekroczenie limitu czasu oznacza, że klient nigdy nie dotarł do nasłuchu, więc konto i jego hasło nie są jeszcze w grze. Odpowiedź o odmowie dostępu oznacza, że serwer odpowiedział, co dowodzi osiągalności i wskazuje na konto, dopasowanie hosta lub poświadczenie.
Wymagania sieciowe to osobna lista: nasłuch powiązany z zamierzonym adresem, a nie tylko z loopbackiem, dozwolony ruch do skonfigurowanego portu i trasa powrotna dla odpowiedzi. Każdy z nich może zawieść niezależnie, a działający tunel nie implikuje żadnego z nich. Nasłuch na loopbacku akceptuje połączenia lokalne i odrzuca każde zdalne, co daje odrzucone połączenie wyglądające jak blokada zapory.
Sprawdź adres powiązania, zanim otworzysz zgłoszenie do zespołu sieciowego. ss -lntp na hoście bazy danych pokazuje, który adres i port naprawdę nasłuchują, i ta jedna linia wyklucza całą kategorię domysłów.
Napraw wąsko, a potem przetestuj oba kierunki
Utwórz zamierzone konto kwalifikowane hostem przez zatwierdzony proces organizacji, z poświadczeniem z obsługiwanego magazynu, a nie współdzielonym wklejonym do zgłoszenia. Przyznaj tylko te operacje na schemacie, których wymaga zadanie. Zamiana nieudanego zdalnego logowania w konto root, politykę przydzielania wszystkiego lub ogólny host wieloznaczny sprawia, że test przechodzi, i usuwa kontrolę, którą testowałeś. Uprawnienie dodane w pośpiechu jest tym, którego nikt później nie usuwa.
Przetestuj ponownie ze świeżą sesją zamierzoną drogą, a następnie sprawdź przypadki negatywne. Droga, która powinna być zablokowana, musi pozostać zablokowana, a operacja, której nie przyznano, musi pozostać odrzucona. Te dwa sprawdzenia odróżniają konto naprawione od rozszerzonego.
Na koniec zapisz zaobserwowany adres źródłowy i nazwę konta razem. Tunel zapewnia osiągalność; MariaDB nadal wybiera i autoryzuje własne konto, a następna osoba potrzebuje obu faktów, aby odtworzyć twój wynik.