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 naloga. Nalozi se vezuju za korisnika i host zajedno, pa su 'reporter'@'localhost' i 'reporter'@'10.90.0.23' odvojeni redovi sa odvojenim lozinkama i odvojenim dozvolama. Preko VPN-a zanimljivo pitanje nije koje je ime korisnik ukucao, nego koju je izvornu adresu server video.

Utvrdite izvor koji server zaista vidi

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

Upotrebite dokaze sa strane servera da to rešite. Dnevnik veza, lista aktivnih sesija ili privremeni unos u opštem dnevniku pokazuje adresu koju je server prihvatio. Javna IP adresa laptopa iz pregledača je druga činjenica i često obmanjujuća.

Uparite nalog koji je MariaDB odabrao

Izbor naloga sledi dokumentovani poredak, a ne uniju dozvola. Tačno podudaranje hosta ima prednost pred džoker znakom, a redovi anonimnog korisnika učestvuju 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 reference vredi više od popodneva testiranja nagađanja.

To znači da dodavanje dozvole na 'reporter'@'%' možda ništa ne menja ako se sesija autentifikovala kao 'reporter'@'10.90.0.23'. Popravka mora pasti na red koji je odabran, zato identifikacija naloga dolazi pre uređivanja dozvola.

Pročitajte nalog koji sesija zaista koristi

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

CURRENT_USER() imenuje nalog koji je autentifikovao sesiju; USER() izveštava šta je klijent tražio i može se razlikovati. Izvršite ih kao obične upite najvišeg nivoa, a ne iz sačuvane rutine sa kontekstom definišućeg korisnika, inače odgovori opisuju vlasnika rutine umesto vaše sesije.

Neuspešna prijava ne može izvršiti ništa od ovoga, a to je slučaj kada administrator mora pregledati definicije naloga 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 kom ste sloju. Odbijena veza ili istek vremena znači da klijent nikada nije stigao do slušaoca, pa nalog i njegova lozinka još nisu upitni. Odgovor o odbijenom pristupu znači da je server odgovorio, što dokazuje dostupnost i upućuje na nalog, podudaranje hosta ili akreditiv.

Mrežni preduslovi su poseban spisak: slušalac 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 da padne, a tunel koji radi ne podrazumeva nijedan od njih. Slušalac na loopbacku prihvata lokalne veze i odbija svaku udaljenu, što stvara odbijenu vezu koja izgleda kao blokada vatrozida.

Proverite adresu vezivanja pre nego što 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 celu kategoriju nagađanja.

Popravite usko, pa ponovo testirajte u oba smera

Napravite predviđeni nalog kvalifikovan hostom kroz odobreni proces organizacije, sa akreditivom iz podržanog skladišta, a ne zajedničkim zalepljenim u tiket. Dodelite samo operacije nad šemom koje zadatak traži. Pretvaranje neuspešne udaljene prijave u root nalog, politiku dodele svega ili široki džoker host čini da test prođe i uklanja kontrolu koju ste testirali. Dozvola koju ste dodali u žurbi je ona koju kasnije niko ne uklanja.

Ponovo testirajte sa svežom sesijom kroz predviđeni put, pa proverite negativne slučajeve. Put koji treba biti blokiran mora ostati blokiran, a operacija koja nije dodeljena mora ostati odbijena. Te dve provere razlikuju popravljen nalog od proširenog.

Na kraju, zabeležite uočenu izvornu adresu i ime naloga zajedno. Tunel daje dostupnost; MariaDB i dalje bira i autorizuje sopstveni nalog, a sledećoj osobi trebaju obe činjenice da reprodukuje vaš rezultat.