MariaDB sa VPN: aling user@host ang nakikita ng server?

I-type ang parehong username mula sa dalawang magkaibang landas at maaaring i-authenticate ka ng MariaDB bilang dalawang magkaibang account. Ang mga account ay naka-key sa user at host nang magkasama, kaya ang 'reporter'@'localhost' at 'reporter'@'10.90.0.23' ay magkahiwalay na row na may magkahiwalay na password at magkahiwalay na pahintulot. Sa VPN, ang kawili-wiling tanong ay hindi kung aling pangalan ang itina-type ng user, kundi kung aling source address ang nakita ng server.

Tukuyin ang pinagmulan na talagang nakikita ng server

Magtrabaho pabalik mula sa host ng database, hindi sa laptop. Ang address na inaakala ng client na mayroon siya ay isa lamang sa ilang posibilidad:

Gumamit ng ebidensya sa panig ng server upang mapagpasyahan ito. Ang log ng koneksyon, listahan ng mga aktibong session, o pansamantalang entry sa pangkalahatang log ay nagpapakita ng address na tinanggap ng server. Ang pampublikong IP ng laptop mula sa browser ay ibang katotohanan at kadalasang nakalilinlang.

Itugma ang account na pinili ng MariaDB

Ang pagpili ng account ay sumusunod sa dokumentadong pagkakasunod-sunod at hindi sa pagsasama ng mga pahintulot. Ang eksaktong tugma ng host ay nauuna sa wildcard, at ang mga row ng anonymous na user ay lumalahok sa pagtutugma sa mga paraang nakakagulat sa mga nag-aakala na ang pangalan lamang ang nagpapasya. Pinipili ng server ang isang row; hindi nito pinagsasama ang mga pribilehiyo ng bawat row na may parehong pangalan. Ang pagbasa ng reference nang isang beses ay mas mahalaga kaysa sa isang hapon ng pagsubok ng haka-haka.

Nangangahulugan ito na ang pagdaragdag ng pahintulot sa 'reporter'@'%' ay maaaring walang mabago kung ang session ay nag-authenticate bilang 'reporter'@'10.90.0.23'. Dapat mapunta ang pagwawasto sa row na napili, kaya nauuna ang pagkilala sa account bago ang pag-edit ng mga pahintulot.

Basahin ang account na talagang ginagamit ng session

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

CURRENT_USER() ay pinangalanan ang account na nag-authenticate ng session; ang USER() ay nag-uulat ng hiniling ng client at maaaring magkaiba. Patakbuhin ang mga ito bilang ordinaryong query sa pinakamataas na antas, hindi mula sa loob ng nakaimbak na routine na may konteksto ng definer, kung hindi ay ilalarawan ng mga sagot ang may-ari ng routine sa halip na ang iyong session.

Ang nabigong pag-login ay hindi makakapagpatakbo ng anuman sa mga ito, at ito ang kaso kung saan kailangang suriin ng administrator ang mga depinisyon ng account at ang ebidensya ng koneksyon ng server. Planuhin iyon: ang taong nagde-debug ng tinanggihang login ay karaniwang walang SQL session na mapagtatanungan.

Paghiwalayin ang maabot mula sa authentication

Sinasabi ng teksto ng error kung aling layer ka. Ang tinanggihang koneksyon o timeout ay nangangahulugan na hindi kailanman naabot ng client ang isang listener, kaya ang account at ang password nito ay hindi pa pinag-uusapan. Ang sagot na tinanggihan ang pag-access ay nangangahulugan na sumagot ang server, na nagpapatunay ng maabot at tumuturo sa account, sa tugma ng host, o sa kredensyal.

Ang mga paunang kailangan ng network ay sarili nilang listahan: isang listener na nakatali sa nilalayong address at hindi lamang sa loopback, pinapayagang trapiko patungo sa naka-configure na port, at return route para sa sagot. Bawat isa ay maaaring mabigo nang mag-isa, at ang gumaganang tunnel ay hindi nagpapahiwatig ng alinman sa mga ito. Ang listener sa loopback ay tumatanggap ng lokal na koneksyon at tinatanggihan ang bawat malayong koneksyon, na gumagawa ng tinanggihang koneksyon na mukhang pagharang ng firewall.

Suriin ang bind address bago magbukas ng ticket sa network team. Ang ss -lntp sa host ng database ay nagpapakita kung aling address at port ang talagang nakikinig, at ang nag-iisang linyang iyon ay nag-aalis ng isang buong kategorya ng haka-haka.

Ayusin nang makitid, pagkatapos ay subukan muli ang dalawang direksyon

Gumawa ng nilalayong account na kwalipikado ng host sa pamamagitan ng aprubadong proseso ng organisasyon, na may kredensyal mula sa sinusuportahang tindahan sa halip na isang pinagsasaluhang nakadikit sa ticket. Magbigay lamang ng mga operasyon sa schema na kailangan ng gawain. Ang paggawa ng nabigong remote login na root account, patakaran ng ibigay-lahat, o pangkalahatang wildcard host ay nagpapapasa sa pagsubok at nag-aalis ng kontrol na sinusubukan mo. Ang pahintulot na idinagdag mo nang nagmamadali ang siyang walang nag-aalis mamaya.

Subukan muli gamit ang bagong session sa nilalayong landas, pagkatapos ay suriin ang mga negatibong kaso. Ang landas na dapat harangan ay dapat manatiling harangan, at ang operasyong hindi ibinigay ay dapat manatiling tinanggihan. Ang dalawang pagsusuring iyon ang naghihiwalay ng naayos na account mula sa pinalawak.

Sa huli, itala ang naobserbahang source address at ang pangalan ng account nang magkasama. Ang tunnel ay nagbibigay ng maabot; pinipili at pinapahintulutan pa rin ng MariaDB ang sarili nitong account, at kailangan ng susunod na tao ang dalawang katotohanan upang muling gawin ang iyong resulta.