MySQL localhost över en VPN: det betyder fortfarande den lokala processen

Applikationen på kontorsservern ansluter till MySQL på localhost, du kopierar det värdnamnet till en skrivbordsklient, och anslutningen misslyckas eller öppnar en annan databas. VPN ändrade inget i ordets betydelse: localhost syftar fortfarande på maskinen som kör klienten. VPN flyttade paket, inte gränssnitt. Bestäm vilken ändpunkt laptopen ska nå innan du rör en rutt.

Steg 1: bestäm vilken ändpunkt laptopen ska nå

Båda designerna är legitima och svarar på olika frågor. Direkt åtkomst innebär att databasen lyssnar på en privat adress som tunneln når, och laptopen ansluter till den adressen. Vidarebefordrad åtkomst innebär att databasen stannar på loopback och en SSH-session bär porten till din maskin. Välj en medvetet, eftersom att blanda dem ger en anslutning som fungerar av fel anledning.

För direkt åtkomst, hämta databasvärdens eget privata namn eller adress och dess port från den som driftar den. VPN-gatewayens adress är inte databasens adress om det inte är samma maskin. Bekräfta sedan att lyssnaren verkligen är bunden till det gränssnittet, eftersom en rutt till ett gränssnitt inte skapar en lyssnare där.

Steg 2: vidarebefordra porten bara om lyssnaren stannar lokalt

Om databasen ska stanna bara på loopback, vidarebefordra den över SSH och bind den lokala änden till loopback också. Bindadressen till vänster tillhör din laptop; målet till höger tolkas från SSH-serverns sida, som OpenSSH-referensen beskriver. Att byta plats på de två rollerna är det vanliga skälet till att en vidarebefordran verkar fungera men inte ansluter till något.

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

Om SSH landar på en hoppvärd i stället för databasvärden, syftar loopbacken till höger på hoppvärden, och målet måste ändras till en adress som den värden når. ExitOnForwardFailure fångar ett misslyckande att upprätta vidarebefordran, men bevisar inte att senare anslutningar till målet lyckas. Håll värdnyckelkontrollen på och erbjud inte vidarebefordringsporten till hela ditt LAN genom att binda den till alla gränssnitt.

Stoppa om databasen måste stanna bara på loopback och du inte kan använda SSH. Då är direkt åtkomst fel design, inte en konfiguration att tvinga fram.

Steg 3: tvinga klienten till TCP

På Unix väljer en MySQL-klient som får localhost en Unix-socket som standard, så om du bara ändrar porten kan den bli stående och leta efter en socket som inte har något med din vidarebefordran att göra. Använd den uttryckliga TCP-protokollen och loopback-adressen för att få klienten att öppna en anslutning till din vidarebefordringsport.

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

Lösenordsalternativet utan värde frågar i stället för att sätta hemligheten på kommandoraden, och det är vanan som är värd att behålla. Andra verktyg har sin egen brytare för samma åtskillnad, och vissa drivrutiner behandlar localhost också särskilt. Kontrollera vad din klient gör i stället för att anta att flaggan följde med. Databaskontot behöver också en behörighet som matchar den källa servern ser, och det är vidarebefordringsvärden, inte din laptop.

Stoppa om verktyget inte kan tvingas till TCP. Använd då en annan klient, eller använd direkt åtkomst till den privata lyssnaren.

Steg 4: bevisa vilken ändpunkt du faktiskt nådde

Fråga servern vad den tror att anslutningen är. Variablerna för värdnamn, port och socket berättar om du kom via TCP och vilken lyssnare som svarade, och anslutningslistan visar källadressen servern registrerade. Det beviset är mer användbart än ännu en ruttändring.

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

Anteckna vilken ändpunkt du försökte: en lokal Unix-socket, din vidarebefordringsport eller den privata lyssnaren. De tre felen har olika åtgärder, och att ändra VPN-rutten medan klienten fortfarande talar med fel localhost är slöseri med arbete. Håll också SSH-autentisering och databasautentisering åtskilda i anteckningarna, eftersom ett fel i den ena ser ut som ett fel i den andra från en skrivbordsklient. Ta sedan bort vidarebefordran när du är klar.

Checklistan slutar när du kan namnge ändpunkten, klientprotokollet, källadressen servern såg och behörigheten som tillät det. Fyra fakta, och nästa anslutningsproblem tar minuter i stället för en eftermiddag.