MySQL localhost oor ’n VPN: dit bly steeds die plaaslike proses

Die toepassing op die kantoorbediener maak by localhost aan MySQL vas, jy kopieer daardie gasheernaam in ’n lessenaarkliënt, en die verbinding misluk of maak ’n ander databasis oop. Niks aan die VPN het die woord se betekenis verander nie: localhost verwys steeds na die masjien wat die kliënt laat loop. Die VPN het pakkette verskuif, nie koppelvlakke nie. Besluit watter eindpunt die skootrekenaar moet bereik voordat jy aan ’n roete raak.

Stap 1: besluit watter eindpunt die skootrekenaar moet bereik

Twee ontwerpe is geldig en hulle antwoord verskillende vrae. Direkte toegang beteken die databasis luister op ’n private adres wat die tonnel kan bereik, en die skootrekenaar verbind met daardie adres. Deurgevoerde toegang beteken die databasis bly op loopback en ’n SSH-sessie dra die poort na jou masjien. Kies een doelbewus, want om hulle te meng lewer ’n verbinding wat om die verkeerde rede werk.

Vir direkte toegang, kry die databasisgasheer se eie private naam of adres en sy poort by wie dit ook al bestuur. Die VPN-poortwag se adres is nie die databasisadres nie, tensy dit dieselfde masjien is. Bevestig dan dat die luisteraar werklik aan daardie koppelvlak gebind is, want ’n roete na ’n koppelvlak skep nie ’n luisteraar daarop nie.

Stap 2: voer die poort net deur as die luisteraar plaaslik bly

As die databasis net op loopback moet bly, voer dit oor SSH deur en bind die plaaslike punt ook aan loopback. Die bindadres aan die linkerkant hoort by jou skootrekenaar; die teiken aan die regterkant word van die SSH-bediener se kant af gelees, soos die OpenSSH-verwysing dit beskryf. Om daardie twee rolle om te ruil is die gewone rede waarom ’n deurvoer werk lyk maar aan niks koppel nie.

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

As SSH op ’n spronggasheer beland eerder as die databasisgasheer, verwys die loopback regs na die spronggasheer, en die teiken moet verander na ’n adres wat daardie gasheer kan bereik. ExitOnForwardFailure vang ’n mislukking om die deurvoer te vestig, maar dit bewys nie dat latere verbindings na die teiken slaag nie. Hou gasheersleuteltoetsing aan, en moenie die deurvoerpoort aan jou hele LAN aanbied deur dit aan alle koppelvlakke te bind nie.

Stop as die databasis op loopback alleen moet bly en jy nie SSH kan gebruik nie. Direkte toegang is dan die verkeerde ontwerp, nie ’n konfigurasie om te forseer nie.

Stap 3: dwing die kliënt na TCP

Op Unix kies ’n MySQL-kliënt wat localhost kry, by verstek ’n Unix-sok, so om net die poort te verander kan dit laat soek na ’n sok wat niks met jou deurvoer te doen het nie. Gebruik die eksplisiete TCP-protokol en die loopback-adres om die kliënt ’n verbinding na jou deurvoerpoort te laat oopmaak.

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

Die wagwoordopsie sonder ’n waarde vra eerder as om die geheim in die opdragreël te sit, en dit is die gewoonte wat werd is om te hou. Ander gereedskap het hul eie skakelaar vir dieselfde onderskeid, en sommige drywers hanteer localhost ook spesiaal. Kyk wat jou kliënt doen eerder as om aan te neem die vlag het oorgedra. Die databasisrekening het ook ’n toekenning nodig wat by die bron pas wat die bediener sien, dit is die deurvoergasheer eerder as jou skootrekenaar.

Stop as die gereedskap nie na TCP gedwing kan word nie. Gebruik dan ’n ander kliënt, of gebruik direkte toegang tot die private luisteraar.

Stap 4: bewys watter eindpunt jy werklik bereik het

Vra die bediener wat dit dink die verbinding is. Die gasheernaam-, poort- en sokveranderlikes sê of jy oor TCP aangekom het en watter luisteraar geantwoord het, en die verbindingslys wys die bronadres wat die bediener aangeteken het. Daardie bewyse is nuttiger as nog ’n roeteverandering.

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

Teken aan watter eindpunt jy probeer het: ’n plaaslike Unix-sok, jou deurvoerpoort of die private luisteraar. Daardie drie mislukkings het verskillende regstellings, en om die VPN-roete te verander terwyl die kliënt nog met die verkeerde localhost praat, is vermorste moeite. Hou SSH-verifikasie en databasisverifikasie ook apart in die notas, want ’n mislukking in die een lyk soos ’n mislukking in die ander van ’n lessenaarkliënt af. Verwyder dan die deurvoer wanneer jy daarmee klaar is.

Die kontrolelys eindig wanneer jy die eindpunt, die kliëntprotokol, die bronadres wat die bediener gesien het en die toekenning wat dit toegelaat het kan noem. Vier feite, en die volgende verbindingsprobleem neem minute in plaas van ’n middag.