Skriv same brukarnamn frå to ulike vegar, og MariaDB kan autentisere deg som to ulike kontoar. Kontoar er nøkla på brukar og vert saman, så 'reporter'@'localhost' og 'reporter'@'10.90.0.23' er separate rader med separate passord og separate tildelingar. Over ein VPN er det interessante spørsmålet ikkje kva namn brukaren skreiv, men kva kjeldeadresse tenaren har sett.

Fastset kjelda tenaren faktisk ser

Arbeid baklengs frå databaseverten, ikkje frå den bereknelege maskina. Adressa klienten trur han har, er berre éin av fleire moglege:

PathSource MariaDB sees
Routed tunnel, no translationThe client's inner VPN address
Gateway source translationThe gateway's translated address
SSH local forwardThe SSH server's address
Public exit, no tunnelWhatever the ISP handed out

Bruk prov frå tenarsida for å avgjere det. Ei tilkoplingslogg, ei liste over aktive økter eller eit mellombels innslag i den generelle loggen viser adressa tenaren godtok. Den bereknelege maskina si offentlege IP frå ein nettlesar er eit anna faktum og ofte eit misvisande eitt.

Match kontoen MariaDB valde

Kontovalet følgjer ei dokumentert rekkjefølgje og ikkje ei foreining av tildelingar. Ein nøyaktig vertsmatch går framom eit jokerteikn, og rader med anonym brukar deltek i matchinga på måtar som overraskar folk som går ut frå at namnet åleine avgjer. Tenaren vel éi rad; han slår ikkje saman privilegia til kvar likt namngjeven rad. Å lese referansen éin gong er verdt meir enn ein ettermiddag med gjetting.

Det tyder at det å leggje til ei tildeling på 'reporter'@'%' kanskje ikkje endrar noko om økta autentiserte seg som 'reporter'@'10.90.0.23'. Rettinga må lande på rada som vart vald, difor kjem identifiseringa av kontoen før redigering av tildelingar.

Les kontoen økta faktisk brukar

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

CURRENT_USER() namngjev kontoen som autentiserte økta; USER() rapporterer kva klienten bad om og kan avvike. Køyr dei som vanlege spørjingar på øvste nivå, ikkje inne frå ein lagra rutine med definerande kontekst, elles skildrar svara eigaren av rutinen i staden for økta di.

Ei mislukka innlogging kan ikkje køyre noko av dette, og det er tilfellet der ein administrator må undersøkje kontodefinisjonane og tilkoplingsprova til tenaren i staden. Planlegg for det: personen som feilsøkjer ei avvist innlogging har vanlegvis inga SQL-økt å spørje i.

Skil nåbarheit frå autentisering

Feilteksten fortel deg kva lag du er i. Ei avvist tilkopling eller ein timeout tyder at klienten aldri nådde ein lyttar, så kontoen og passordet er enno ikkje i spel. Eit svar om nekta tilgang tyder at tenaren svara, noko som provar nåbarheit og peikar på kontoen, vertsmatchinga eller legitimasjonen.

Nettverksføresetnadene er si eiga liste: ein lyttar bunden til den tiltenkte adressa og ikkje berre til loopback, tillaten trafikk til den konfigurerte porten og ein returveg for svaret. Kvar av dei kan feile uavhengig, og ein fungerande tunnel inneber ingen av dei. Ein lyttar på loopback godtek lokale tilkoplingar og avviser kvar fjern tilkopling, noko som gjev ei avvist tilkopling som ser ut som ei brannmurblokkering.

Kontroller bind-adressa før du opnar ei sak hos nettverksteamet. ss -lntp på databaseverten viser kva adresse og port som faktisk lyttar, og den eine linja utelukkar ein heil kategori med gjetting.

Reparer smalt, og test deretter begge retningar

Opprett den tiltenkte vertskvalifiserte kontoen gjennom den godkjende prosessen til organisasjonen, med ein legitimasjon frå det støtta lageret i staden for ein delt som er limt inn i ei sak. Gi berre skjemaoperasjonane oppgåva treng. Å gjere ei mislukka fjerninnlogging om til ein root-konto, ein gje-alt-policy eller ein generell jokervert får testen til å bestå og fjernar kontrollen du testa. Tildelinga du la til i hast, er den ingen fjernar seinare.

Test på nytt med ei fersk økt via den tiltenkte vegen, og kontroller deretter dei negative tilfella. Ein veg som skal vere blokkert må framleis vere blokkert, og ein operasjon som ikkje vart gitt må framleis vere nekta. Desse to kontrollane skil ein reparert konto frå ein utvida.

Til slutt registrerer du den observerte kjeldeadressa og kontonamnet saman. Tunnelen gjev nåbarheit; MariaDB vel og autoriserer framleis sin eigen konto, og neste person treng begge fakta for å reprodusere resultatet ditt.

Relaterte artiklar