MySQL localhost VPN-en át: ez továbbra is a helyi folyamatot jelenti

Az irodai szerveren futó alkalmazás MySQL-hez csatlakozik a localhost címen, Ön átmásolja ezt a gazdanevet egy asztali kliensbe, és a kapcsolat vagy meghiúsul, vagy másik adatbázist nyit meg. A VPN semmit nem változtatott a szó jelentésén: a localhost továbbra is azt a gépet jelöli, amelyen a kliens fut. A VPN csomagokat mozgatott, nem interfészeket. Döntse el, melyik végpontot kell a laptopnak elérnie, mielőtt bármelyik útvonalhoz nyúl.

1. lépés: döntse el, melyik végpontot kell a laptopnak elérnie

Mindkét felépítés jogos, és más-más kérdésre válaszol. A közvetlen hozzáférés azt jelenti, hogy az adatbázis egy privát címen figyel, amelyet az alagút elér, és a laptop ehhez a címhez csatlakozik. A továbbított hozzáférés azt jelenti, hogy az adatbázis loopbacken marad, és egy SSH-munkamenet viszi a portot a gépére. Válasszon egyet szándékosan, mert a kettő keverése olyan kapcsolatot ad, amely rossz okból működik.

Közvetlen hozzáféréshez szerezze be az adatbázis-gazda saját privát nevét vagy címét és a portját attól, aki üzemelteti. A VPN-átjáró címe nem az adatbázis címe, hacsak nem ugyanaz a gép. Ezután erősítse meg, hogy a figyelő valóban ehhez az interfészhez van kötve, mert az interfész felé vezető útvonal nem hoz létre rajta figyelőt.

2. lépés: csak akkor továbbítsa a portot, ha a figyelő helyi marad

Ha az adatbázisnak csak loopbacken szabad maradnia, továbbítsa SSH-n, és a helyi végét is kösse loopbackhez. A bal oldali kötési cím az Ön laptopjáé; a jobb oldali cél az SSH-szerver oldaláról értelmeződik, ahogy az OpenSSH-referencia leírja. E két szerep felcserélése a szokásos oka annak, hogy egy továbbítás működni látszik, de semmihez nem csatlakozik.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

Ha az SSH ugrógazdára érkezik az adatbázis-gazda helyett, a jobb oldali loopback az ugrógazdára utal, és a célt olyan címre kell változtatni, amelyet az a gazda elér. Az ExitOnForwardFailure elkapja a továbbítás létrehozásának kudarcát, de nem bizonyítja, hogy a későbbi kapcsolatok a cél felé sikerülnek. Tartsa bekapcsolva a gazdakulcs-ellenőrzést, és ne kínálja a továbbítási portot az egész LAN-jának úgy, hogy minden interfészhez hozzáköti.

Álljon meg, ha az adatbázisnak csak loopbacken szabad maradnia, és nem használhat SSH-t. Akkor a közvetlen hozzáférés a rossz felépítés, nem kikényszerítendő konfiguráció.

3. lépés: kényszerítse a klienst TCP-re

Unixon a localhostot kapó MySQL-kliens alapértelmezés szerint Unix-socketet választ, ezért a csak portváltás olyan socket keresésére hagyhatja, amelynek semmi köze a továbbításához. Használja a kifejezett TCP-protokollt és a loopback címet, hogy a kliens kapcsolatot nyisson a továbbítási portjához.

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

Az érték nélküli jelszóopció kérdez ahelyett, hogy a titkot a parancssorba tenné, és ez az a szokás, amelyet érdemes megtartani. Más eszközöknek saját kapcsolójuk van ugyanerre a megkülönböztetésre, és egyes illesztőprogramok is különlegesen kezelik a localhostot. Ellenőrizze, mit tesz a kliense, ahelyett hogy feltételezné, hogy a jelző átkerült. Az adatbázis-fióknak olyan jogosultság is kell, amely megfelel a szerver által látott forrásnak, és az a továbbítási gazda, nem az Ön laptopja.

Álljon meg, ha az eszközt nem lehet TCP-re kényszeríteni. Akkor használjon másik klienst, vagy közvetlen hozzáférést a privát figyelőhöz.

4. lépés: bizonyítsa, melyik végpontot érte el valójában

Kérdezze meg a szervert, minek tartja a kapcsolatot. A gazdanév, a port és a socket változói megmondják, TCP-n keresztül érkezett-e, és melyik figyelő válaszolt, a kapcsolatlistán pedig látszik a forráscím, amelyet a szerver rögzített. Ez a bizonyíték hasznosabb, mint egy újabb útvonalváltoztatás.

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

Jegyezze fel, melyik végpontot próbálta: helyi Unix-socketet, a továbbítási portját vagy a privát figyelőt. Ennek a három kudarcnak más a javítása, és a VPN-útvonal módosítása, miközben a kliens még a rossz localhosttal beszél, elvesztegetett fáradság. A jegyzetekben tartsa külön az SSH-hitelesítést és az adatbázis-hitelesítést is, mert az egyik kudarca asztali kliensből a másik kudarcának látszik. Utána távolítsa el a továbbítást, amikor végzett.

Az ellenőrzőlista akkor ér véget, amikor meg tudja nevezni a végpontot, a kliens protokollját, a forráscímet, amelyet a szerver látott, és az engedélyt, amely lehetővé tette. Négy tény, és a következő kapcsolati probléma percekig tart egy délután helyett.