MariaDB over VPN: hvilken user@host ser serveren?
Kontoen velges av bruker og vert sammen. Finn kilden serveren har sett, les CURRENT_USER(), og reparer deretter den raden, ikke tildelingen.
Skriv samme brukernavn fra to forskjellige veier, og MariaDB kan autentisere deg som to forskjellige kontoer. Kontoer er nøklet på bruker og vert sammen, så 'reporter'@'localhost' og 'reporter'@'10.90.0.23' er separate rader med separate passord og separate tildelinger. Over en VPN er det interessante spørsmålet ikke hvilket navn brukeren skrev, men hvilken kildeadresse serveren har sett.
Bestem kilden serveren faktisk ser
Arbeid baklengs fra databaseverten, ikke fra den bærbare maskinen. Adressen klienten tror den har, er bare én av flere muligheter:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
Bruk bevis fra serversiden for å avgjøre det. En tilkoblingslogg, en liste over aktive økter eller en midlertidig oppføring i den generelle loggen viser adressen serveren godtok. Den bærbare maskinens offentlige IP fra en nettleser er et annet faktum og ofte et misvisende ett.
Match kontoen MariaDB valgte
Kontovalget følger en dokumentert rekkefølge og ikke en forening av tildelinger. En nøyaktig vertsmatch går foran et jokertegn, og rader med anonym bruker deltar i matchingen på måter som overrasker folk som antar at navnet alene avgjør. Serveren velger én rad; den slår ikke sammen privilegiene til hver likt navngitt rad. Å lese referansen én gang er verdt mer enn en ettermiddag med gjetting.
Det betyr at det å legge til en tildeling på 'reporter'@'%' kanskje ikke endrer noe hvis økten autentiserte seg som 'reporter'@'10.90.0.23'. Rettelsen må lande på raden som ble valgt, derfor kommer identifiseringen av kontoen før redigering av tildelinger.
Les kontoen økten faktisk bruker
SELECT USER(), CURRENT_USER();
SHOW GRANTS;
CURRENT_USER() navngir kontoen som autentiserte økten; USER() rapporterer hva klienten ba om og kan avvike. Kjør dem som vanlige spørringer på øverste nivå, ikke inne fra en lagret rutine med definerende kontekst, ellers beskriver svarene rutinens eier i stedet for økten din.
En mislykket innlogging kan ikke kjøre noe av dette, og det er tilfellet der en administrator må undersøke kontodefinisjonene og serverens tilkoblingsbevis i stedet. Planlegg for det: personen som feilsøker en avvist innlogging har vanligvis ingen SQL-økt å spørre i.
Skill nåbarhet fra autentisering
Feilteksten forteller deg hvilket lag du er i. En avvist tilkobling eller en tidsavbrudd betyr at klienten aldri nådde en lytter, så kontoen og passordet er ennå ikke i spill. Et svar om nektet tilgang betyr at serveren svarte, noe som beviser nåbarhet og peker på kontoen, vertsmatchingen eller legitimasjonen.
Nettverksforutsetningene er sin egen liste: en lytter bundet til den tiltenkte adressen og ikke bare til loopback, tillatt trafikk til den konfigurerte porten og en returrute for svaret. Hver av dem kan feile uavhengig, og en fungerende tunnel innebærer ingen av dem. En lytter på loopback godtar lokale tilkoblinger og avviser hver fjern tilkobling, noe som gir en avvist tilkobling som ser ut som en brannmurblokkering.
Kontroller bind-adressen før du åpner en sak hos nettverksteamet. ss -lntp på databaseverten viser hvilken adresse og port som faktisk lytter, og den ene linjen utelukker en hel kategori med gjetting.
Reparer smalt, og test deretter begge retninger
Opprett den tiltenkte vertskvalifiserte kontoen gjennom organisasjonens godkjente prosess, med en legitimasjon fra det støttede lageret i stedet for en delt som er limt inn i en sak. Gi bare skjemaoperasjonene oppgaven trenger. Å gjøre en mislykket fjerninnlogging om til en root-konto, en gi-alt-policy eller en generell jokervert får testen til å bestå og fjerner kontrollen du testet. Tildelingen du la til i hast, er den ingen fjerner senere.
Test på nytt med en fersk økt via den tiltenkte veien, og kontroller deretter de negative tilfellene. En vei som skal være blokkert må fortsatt være blokkert, og en operasjon som ikke ble gitt må fortsatt være nektet. Disse to kontrollene skiller en reparert konto fra en utvidet.
Til slutt registrerer du den observerte kildeadressen og kontonavnet sammen. Tunnelen gir nåbarhet; MariaDB velger og autoriserer fortsatt sin egen konto, og neste person trenger begge fakta for å reprodusere resultatet ditt.