MySQL localhost tra VPN: ĝi ankoraŭ signifas la lokan procezon

La aplikaĵo sur la ofica servilo konektiĝas al MySQL ĉe localhost, vi kopias tiun gastigantnomon en labortablan klienton, kaj la konekto aŭ malsukcesas aŭ malfermas alian datumbazon. La VPN ŝanĝis nenion en la signifo de la vorto: localhost ankoraŭ indikas tiun maŝinon, kiu rulas la klienton. La VPN movis pakaĵojn, ne interfacojn. Decidu, kiun finpunkton la tekkomputilo devas atingi, antaŭ ol vi tuŝos itineron.

Paŝo 1: decidu, kiun finpunkton la tekkomputilo devas atingi

Ambaŭ projektoj estas legitimaj kaj respondas malsamajn demandojn. Rekta aliro signifas, ke la datumbazo aŭskultas sur privata adreso atingebla de la tunelo, kaj la tekkomputilo konektiĝas al tiu adreso. Plusendita aliro signifas, ke la datumbazo restas sur loopback kaj SSH-sesio portas la pordon al via maŝino. Elektu unu konscie, ĉar miksado de ili produktas konekton, kiu funkcias pro la malĝusta kaŭzo.

Por rekta aliro, prenu la propran privatan nomon aŭ adreson de la gastiganto de la datumbazo kaj ĝian pordon de tiu, kiu administras ĝin. La adreso de la VPN-enirejo ne estas la datumbaza adreso, se temas ne pri la sama maŝino. Poste konfirmu, ke la aŭskultanto vere estas ligita al tiu interfaco, ĉar itinero al interfaco ne kreas aŭskultanton sur ĝi.

Paŝo 2: plusendu la pordon nur se la aŭskultanto restas loka

Se la datumbazo devas resti nur sur loopback, plusendu ĝin tra SSH kaj ligu ankaŭ la lokan finon al loopback. La liga adreso maldekstre apartenas al via tekkomputilo; la celo dekstre estas interpretata de la flanko de la SSH-servilo, kiel priskribas la OpenSSH-referenco. Inversigi tiujn du rolojn estas la kutima kaŭzo, kial plusendado ŝajnas funkcii sed konektiĝas al nenio.

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

Se SSH surteriĝas sur saltan gastiganton anstataŭ la gastiganton de la datumbazo, la loopback dekstre rilatas al la salta gastiganto, kaj la celo devas ŝanĝiĝi al adreso, kiun tiu gastiganto atingas. ExitOnForwardFailure kaptas malsukceson starigi la plusendadon, sed ĝi ne pruvas, ke postaj konektoj al la celo sukcesas. Tenu la kontrolon de la gastiganta ŝlosilo ŝaltita, kaj ne proponu la plusendan pordon al via tuta LAN ligante ĝin al ĉiuj interfacoj.

Haltu, se la datumbazo devas resti nur sur loopback kaj vi ne povas uzi SSH. Tiam rekta aliro estas la malĝusta projekto, ne agordo devigota.

Paŝo 3: devigu la klienton al TCP

En Unikso, MySQL-kliento ricevinta localhost elektas Uniksan konektilon defaŭlte, do ŝanĝi nur la pordon povas lasi ĝin serĉi konektilon, kiu neniel rilatas al via plusendado. Uzu la eksplicitan TCP-protokolon kaj la loopback-adreson por igi la klienton malfermi konekton al via plusenda pordo.

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

La pasvorta opcio sen valoro demandas anstataŭ meti la sekreton en la komandlinion, kaj tio estas la kutimo inda je konservo. Aliaj iloj havas sian propran ŝaltilon por la sama distingo, kaj kelkaj peliloj ankaŭ traktas localhost speciale. Kontrolu, kion via kliento faras, anstataŭ supozi, ke la flago transdoniĝis. La datumbaza konto ankaŭ bezonas permeson kongruan kun la fonto, kiun la servilo vidas, nome la plusenda gastiganto, ne via tekkomputilo.

Haltu, se la ilo ne povas esti devigita al TCP. Tiam uzu alian klienton aŭ rektan aliron al la privata aŭskultanto.

Paŝo 4: pruvu, kiun finpunkton vi efektive atingis

Demandu la servilon, kion ĝi opinias la konekto. La variabloj de gastigantnomo, pordo kaj konektilo diras, ĉu vi alvenis tra TCP kaj kiu aŭskultanto respondis, kaj la konektolisto montras la fontan adreson, kiun la servilo registris. Tiu pruvo utilas pli ol plia itinera ŝanĝo.

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

Notu, kiun finpunkton vi provis: lokan Uniksan konektilon, vian plusendan pordon aŭ la privatan aŭskultanton. Tiuj tri fiaskoj havas malsamajn riparojn, kaj ŝanĝi la VPN-itineron dum la kliento ankoraŭ parolas kun la malĝusta localhost estas vana peno. Tenu ankaŭ SSH-identigon kaj datumbazan identigon aparte en la notoj, ĉar fiasko en unu aspektas kiel fiasko en la alia el labortabla kliento. Poste forigu la plusendadon, kiam vi finos.

La kontrolo finiĝas, kiam vi povas nomi la finpunkton, la klientan protokolon, la fontan adreson, kiun la servilo vidis, kaj la permeson, kiu tion ebligis. Kvar faktoj, kaj la sekva konekta problemo daŭras minutojn anstataŭ posttagmezon.