MySQL localhost via een VPN: het blijft het lokale proces

De applicatie op de kantoorserver verbindt met MySQL op localhost, je kopieert die hostnaam naar een desktopclient, en de verbinding mislukt of opent een andere database. De VPN heeft niets aan de betekenis van het woord veranderd: localhost verwijst nog steeds naar de machine waarop de client draait. De VPN verplaatste pakketten, geen interfaces. Bepaal welk eindpunt de laptop moet bereiken voordat je een route aanraakt.

Stap 1: bepaal welk eindpunt de laptop moet bereiken

Beide ontwerpen zijn legitiem en beantwoorden verschillende vragen. Directe toegang betekent dat de database luistert op een privéadres dat de tunnel bereikt, en de laptop verbindt met dat adres. Doorgestuurde toegang betekent dat de database op loopback blijft en een SSH-sessie de poort naar je machine draagt. Kies er bewust één, want ze mengen levert een verbinding op die om de verkeerde reden werkt.

Vraag voor directe toegang de eigen privénaam of het adres van de databasehost en de poort op bij wie hem beheert. Het adres van de VPN-gateway is niet het databaseadres, tenzij het dezelfde machine is. Bevestig daarna dat de listener echt aan die interface gebonden is, want een route naar een interface maakt daar geen listener.

Stap 2: stuur de poort alleen door als de listener lokaal blijft

Als de database alleen op loopback moet blijven, stuur hem dan door via SSH en bind ook het lokale uiteinde aan loopback. Het bindadres links hoort bij je laptop; het doel rechts wordt uitgelegd vanuit de SSH-server, zoals de OpenSSH-referentie beschrijft. Die twee rollen omdraaien is de gebruikelijke reden dat een doorstuur lijkt te werken maar nergens mee verbindt.

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

Als SSH op een spronghost landt in plaats van op de databasehost, verwijst de loopback rechts naar de spronghost, en het doel moet veranderen in een adres dat die host bereikt. ExitOnForwardFailure vangt een fout bij het opzetten van de doorstuur, maar bewijst niet dat latere verbindingen naar het doel slagen. Houd de host-sleutelcontrole aan en bied de doorgestuurde poort niet aan je hele LAN aan door hem aan alle interfaces te binden.

Stop als de database alleen op loopback moet blijven en je geen SSH kunt gebruiken. Dan is directe toegang het verkeerde ontwerp, geen configuratie om te forceren.

Stap 3: dwing de client naar TCP

Op Unix kiest een MySQL-client die localhost krijgt standaard een Unix-socket, dus alleen de poort wijzigen kan hem laten zoeken naar een socket die niets met je doorstuur te maken heeft. Gebruik het expliciete TCP-protocol en het loopbackadres om de client een verbinding naar je doorgestuurde poort te laten openen.

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

De wachtwoordoptie zonder waarde vraagt ernaar in plaats van het geheim op de opdrachtregel te zetten, en dat is de gewoonte die je wilt houden. Andere hulpmiddelen hebben hun eigen schakelaar voor hetzelfde onderscheid, en sommige stuurprogramma's behandelen localhost ook apart. Controleer wat je client doet in plaats van aan te nemen dat de vlag is meegekomen. Het databaseaccount heeft ook een recht nodig dat past bij de bron die de server ziet, en dat is de doorgestuurde host, niet je laptop.

Stop als het hulpmiddel niet naar TCP kan worden gedwongen. Gebruik dan een andere client, of gebruik directe toegang tot de privé-listener.

Stap 4: bewijs welk eindpunt je werkelijk hebt bereikt

Vraag de server wat hij denkt dat de verbinding is. De variabelen voor hostnaam, poort en socket vertellen of je via TCP kwam en welke listener antwoordde, en de verbindingenlijst toont het bronadres dat de server vastlegde. Dat bewijs is nuttiger dan nog een routewijziging.

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

Noteer welk eindpunt je hebt geprobeerd: een lokale Unix-socket, je doorgestuurde poort of de privé-listener. Die drie fouten hebben verschillende oplossingen, en de VPN-route wijzigen terwijl de client nog met de verkeerde localhost praat is verspilde moeite. Houd in de notities ook SSH-authenticatie en database-authenticatie gescheiden, want een fout in de ene lijkt vanuit een desktopclient op een fout in de andere. Verwijder daarna de doorstuur als je klaar bent.

De checklist eindigt wanneer je het eindpunt, het clientprotocol, het bronadres dat de server zag en het recht dat het toestond kunt benoemen. Vier feiten, en het volgende verbindingsprobleem kost minuten in plaats van een middag.