MariaDB через VPN: який user@host бачить сервер?
Обліковий запис вибирається за користувачем і хостом разом. Знайдіть джерело, яке побачив сервер, прочитайте CURRENT_USER() і потім виправте той рядок, а не привілей.
Введіть те саме ім'я користувача двома різними шляхами, і MariaDB може автентифікувати вас як два різні облікові записи. Записи прив'язані до користувача й хоста разом, тому 'reporter'@'localhost' і 'reporter'@'10.90.0.23' — окремі рядки з окремими паролями й окремими привілеями. Через VPN цікаве питання не в тому, яке ім'я ввів користувач, а в тому, яку адресу джерела побачив сервер.
Визначте джерело, яке сервер справді бачить
Працюйте у зворотному напрямку від хоста бази даних, а не від ноутбука. Адреса, яку клієнт вважає своєю, — лише один із кількох варіантів:
| 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 |
Використовуйте докази на боці сервера, щоб це вирішити. Журнал з'єднань, список активних сеансів або тимчасовий запис у загальному журналі показують адресу, яку сервер прийняв. Публічна IP-адреса ноутбука з браузера — інший факт і часто оманливий.
Зіставте обліковий запис, який вибрала MariaDB
Вибір запису дотримується задокументованого порядку, а не об'єднання привілеїв. Точний збіг хоста має пріоритет перед шаблонним знаком, а рядки анонімного користувача беруть участь у зіставленні так, що це дивує тих, хто вважає, що вирішує саме ім'я. Сервер вибирає один рядок; він не об'єднує привілеї кожного однойменного рядка. Прочитати довідку один раз цінніше, ніж півдня перебирати здогадки.
Це означає, що додавання привілею до 'reporter'@'%' може нічого не змінити, якщо сеанс автентифікувався як 'reporter'@'10.90.0.23'. Виправлення має потрапити в той рядок, який було вибрано, тому ідентифікація запису передує редагуванню привілеїв.
Прочитайте запис, який сеанс справді використовує
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() називає запис, що автентифікував сеанс; USER() повідомляє, що запросив клієнт, і може відрізнятися. Виконуйте їх як звичайні запити верхнього рівня, а не зсередини збереженої процедури з контекстом визначника, інакше відповіді опишуть власника процедури, а не ваш сеанс.
Невдалий вхід не може виконати нічого з цього, і це той випадок, коли адміністратор має перевірити визначення записів і докази з'єднання сервера. Плануйте це: людина, яка налагоджує відхилений вхід, зазвичай не має SQL-сеансу, щоб запитати.
Відокремте доступність від автентифікації
Текст помилки говорить, на якому рівні ви перебуваєте. Відмова в з'єднанні або тайм-аут означає, що клієнт так і не досяг слухача, тому запис і його пароль ще не під питанням. Відповідь про відмову в доступі означає, що сервер відповів, що доводить доступність і вказує на запис, збіг хоста або облікові дані.
Мережеві передумови — окремий список: слухач, прив'язаний до потрібної адреси, а не лише до loopback, дозволений трафік на налаштований порт і зворотний маршрут для відповіді. Кожен може відмовити незалежно, і робочий тунель не передбачає жодного з них. Слухач на loopback приймає локальні з'єднання й відхиляє кожне віддалене, що дає відмову в з'єднанні, схожу на блокування брандмауера.
Перевірте адресу прив'язки, перш ніж відкривати заявку мережевій команді. ss -lntp на хості бази даних показує, яка адреса й порт справді слухають, і цей один рядок виключає цілу категорію здогадок.
Виправляйте точково, потім перевірте обидва напрямки
Створіть потрібний запис, кваліфікований хостом, через затверджений процес організації, з обліковими даними з підтримуваного сховища, а не спільними, вставленими в заявку. Надайте лише ті операції зі схемою, які потрібні завданню. Перетворення невдалого віддаленого входу на root-запис, політику надання всього або загальний шаблонний хост змушує тест пройти й прибирає контроль, який ви перевіряли. Привілей, доданий поспіхом, — той, який потім ніхто не видаляє.
Повторіть перевірку з новим сеансом потрібним шляхом, потім перевірте негативні випадки. Шлях, який має бути заблокований, має залишитися заблокованим, а операція, яку не було надано, має залишитися забороненою. Ці дві перевірки відрізняють виправлений запис від розширеного.
Нарешті, запишіть спостережувану адресу джерела та ім'я запису разом. Тунель забезпечує доступність; MariaDB і далі вибирає й авторизує власний запис, а наступній людині потрібні обидва факти, щоб відтворити ваш результат.