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 все още избира и оторизира собствения си акаунт, а следващият човек се нуждае от двата факта, за да възпроизведе резултата ви.