MariaDB VPN-i kaudu: millist user@host server näeb?

Sisestage sama kasutajanimi kahel erineval teel ja MariaDB võib teid autentida kahe erineva kontona. Kontod on võtmetatud kasutaja ja hosti järgi koos, seega 'reporter'@'localhost' ja 'reporter'@'10.90.0.23' on eraldi read eraldi paroolide ja eraldi õigustega. VPN-i kaudu ei ole huvitav küsimus see, millise nime kasutaja sisestas, vaid see, millist allikaaadressi server nägi.

Tehke kindlaks allikas, mida server tegelikult näeb

Töötage tagurpidi andmebaasi hostist, mitte sülearvutist. Aadress, mille klient arvab endal olevat, on vaid üks mitmest võimalusest:

Kasutage otsustamiseks serveripoolseid tõendeid. Ühenduslogi, aktiivsete sessioonide loend või ajutine kirje üldlogis näitab aadressi, mille server vastu võttis. Sülearvuti avalik IP brauserist on teine fakt ja sageli eksitav.

Sobitage konto, mille MariaDB valis

Konto valik järgib dokumenteeritud järjekorda, mitte õiguste ühendit. Täpne hosti vaste on metamärgist tähtsam ning anonüümse kasutaja read osalevad sobitamises viisil, mis üllatab inimesi, kes eeldavad, et otsustab üksi nimi. Server valib ühe rea; see ei ühenda iga samanimelise rea privileege. Viite üks kord lugemine on väärt rohkem kui terve pärastlõuna oletuste katsetamist.

See tähendab, et õiguse lisamine 'reporter'@'%'-le ei pruugi midagi muuta, kui sessioon autentiti kui 'reporter'@'10.90.0.23'. Parandus peab maanduma reale, mis valiti, seepärast tuleb konto tuvastamine enne õiguste muutmist.

Lugege konto, mida sessioon tegelikult kasutab

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

CURRENT_USER() nimetab konto, mis sessiooni autentis; USER() teatab, mida klient küsis, ja võib erineda. Käivitage neid tavaliste ülatasandi päringutena, mitte määraja kontekstiga salvestatud rutiini seest, muidu kirjeldavad vastused rutiini omanikku, mitte teie sessiooni.

Ebaõnnestunud sisselogimine ei saa neist ühtegi käivitada ja see on juhtum, kus administraator peab hoopis uurima kontode määratlusi ja serveri ühendustõendeid. Planeerige seda: tagasilükatud sisselogimist silujal tavaliselt SQL-sessiooni ei ole.

Eraldage kättesaadavus autentimisest

Veateade ütleb, millises kihis te olete. Tagasilükatud ühendus või aegumine tähendab, et klient ei jõudnud kunagi kuulajani, seega konto ja selle parool ei ole veel küsimuse all. Juurdepääsu keelamise vastus tähendab, et server vastas, mis tõestab kättesaadavust ja osutab kontole, hosti vastele või volitusele.

Võrgu eeldused on omaette loend: kuulaja, mis on seotud kavandatud aadressiga, mitte ainult loopbackiga, lubatud liiklus konfigureeritud pordile ja vastuse jaoks tagasitee. Igaüks võib iseseisvalt ebaõnnestuda ja töötav tunnel ei eelda neist ühtegi. Loopbacki kuulaja võtab vastu kohalikud ühendused ja lükkab tagasi iga kaugühenduse, mis tekitab tagasilükatud ühenduse, mis näeb välja nagu tulemüüri blokeering.

Kontrollige sidumisaadressi enne võrgumeeskonnale pileti avamist. ss -lntp andmebaasi hostis näitab, milline aadress ja port tegelikult kuulavad, ja see üks rida välistab terve oletuste kategooria.

Parandage kitsalt, seejärel testige mõlemas suunas

Looge kavandatud hostiga kvalifitseeritud konto organisatsiooni kinnitatud protsessi kaudu, volitusega toetatud hoidlast, mitte jagatud volitusega, mis on pileti sisse kleebitud. Andke ainult need skeemi toimingud, mida ülesanne vajab. Ebaõnnestunud kaugsisselogimise muutmine juurkontoks, kõigile lubamise poliitikaks või üldiseks metamärk-hostiks laseb testil läbida ja eemaldab kontrolli, mida te testisite. Kiirustades lisatud õigus on see, mida hiljem keegi ei eemalda.

Testige uuesti värske sessiooniga kavandatud teel ja seejärel kontrollige negatiivseid juhtumeid. Tee, mis peaks olema blokeeritud, peab jääma blokeerituks, ja toiming, mida ei antud, peab jääma keelatuks. Need kaks kontrolli eristavad parandatud kontot laiendatud kontost.

Lõpuks registreerige täheldatud allikaaadress ja konto nimi koos. Tunnel annab kättesaadavuse; MariaDB valib ja volitab endiselt oma konto ning järgmisel inimesel on tulemuse kordamiseks vaja mõlemat fakti.