MariaDB tra VPN: kiun user@host vidas la servilo?
La konto elektiĝas laŭ uzanto kaj gastiganto kune. Trovu la fonton, kiun la servilo vidis, legu CURRENT_USER(), poste riparu tiun vicon, ne la permeson.
Tajpu la saman uzantnomon el du malsamaj vojoj kaj MariaDB povas aŭtentigi vin kiel du malsamajn kontojn. Kontoj estas ŝlositaj laŭ uzanto kaj gastiganto kune, do 'reporter'@'localhost' kaj 'reporter'@'10.90.0.23' estas apartaj vicoj kun apartaj pasvortoj kaj apartaj permesoj. Tra VPN, la interesa demando ne estas, kiun nomon la uzanto tajpis, sed kiun fontan adreson la servilo vidis.
Determinu la fonton, kiun la servilo efektive vidas
Laboru malantaŭen de la datumbaza gastiganto, ne de la tekkomputilo. La adreso, kiun la kliento kredas havi, estas nur unu el pluraj ebloj:
| 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 |
Uzu servilflankajn pruvojn por decidi tion. Konekta protokolo, listo de aktivaj sesioj aŭ provizora enskribo en la ĝenerala protokolo montras la adreson, kiun la servilo akceptis. La publika IP de la tekkomputilo el retumilo estas alia fakto kaj ofte misgvida.
Parigu la konton, kiun MariaDB elektis
Konta elekto sekvas dokumentitan ordon, ne union de permesoj. Ekzakta gastiganta kongruo havas prioritaton super ĵokera signo, kaj vicoj de anonima uzanto partoprenas en kongruo laŭ manieroj, kiuj surprizas homojn, kiuj supozas, ke la nomo sola decidas. La servilo elektas unu vicon; ĝi ne kunfandas la privilegiojn de ĉiu samnoma vico. Legi la referencon unufoje valoras pli ol posttagmezo da divenoj.
Tio signifas, ke aldoni permeson al 'reporter'@'%' eble tute ne ŝanĝas ion, se la sesio aŭtentiĝis kiel 'reporter'@'10.90.0.23'. La ripeto devas surteriĝi sur la vico, kiu estis elektita, tial identigi la konton venas antaŭ redakti permesojn.
Legu la konton, kiun la sesio efektive uzas
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() nomas la konton, kiu aŭtentigis la sesion; USER() raportas, kion la kliento petis, kaj povas malsami. Rulu ilin kiel ordinarajn plejaltnivelajn demandojn, ne el konservita rutino kun difina kunteksto, alie la respondoj priskribas la posedanton de la rutino anstataŭ vian sesion.
Malsukcesa ensaluto povas ruli neniom el tio, kaj tio estas la kazo, kiam administranto devas anstataŭe inspekti la kontajn difinojn kaj la konektajn pruvojn de la servilo. Planu por tio: la persono, kiu sencimigas rifuzitan ensaluton, kutime havas neniun SQL-sesion por demandi.
Apartigu atingeblon de aŭtentigo
La erarteksto diras al vi, en kiu tavolo vi estas. Rifuzita konekto aŭ tempolimo signifas, ke la kliento neniam atingis aŭskultanton, do la konto kaj ĝia pasvorto ankoraŭ ne estas pridubataj. Respondo pri rifuzita aliro signifas, ke la servilo respondis, kio pruvas atingeblon kaj montras al la konto, la gastiganta kongruo aŭ la legitimilo.
Retaj antaŭkondiĉoj estas propra listo: aŭskultanto ligita al la celata adreso kaj ne nur al loopback, permesita trafiko al la agordita pordo kaj revena vojo por la respondo. Ĉiu povas malsukcesi sendepende, kaj funkcianta tunelo implicas neniun el ili. Aŭskultanto sur loopback akceptas lokajn konektojn kaj rifuzas ĉiun malproksiman, kio produktas rifuzitan konekton, kiu aspektas kiel fajroŝirma blokado.
Kontrolu la bind-adreson antaŭ ol malfermi bileton ĉe la reta teamo. ss -lntp sur la datumbaza gastiganto montras, kiu adreso kaj pordo efektive aŭskultas, kaj tiu sola linio ekskludas tutan kategorion da divenoj.
Riparu mallarĝe, poste retestu ambaŭ direktojn
Kreu la celatan konton kvalifikitan per gastiganto per la aprobita procezo de la organizo, kun legitimilo el la subtenata stokejo anstataŭ komuna, enmetita en bileton. Donu nur la skemajn operaciojn, kiujn la tasko bezonas. Turni malsukcesan malproksiman ensaluton en root-konton, ĉion-permesan politikon aŭ ĝeneralan ĵokeran gastiganton igas la teston pasi kaj forigas la kontrolon, kiun vi testis. La permeso, kiun vi aldonis haste, estas tiu, kiun neniu forigas poste.
Retestu per freŝa sesio tra la celata vojo, poste kontrolu la negativajn kazojn. Vojo, kiu devus esti blokita, devas resti blokita, kaj operacio, kiu ne estis permesita, devas resti malpermesita. Tiuj du kontroloj estas tio, kio apartigas riparitan konton de vastigita.
Fine, registru la observitan fontan adreson kaj la kontan nomon kune. La tunelo provizas atingeblon; MariaDB ankoraŭ elektas kaj rajtigas sian propran konton, kaj la sekva persono bezonas ambaŭ faktojn por reprodukti vian rezulton.