MySQL localhost per VPN: tai vis dar reiškia vietinį procesą
Duomenų bazė, kurią programa vadina localhost, yra serveryje, o ne jūsų nešiojamajame. Naudokite privatų klausytuvą arba SSH perdavimą, tada priverskite klientą naudoti TCP.
Biuro serverio programa jungiasi prie MySQL adresu localhost, jūs nukopijuojate tą hosto vardą į darbalaukio klientą, ir ryšys arba nepavyksta, arba atidaro kitą duomenų bazę. VPN nepakeitė žodžio reikšmės: localhost vis dar reiškia mašiną, kurioje veikia klientas. VPN perkėlė paketus, o ne sąsajas. Nuspręskite, kurį galinį tašką nešiojamasis turi pasiekti, prieš liesdami maršrutą.
1 žingsnis: nuspręskite, kurį galinį tašką nešiojamasis turi pasiekti
Abu sprendimai yra teisėti ir atsako į skirtingus klausimus. Tiesioginė prieiga reiškia, kad duomenų bazė klausosi privataus adreso, kurį pasiekia tunelis, o nešiojamasis jungiasi prie to adreso. Perduodama prieiga reiškia, kad duomenų bazė lieka loopback, o SSH sesija neša portą į jūsų mašiną. Pasirinkite vieną sąmoningai, nes sumaišius juos gaunamas ryšys, kuris veikia dėl neteisingos priežasties.
Tiesioginei prieigai gaukite paties duomenų bazės hosto privatų vardą arba adresą ir jo portą iš to, kas jį administruoja. VPN šliuzo adresas nėra duomenų bazės adresas, nebent tai ta pati mašina. Tada patvirtinkite, kad klausytuvas tikrai susietas su ta sąsaja, nes maršrutas į sąsają nesukuria joje klausytuvo.
2 žingsnis: perduokite portą tik jei klausytuvas lieka vietinis
Jei duomenų bazė turi likti tik loopback, perduokite ją per SSH ir vietinį galą taip pat susiekite su loopback. Susiejimo adresas kairėje priklauso jūsų nešiojamajam; tikslas dešinėje interpretuojamas iš SSH serverio pusės, kaip aprašo OpenSSH žinynas. Šių dviejų vaidmenų sukeitimas yra įprasta priežastis, kodėl perdavimas atrodo veikiantis, bet nieko nepasiekia.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'
Jei SSH nusileidžia ne ant duomenų bazės hosto, o ant šuolio hosto, dešinysis loopback reiškia šuolio hostą, o tikslą reikia pakeisti adresu, kurį tas hostas pasiekia. ExitOnForwardFailure pagauna perdavimo sukūrimo nesėkmę, bet neįrodo, kad vėlesni ryšiai su tikslu pavyks. Palikite hosto rakto tikrinimą įjungtą ir nesiūlykite perdavimo porto visam savo LAN, susiedami jį su visomis sąsajomis.
Sustokite, jei duomenų bazė turi likti tik loopback, o SSH naudoti negalite. Tada tiesioginė prieiga yra neteisingas sprendimas, o ne konfigūracija, kurią reikia primesti.
3 žingsnis: priverskite klientą naudoti TCP
Unix sistemoje MySQL klientas, gavęs localhost, pagal nutylėjimą pasirenka Unix lizdą, todėl pakeitus tik portą jis gali likti ieškoti lizdo, kuris neturi nieko bendra su jūsų perdavimu. Naudokite aiškų TCP protokolą ir loopback adresą, kad klientas atidarytų ryšį su jūsų perdavimo portu.
mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password
Slaptažodžio parinktis be reikšmės klausia, o ne deda paslaptį į komandų eilutę, ir tai yra įprotis, kurį verta išlaikyti. Kiti įrankiai turi savo jungiklį tam pačiam skirtumui, o kai kurie tvarkyklės localhost taip pat traktuoja specialiai. Patikrinkite, ką daro jūsų klientas, o ne manykite, kad požymis buvo perduotas. Duomenų bazės paskyrai taip pat reikia teisės, atitinkančios šaltinį, kurį mato serveris, ir tai yra perdavimo hostas, o ne jūsų nešiojamasis.
Sustokite, jei įrankio nepavyksta priversti naudoti TCP. Tada naudokite kitą klientą arba tiesioginę prieigą prie privataus klausytuvo.
4 žingsnis: įrodykite, kurį galinį tašką iš tikrųjų pasiekėte
Paklauskite serverio, kuo jis laiko ryšį. Hosto vardo, porto ir lizdo kintamieji pasako, ar atėjote per TCP ir kuris klausytuvas atsakė, o ryšių sąrašas rodo šaltinio adresą, kurį serveris užfiksavo. Šis įrodymas naudingesnis už dar vieną maršruto pakeitimą.
mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"
Užrašykite, kurį galinį tašką bandėte: vietinį Unix lizdą, savo perdavimo portą ar privatų klausytuvą. Šios trys nesėkmės turi skirtingus sprendimus, o VPN maršruto keitimas, kol klientas dar kalba su neteisingu localhost, yra bergždžias darbas. Užrašuose atskirai laikykite SSH autentifikaciją ir duomenų bazės autentifikaciją, nes vienos nesėkmė iš darbalaukio kliento atrodo kaip kitos nesėkmė. Tada pašalinkite perdavimą, kai baigsite.
Sąrašas baigiasi, kai galite įvardyti galinį tašką, kliento protokolą, šaltinio adresą, kurį matė serveris, ir teisę, kuri tai leido. Keturi faktai, ir kita ryšio problema užima minutes, o ne popietę.