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 па-ранейшаму выбірае і аўтарызуе ўласны ўліковы запіс, а наступнаму чалавеку патрэбны абодва факты, каб узнавіць ваш вынік.