MySQL localhost over en VPN: det betyder stadig den lokale proces

Applikationen på kontorserveren forbinder til MySQL på localhost, du kopierer det værtsnavn ind i en desktopklient, og forbindelsen fejler enten eller åbner en anden database. VPN ændrede ikke ordets betydning: localhost henviser stadig til den maskine, der kører klienten. VPN flyttede pakker, ikke grænseflader. Beslut, hvilket endepunkt den bærbare skal nå, før du rører en rute.

Trin 1: beslut, hvilket endepunkt den bærbare skal nå

Begge design er legitime og besvarer forskellige spørgsmål. Direkte adgang betyder, at databasen lytter på en privat adresse, som tunnelen kan nå, og den bærbare forbinder til den adresse. Videresendt adgang betyder, at databasen bliver på loopback, og at en SSH-session bærer porten til din maskine. Vælg ét bevidst, fordi blanding af dem giver en forbindelse, der virker af den forkerte grund.

Til direkte adgang skal du hente databaseværtens eget private navn eller adresse og dens port hos den, der driver den. VPN-gatewayens adresse er ikke databaseadressen, medmindre det er den samme maskine. Bekræft derefter, at listeneren faktisk er bundet til den grænseflade, fordi en rute til en grænseflade ikke opretter en listener på den.

Trin 2: videresend kun porten, hvis listeneren bliver lokal

Hvis databasen skal forblive kun på loopback, skal du videresende den over SSH og også binde den lokale ende til loopback. Bindeadressen til venstre tilhører din bærbare; målet til højre fortolkes fra SSH-serverens side, som OpenSSH-referencen beskriver. At bytte om på de to roller er den sædvanlige grund til, at en videresendelse ser ud til at virke, men ikke forbinder til noget.

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

Hvis SSH lander på en springvært i stedet for databaseværten, henviser loopback til højre til springværten, og målet skal ændres til en adresse, som den vært kan nå. ExitOnForwardFailure fanger en fejl ved at oprette videresendelsen, men beviser ikke, at senere forbindelser til målet lykkes. Behold værtsnøglekontrol slået til, og tilbyd ikke videresendelsesporten til hele dit LAN ved at binde den til alle grænseflader.

Stop, hvis databasen skal forblive kun på loopback, og du ikke kan bruge SSH. Så er direkte adgang det forkerte design, ikke en konfiguration, der skal gennemtvinges.

Trin 3: tving klienten over på TCP

På Unix vælger en MySQL-klient, der får localhost, en Unix-socket som standard, så hvis du kun ændrer porten, kan den blive ved med at lede efter en socket, der intet har med din videresendelse at gøre. Brug den eksplicitte TCP-protokol og loopback-adressen for at få klienten til at åbne en forbindelse til din videresendelsesport.

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

Adgangskodeindstillingen uden værdi spørger i stedet for at sætte hemmeligheden på kommandolinjen, og det er den vane, der er værd at beholde. Andre værktøjer har deres egen switch til samme skelnen, og nogle drivere behandler også localhost særligt. Kontroller, hvad din klient gør, i stedet for at antage, at flaget blev overført. Databasekontoen skal også have en bevilling, der matcher den kilde, serveren ser, og det er videresendelsesværten, ikke din bærbare.

Stop, hvis værktøjet ikke kan tvinges over på TCP. Brug så en anden klient, eller brug direkte adgang til den private listener.

Trin 4: bevis, hvilket endepunkt du faktisk nåede

Spørg serveren, hvad den mener, forbindelsen er. Variablerne for værtsnavn, port og socket fortæller, om du ankom over TCP, og hvilken listener der svarede, og forbindelseslisten viser den kildeadresse, serveren registrerede. Det bevis er mere nyttigt end endnu en ruteændring.

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

Noter, hvilket endepunkt du forsøgte: en lokal Unix-socket, din videresendelsesport eller den private listener. De tre fejl har forskellige løsninger, og at ændre VPN-ruten, mens klienten stadig taler med den forkerte localhost, er spildt arbejde. Hold også SSH-godkendelse og databasegodkendelse adskilt i noterne, fordi en fejl i den ene ser ud som en fejl i den anden fra en desktopklient. Fjern derefter videresendelsen, når du er færdig.

Tjeklisten slutter, når du kan navngive endepunktet, klientprotokollen, den kildeadresse serveren så, og den bevilling, der tillod det. Fire fakta, og det næste forbindelsesproblem tager minutter i stedet for en eftermiddag.