MariaDB VPN-en át: melyik user@host-ot látja a kiszolgáló?

Írja be ugyanazt a felhasználónevet két különböző útvonalon, és a MariaDB két különböző fiókként hitelesítheti Önt. A fiókok felhasználó és gazdagép együtt alapján kulcsoltak, ezért 'reporter'@'localhost' és 'reporter'@'10.90.0.23' külön sorok külön jelszavakkal és külön engedélyekkel. VPN-en át az érdekes kérdés nem az, milyen nevet írt be a felhasználó, hanem hogy melyik forrás címet látta a kiszolgáló.

Határozza meg a forrást, amelyet a kiszolgáló valóban lát

Az adatbázis-gazdagéptől dolgozzon visszafelé, nem a laptopról. A cím, amelyről az ügyfél azt hiszi, hogy van, csak egy a több lehetőség közül:

Használjon kiszolgálóoldali bizonyítékokat a eldöntéshez. Egy kapcsolatnapló, az aktív munkamenetek listája vagy egy ideiglenes bejegyzés az általános naplóban mutatja a címet, amelyet a kiszolgáló elfogadott. A laptop nyilvános IP-je böngészőből egy másik tény, és gyakran félrevezető.

Párosítsa a MariaDB által kiválasztott fiókot

A fiókválasztás dokumentált sorrendet követ, nem az engedélyek egyesítését. A pontos gazdagép-egyezés elsőbbséget élvez a helyettesítő karakterrel szemben, és a névtelen felhasználói sorok olyan módon vesznek részt az egyeztetésben, ami meglepi azokat, akik azt feltételezik, hogy a név önmagában dönt. A kiszolgáló egy sort választ; nem egyesíti az azonos nevű sorok kiváltságait. A referenciát egyszer elolvasni többet ér, mint egy délután találgatni.

Ez azt jelenti, hogy a 'reporter'@'%'-hoz adott engedély semmit sem változtathat, ha a munkamenet 'reporter'@'10.90.0.23'-ként hitelesítette magát. A javításnak azon a soron kell landolnia, amelyet kiválasztottak, ezért a fiók azonosítása megelőzi az engedélyek szerkesztését.

Olvassa el a fiókot, amelyet a munkamenet valóban használ

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

CURRENT_USER() megnevezi a munkamenetet hitelesítő fiókot; USER() azt jelenti, amit az ügyfél kért, és eltérhet. Futtassa ezeket rendes legfelső szintű lekérdezésként, ne definiáló környezetű tárolt rutinból, különben a válaszok a rutin tulajdonosát írják le a munkamenete helyett.

Egy sikertelen bejelentkezés ezek közül semmit sem tud futtatni, és ez az az eset, amikor a rendszergazdának a fiókdefiníciókat és a kiszolgáló kapcsolati bizonyítékait kell megvizsgálnia. Számoljon ezzel: az elutasított bejelentkezést hibakereső személynek általában nincs SQL-munkamenete a lekérdezéshez.

Válassza szét az elérhetőséget a hitelesítéstől

A hibaüzenet megmondja, melyik rétegben van. Az elutasított kapcsolat vagy az időtúllépés azt jelenti, hogy az ügyfél soha nem ért el figyelőt, tehát a fiók és a jelszava még nem kérdéses. A hozzáférés megtagadása válasz azt jelenti, hogy a kiszolgáló válaszolt, ami bizonyítja az elérhetőséget, és a fiókra, a gazdagép-egyezésre vagy a hitelesítő adatra mutat.

A hálózati előfeltételek saját listát alkotnak: a szándékolt címhez kötött figyelő, nem csak a loopbackhez, a konfigurált portra engedélyezett forgalom és a válasz visszaútja. Mindegyik önállóan meghiúsulhat, és egy működő alagút egyiket sem jelenti. A loopbacken lévő figyelő elfogadja a helyi kapcsolatokat és minden távolit elutasít, ami olyan elutasított kapcsolatot eredményez, amely tűzfalblokkolásnak tűnik.

Ellenőrizze a kötési címet, mielőtt jegyet nyitna a hálózati csapatnál. Az adatbázis-gazdagépen a ss -lntp megmutatja, melyik cím és port figyel valójában, és az az egy sor kizárja a találgatások egész kategóriáját.

Szűken javítson, majd tesztelje mindkét irányt

Hozza létre a szándékolt, gazdagéphez kötött fiókot a szervezet jóváhagyott folyamatán keresztül, a támogatott tárolóból származó hitelesítő adattal, nem egy jegybe beillesztett közössel. Csak a feladat által igényelt séma-műveleteket adja meg. Egy sikertelen távoli bejelentkezés root fiókká, mindent-engedélyező szabályzattá vagy általános helyettesítő gazdagéppé alakítása átengedi a tesztet, és eltávolítja azt az ellenőrzést, amelyet tesztelt. A sietve hozzáadott engedély az, amelyet később senki nem távolít el.

Tesztelje újra friss munkamenettel a szándékolt útvonalon, majd ellenőrizze a negatív eseteket. Egy blokkolandó útvonalnak továbbra is blokkoltnak kell lennie, és egy meg nem adott műveletnek továbbra is megtagadottnak kell maradnia. Ez a két ellenőrzés választja el a javított fiókot a kibővítettől.

Végül rögzítse a megfigyelt forráscímet és a fióknevet együtt. Az alagút biztosítja az elérhetőséget; a MariaDB továbbra is saját fiókot választ és engedélyez, és a következő személynek mindkét tényre szüksége van az eredmény reprodukálásához.