MySQL localhost VPN:n yli: se tarkoittaa yhä paikallista prosessia

Toimiston palvelimen sovellus yhdistää MySQL:ään osoitteessa localhost, kopioit sen isäntänimen työpöytäasiakkaaseen, ja yhteys joko epäonnistuu tai avaa toisen tietokannan. VPN ei muuttanut sanan merkitystä: localhost viittaa yhä siihen koneeseen, jolla asiakas toimii. VPN siirsi paketteja, ei rajapintoja. Päätä, mihin päätepisteeseen kannettavan pitää päästä, ennen kuin kosket reittiin.

Vaihe 1: päätä, mihin päätepisteeseen kannettavan pitää päästä

Molemmat mallit ovat kelvollisia ja vastaavat eri kysymyksiin. Suora käyttö tarkoittaa, että tietokanta kuuntelee yksityisessä osoitteessa, johon tunneli pääsee, ja kannettava yhdistää siihen osoitteeseen. Edelleenohjattu käyttö tarkoittaa, että tietokanta pysyy loopbackissa ja SSH-istunto kuljettaa portin koneellesi. Valitse toinen tietoisesti, sillä niiden sekoittaminen tuottaa yhteyden, joka toimii väärästä syystä.

Suoraa käyttöä varten hanki tietokannan isäntäkoneen oma yksityinen nimi tai osoite ja sen portti siltä, joka sitä hallinnoi. VPN-yhdyskäytävän osoite ei ole tietokannan osoite, ellei kyse ole samasta koneesta. Vahvista sitten, että kuuntelija on todella sidottu tuohon rajapintaan, sillä reitti rajapintaan ei luo kuuntelijaa sille.

Vaihe 2: ohjaa portti eteenpäin vain, jos kuuntelija pysyy paikallisena

Jos tietokannan pitää pysyä vain loopbackissa, ohjaa se SSH:n yli ja sido myös paikallinen pää loopbackiin. Vasemman puolen sidontaosoite kuuluu kannettavallesi; oikean puolen kohde tulkitaan SSH-palvelimen puolelta, kuten OpenSSH-viite kuvaa. Näiden kahden roolin vaihtaminen on tavallinen syy siihen, että edelleenohjaus näyttää toimivan mutta ei yhdistä mihinkään.

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

Jos SSH laskeutuu hyppyisäntään eikä tietokannan isäntään, oikean puolen loopback viittaa hyppyisäntään, ja kohde on vaihdettava osoitteeseen, johon se isäntä pääsee. ExitOnForwardFailure havaitsee edelleenohjauksen luomisen epäonnistumisen, mutta ei todista, että myöhemmät yhteydet kohteeseen onnistuvat. Pidä isäntäavaimen tarkistus päällä äläkä tarjoa edelleenohjausporttia koko lähiverkollesi sitomalla se kaikkiin rajapintoihin.

Pysähdy, jos tietokannan on pysyttävä vain loopbackissa etkä voi käyttää SSH:ta. Silloin suora käyttö on väärä malli, ei konfiguraatio, joka pitää pakottaa.

Vaihe 3: pakota asiakas TCP:hen

Unixissa MySQL-asiakas, jolle annetaan localhost, valitsee oletuksena Unix-socketin, joten pelkän portin muuttaminen voi jättää sen etsimään socketia, jolla ei ole mitään tekemistä edelleenohjauksesi kanssa. Käytä nimenomaista TCP-protokollaa ja loopback-osoitetta, jotta asiakas avaa yhteyden edelleenohjausporttiisi.

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

Salasanavaihtoehto ilman arvoa kysyy sen sijaan, että salaisuus pantaisiin komentoriville, ja se on tapa, joka kannattaa pitää. Muilla työkaluilla on oma kytkimensä samaan erotteluun, ja jotkut ajurit kohtelevat localhostia myös erityisesti. Tarkista, mitä asiakkaasi tekee, sen sijaan että olettaisit lipun siirtyneen. Tietokantatili tarvitsee myös oikeuden, joka vastaa lähdettä, jonka palvelin näkee, ja se on edelleenohjausisäntä, ei kannettavasi.

Pysähdy, jos työkalua ei voi pakottaa TCP:hen. Käytä silloin toista asiakasta tai suoraa käyttöä yksityiseen kuuntelijaan.

Vaihe 4: todista, mihin päätepisteeseen todella pääsit

Kysy palvelimelta, mitä se pitää yhteytenä. Isäntänimen, portin ja socketin muuttujat kertovat, saavuitko TCP:n kautta ja mikä kuuntelija vastasi, ja yhteysluettelo näyttää lähdeosoitteen, jonka palvelin tallensi. Se todiste on hyödyllisempi kuin vielä yksi reittimuutos.

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

Kirjaa, mitä päätepistettä yritit: paikallista Unix-socketia, edelleenohjausporttiasi vai yksityistä kuuntelijaa. Näillä kolmella epäonnistumisella on eri korjaukset, ja VPN-reitin muuttaminen, kun asiakas yhä puhuu väärälle localhostille, on hukattua vaivaa. Pidä myös SSH-todennus ja tietokannan todennus erillään muistiinpanoissa, sillä epäonnistuminen toisessa näyttää työpöytäasiakkaasta epäonnistumiselta toisessa. Poista sitten edelleenohjaus, kun olet valmis.

Tarkistuslista päättyy, kun pystyt nimeämään päätepisteen, asiakkaan protokollan, lähdeosoitteen, jonka palvelin näki, ja oikeuden, joka sen salli. Neljä tosiasiaa, ja seuraava yhteysongelma vie minuutteja iltapäivän sijaan.