MariaDB over VPN: hvilken user@host ser serveren?

Skriv det samme brugernavn ad to forskellige veje, og MariaDB kan godkende dig som to forskellige konti. Konti er nøglet på bruger og vært sammen, så 'reporter'@'localhost' og 'reporter'@'10.90.0.23' er separate rækker med separate adgangskoder og separate tildelinger. Over en VPN er det interessante spørgsmål ikke, hvilket navn brugeren skrev, men hvilken kildeadresse serveren har set.

Bestem den kilde, serveren faktisk ser

Arbejd baglæns fra databaseværten, ikke fra den bærbare computer. Den adresse, klienten tror, den har, er kun én af flere muligheder:

Brug beviser fra serversiden til at afgøre det. En forbindelseslog, en liste over aktive sessioner eller en midlertidig post i den generelle log viser den adresse, serveren accepterede. Den bærbare computers offentlige IP fra en browser er et andet faktum og ofte et misvisende et.

Match den konto, MariaDB valgte

Kontovalget følger en dokumenteret rækkefølge frem for en forening af tildelinger. Et præcist vært-match har forrang for et jokertegn, og rækker med anonym bruger deltager i matchningen på måder, der overrasker folk, som antager, at navnet alene afgør det. Serveren vælger én række; den slår ikke privilegierne for hver lignende navngivet række sammen. At læse referencen én gang er mere værd end en eftermiddag med gætterier.

Det betyder, at tilføjelse af en tildeling til 'reporter'@'%' måske ikke ændrer noget, hvis sessionen blev godkendt som 'reporter'@'10.90.0.23'. Rettelsen skal lande på den række, der blev valgt, og derfor kommer identifikationen af kontoen før redigering af tildelinger.

Læs den konto, sessionen faktisk bruger

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

CURRENT_USER() angiver den konto, der godkendte sessionen; USER() rapporterer, hvad klienten bad om, og kan afvige. Kør dem som almindelige forespørgsler på øverste niveau, ikke inde fra en gemt rutine med en definerende kontekst, ellers beskriver svarene rutinens ejer i stedet for din session.

Et mislykket login kan ikke køre noget af dette, og det er tilfældet, hvor en administrator i stedet må inspicere kontodefinitionerne og serverens forbindelsesbeviser. Planlæg det: personen, der fejlretter et afvist login, har normalt ingen SQL-session at forespørge i.

Adskil nåbarhed fra godkendelse

Fejlteksten fortæller dig, hvilket lag du er i. En afvist forbindelse eller en timeout betyder, at klienten aldrig nåede en lytter, så kontoen og dens adgangskode er endnu ikke i spil. Et svar om nægtet adgang betyder, at serveren svarede, hvilket beviser nåbarhed og peger på kontoen, vært-matchet eller legitimationsoplysningen.

Netværksforudsætninger er deres egen liste: en lytter bundet til den tilsigtede adresse og ikke kun til loopback, tilladt trafik til den konfigurerede port og en returrute for svaret. Hver kan fejle uafhængigt, og en fungerende tunnel indebærer ingen af dem. En lytter på loopback accepterer lokale forbindelser og afviser enhver fjern forbindelse, hvilket giver en afvist forbindelse, der ligner en firewallblokering.

Kontroller bind-adressen, før du åbner en sag hos netværksteamet. ss -lntp på databaseværten viser, hvilken adresse og port der faktisk lytter, og den ene linje udelukker en hel kategori af gæt.

Reparér snævert, og test derefter begge retninger

Opret den tilsigtede værtkvalificerede konto gennem organisationens godkendte proces, med en legitimationsoplysning fra det understøttede lager i stedet for en delt, der er indsat i en sag. Tildel kun de skemaoperationer, opgaven har brug for. At gøre et mislykket fjernlogin til en root-konto, en tildel-alt-politik eller en blanket jokertegn-vært får testen til at bestå og fjerner den kontrol, du testede. Den tildeling, du tilføjede i hast, er den, ingen fjerner senere.

Test igen med en frisk session ad den tilsigtede vej, og kontroller derefter de negative tilfælde. En vej, der skal blokeres, skal stadig være blokeret, og en handling, der ikke blev tildelt, skal stadig være nægtet. De to kontroller er det, der adskiller en repareret konto fra en udvidet.

Til sidst skal du registrere den observerede kildeadresse og kontonavnet sammen. Tunnelen leverer nåbarhed; MariaDB vælger og autoriserer stadig sin egen konto, og den næste person har brug for begge fakta for at gengive dit resultat.