MariaDB преко VPN-а: који user@host види сервер?

Укуцајте исто корисничко име са два различита пута и MariaDB вас може аутентификовати као два различита налога. Налози се везују за корисника и хост заједно, па су 'reporter'@'localhost' и 'reporter'@'10.90.0.23' одвојени редови са одвојеним лозинкама и одвојеним дозволама. Преко VPN-а занимљиво питање није које је име корисник укуцао, него коју је изворну адресу сервер видео.

Утврдите извор који сервер заиста види

Радите уназад од хоста базе података, а не од лаптопа. Адреса за коју клијент мисли да је има само је једна од неколико могућности:

Употребите доказе са стране сервера да то решите. Дневник веза, листа активних сесија или привремени унос у општем дневнику показује адресу коју је сервер прихватио. Јавна IP адреса лаптопа из прегледача је друга чињеница и често обмањујућа.

Упарите налог који је MariaDB одабрао

Избор налога следи документовани поредак, а не унију дозвола. Тачно подударање хоста има предност пред џокер знаком, а редови анонимног корисника учествују у подударању на начине који изненађују људе који претпостављају да само име одлучује. Сервер бира један ред; не спаја привилегије сваког истоименог реда. Једно читање референце вреди више од поподнева тестирања нагађања.

То значи да додавање дозволе на 'reporter'@'%' можда ништа не мења ако се сесија аутентификовала као 'reporter'@'10.90.0.23'. Поправка мора пасти на ред који је одабран, зато идентификација налога долази пре уређивања дозвола.

Прочитајте налог који сесија заиста користи

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

CURRENT_USER() именује налог који је аутентификовао сесију; USER() извештава шта је клијент тражио и може се разликовати. Извршите их као обичне упите највишег нивоа, а не из сачуване рутине са контекстом дефинишућег корисника, иначе одговори описују власника рутине уместо ваше сесије.

Неуспешна пријава не може извршити ништа од овога, а то је случај када администратор мора прегледати дефиниције налога и доказе о везама на серверу. Планирајте то: особа која отклања грешку одбијене пријаве обично нема SQL сесију за упите.

Одвојите доступност од аутентификације

Текст грешке вам каже на ком сте слоју. Одбијена веза или истек времена значи да клијент никада није стигао до слушаоца, па налог и његова лозинка још нису упитни. Одговор о одбијеном приступу значи да је сервер одговорио, што доказује доступност и упућује на налог, подударање хоста или акредитив.

Мрежни предуслови су посебан списак: слушалац везан на предвиђену адресу, а не само на loopback, дозвољен саобраћај на конфигурисани порт и повратна рута за одговор. Сваки може независно да падне, а тунел који ради не подразумева ниједан од њих. Слушалац на loopback-у прихвата локалне везе и одбија сваку удаљену, што ствара одбијену везу која изгледа као блокада ватрозида.

Проверите адресу везивања пре него што отворите тикет мрежном тиму. ss -lntp на хосту базе података показује која адреса и порт заиста слушају, а тај један ред искључује целу категорију нагађања.

Поправите уско, па поново тестирајте у оба смера

Направите предвиђени налог квалификован хостом кроз одобрени процес организације, са акредитивом из подржаног складишта, а не заједничким залепљеним у тикет. Доделите само операције над шемом које задатак тражи. Претварање неуспешне удаљене пријаве у root налог, политику доделе свега или широки џокер хост чини да тест прође и уклања контролу коју сте тестирали. Дозвола коју сте додали у журби је она коју касније нико не уклања.

Поново тестирајте са свежом сесијом кроз предвиђени пут, па проверите негативне случајеве. Пут који треба бити блокиран мора остати блокиран, а операција која није додељена мора остати одбијена. Те две провере разликују поправљен налог од проширеног.

На крају, забележите уочену изворну адресу и име налога заједно. Тунел даје доступност; MariaDB и даље бира и ауторизује сопствени налог, а следећој особи требају обе чињенице да репродукује ваш резултат.