MariaDB preko VPN-a: koji user@host vidi server?

Ukucajte isto korisničko ime sa dva različita puta i MariaDB vas može autentifikovati kao dva različita računa. Računi se vezuju za korisnika i host zajedno, pa su 'reporter'@'localhost' i 'reporter'@'10.90.0.23' odvojeni redovi s odvojenim lozinkama i odvojenim grantovima. Preko VPN-a zanimljivo pitanje nije koje je ime korisnik ukucao, nego koju je izvornu adresu server vidio.

Utvrdite izvor koji server zaista vidi

Radite unatrag od hosta baze podataka, a ne od laptopa. Adresa za koju klijent misli da je ima samo je jedna od nekoliko mogućnosti:

Upotrijebite dokaze sa strane servera da to riješite. Dnevnik veza, popis aktivnih sesija ili privremeni unos u općem dnevniku pokazuje adresu koju je server prihvatio. Javna IP adresa laptopa iz preglednika druga je činjenica i često obmanjujuća.

Uparite račun koji je MariaDB odabrao

Odabir računa slijedi dokumentirani poredak, a ne uniju grantova. Točno podudaranje hosta ima prednost pred džoker znakom, a redovi anonimnog korisnika sudjeluju u podudaranju na načine koji iznenađuju ljude koji pretpostavljaju da samo ime odlučuje. Server bira jedan red; ne spaja privilegije svakog istoimenog reda. Jedno čitanje referencije vrijedi više od popodneva testiranja nagađanja.

To znači da dodavanje granta na 'reporter'@'%' možda ništa ne mijenja ako se sesija autentifikovala kao 'reporter'@'10.90.0.23'. Popravka mora pasti na red koji je odabran, zato identifikacija računa dolazi prije uređivanja grantova.

Pročitajte račun koji sesija zaista koristi

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

CURRENT_USER() imenuje račun koji je autentifikovao sesiju; USER() izvještava šta je klijent tražio i može se razlikovati. Izvršite ih kao obične upite najvišeg nivoa, a ne iz pohranjene rutine s kontekstom definirajućeg korisnika, inače odgovori opisuju vlasnika rutine umjesto vaše sesije.

Neuspjela prijava ne može izvršiti ništa od ovoga, a to je slučaj kada administrator mora pregledati definicije računa i dokaze o vezama na serveru. Planirajte to: osoba koja otklanja grešku odbijene prijave obično nema SQL sesiju za upite.

Odvojite dostupnost od autentifikacije

Tekst greške vam kaže na kojem ste sloju. Odbijena veza ili istek vremena znači da klijent nikada nije stigao do slušača, pa račun i njegova lozinka još nisu upitni. Odgovor o odbijenom pristupu znači da je server odgovorio, što dokazuje dostupnost i upućuje na račun, podudaranje hosta ili akreditiv.

Mrežni preduslovi su zaseban popis: slušač vezan na predviđenu adresu, a ne samo na loopback, dozvoljen saobraćaj na konfigurisani port i povratna ruta za odgovor. Svaki može nezavisno pasti, a tunel koji radi ne podrazumijeva nijedan od njih. Slušač na loopbacku prihvata lokalne veze i odbija svaku udaljenu, što stvara odbijenu vezu koja izgleda kao blokada vatrozida.

Provjerite bind adresu prije nego otvorite tiket mrežnom timu. ss -lntp na hostu baze podataka pokazuje koja adresa i port zaista slušaju, a taj jedan red isključuje cijelu kategoriju nagađanja.

Popravite usko, pa ponovo testirajte u oba smjera

Kreirajte predviđeni račun kvalifikovan hostom kroz odobreni proces organizacije, s akreditivom iz podržanog spremišta, a ne zajedničkim zalijepljenim u tiket. Dodijelite samo operacije nad šemom koje zadatak treba. Pretvaranje neuspjele udaljene prijave u root račun, politiku dodjele svega ili široki džoker host čini da test prođe i uklanja kontrolu koju ste testirali. Grant koji ste dodali u žurbi je onaj koji kasnije niko ne uklanja.

Ponovo testirajte sa svježom sesijom kroz predviđeni put, pa provjerite negativne slučajeve. Put koji treba biti blokiran mora ostati blokiran, a operacija koja nije dodijeljena mora ostati odbijena. Te dvije provjere razlikuju popravljen račun od proširenog.

Na kraju, zabilježite uočenu izvornu adresu i ime računa zajedno. Tunel daje dostupnost; MariaDB i dalje bira i autorizuje vlastiti račun, a sljedećoj osobi trebaju obje činjenice da reprodukuje vaš rezultat.