MySQL localhost sa pamamagitan ng VPN: lokal na proseso pa rin ang ibig sabihin

Ang app sa office server ay kumokonekta sa MySQL sa localhost, kinokopya mo ang hostname na iyon sa desktop client, at ang koneksyon ay nabigo o nagbukas ng ibang database. Walang binago ang VPN sa kahulugan ng salita: ang localhost ay tumutukoy pa rin sa makina kung saan tumatakbo ang client. Inilipat ng VPN ang mga packet, hindi ang mga interface. Magpasya kung aling endpoint ang dapat maabot ng laptop bago mo hawakan ang anumang ruta.

Hakbang 1: magpasya kung aling endpoint ang dapat maabot ng laptop

Parehong lehitimo ang dalawang disenyo at sumasagot sa magkaibang tanong. Ang direktang pag-access ay nangangahulugang nakikinig ang database sa isang pribadong address na naaabot ng tunnel, at kumokonekta ang laptop sa address na iyon. Ang forward na pag-access ay nangangahulugang nananatili ang database sa loopback at may SSH session na nagdadala ng port sa makina mo. Pumili ng isa nang sinasadya, dahil ang paghahalo ng dalawa ay gumagawa ng koneksyon na gumagana sa maling dahilan.

Para sa direktang pag-access, kunin ang sariling pribadong pangalan o address ng host ng database at ang port nito sa kung sino man ang namamahala nito. Ang address ng VPN gateway ay hindi ang address ng database maliban kung pareho silang makina. Pagkatapos tiyakin na ang listener ay talagang nakatali sa interface na iyon, dahil ang ruta patungo sa interface ay hindi gumagawa ng listener doon.

Hakbang 2: i-forward ang port kung nananatiling lokal ang listener

Kung dapat manatili ang database sa loopback lamang, i-forward ito sa SSH at itali rin ang lokal na dulo sa loopback. Ang bind address sa kaliwa ay pag-aari ng laptop mo; ang target sa kanan ay binibigyang-kahulugan mula sa panig ng SSH server, gaya ng inilalarawan ng sanggunian ng OpenSSH. Ang pagbaliktad ng dalawang papel na iyon ang karaniwang dahilan kung bakit ang isang forward ay tila gumagana ngunit walang nakakonektang anuman.

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

Kung ang SSH ay lumapag sa isang jump host sa halip na sa host ng database, ang loopback sa kanan ay tumutukoy sa jump host, at ang target ay dapat palitan ng address na naaabot ng host na iyon. Nahuhuli ng ExitOnForwardFailure ang pagkabigo sa pagtatatag ng forward, ngunit hindi nito pinapatunayan na ang mga susunod na koneksyon sa target ay magtatagumpay. Panatilihing bukas ang pagsusuri ng host key, at huwag ialok ang forward port sa buong LAN mo sa pamamagitan ng pagtali nito sa lahat ng interface.

Huminto kung dapat manatili ang database sa loopback lamang at hindi mo magagamit ang SSH. Kung gayon, ang direktang pag-access ay ang maling disenyo, hindi isang configuration na pipilitin.

Hakbang 3: pilitin ang client sa TCP

Sa Unix, ang MySQL client na binigyan ng localhost ay pumipili ng Unix socket bilang default, kaya ang pagbabago lamang ng port ay maaaring mag-iwan sa kanya na naghahanap ng socket na walang kinalaman sa forward mo. Gamitin ang tahasang TCP protocol at ang loopback address para buksan ng client ang koneksyon sa iyong forward port.

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

Ang opsyong password na walang halaga ay nagtatanong sa halip na ilagay ang sikreto sa command line, at ito ang ugali na dapat panatilihin. Ang ibang mga tool ay may sariling switch para sa parehong pagkakaiba, at ang ilang driver ay espesyal ding tinatrato ang localhost. Suriin kung ano ang ginagawa ng iyong client sa halip na ipagpalagay na naipasa ang flag. Ang database account ay nangangailangan din ng pahintulot na tumutugma sa pinagmulan na nakikita ng server, at iyon ay ang forward host, hindi ang laptop mo.

Huminto kung hindi mapipilit ang tool sa TCP. Kung gayon, gumamit ng ibang client, o gumamit ng direktang pag-access sa pribadong listener.

Hakbang 4: patunayan kung aling endpoint ang aktwal na naabot mo

Tanungin ang server kung ano sa palagay nito ang koneksyon. Ang mga variable ng hostname, port at socket ay nagsasabi kung dumating ka sa TCP at aling listener ang sumagot, at ang listahan ng koneksyon ay nagpapakita ng source address na naitala ng server. Ang ebidensyang iyon ay mas kapaki-pakinabang kaysa sa isa pang pagbabago ng ruta.

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

Itala kung aling endpoint ang sinubukan mo: lokal na Unix socket, ang forward port mo o ang pribadong listener. Ang tatlong pagkabigong ito ay may magkaibang lunas, at ang pagbabago ng ruta ng VPN habang kausap pa ng client ang maling localhost ay sayang na pagsisikap. Panatilihing hiwalay sa mga tala ang SSH authentication at database authentication, dahil mula sa desktop client ang pagkabigo sa isa ay mukhang pagkabigo sa isa pa. Pagkatapos, alisin ang forward kapag tapos ka na.

Nagtatapos ang checklist kapag maitutukoy mo ang endpoint, ang protocol ng client, ang source address na nakita ng server at ang pahintulot na nagbigay-daan dito. Apat na katotohanan, at ang susunod na problema sa koneksyon ay tumatagal ng ilang minuto kaysa isang hapon.