MySQL localhost prin VPN: înseamnă în continuare procesul local

Aplicația de pe serverul biroului se conectează la MySQL la localhost, copiezi acel nume de gazdă într-un client desktop, iar conexiunea fie eșuează, fie deschide altă bază de date. VPN-ul nu a schimbat nimic în sensul cuvântului: localhost se referă în continuare la mașina care rulează clientul. VPN-ul a mutat pachete, nu interfețe. Decide la ce punct final trebuie să ajungă laptopul înainte de a atinge o rută.

Pasul 1: decide la ce punct final trebuie să ajungă laptopul

Ambele variante sunt legitime și răspund la întrebări diferite. Accesul direct înseamnă că baza de date ascultă pe o adresă privată la care ajunge tunelul, iar laptopul se conectează la acea adresă. Accesul redirecționat înseamnă că baza rămâne pe loopback și o sesiune SSH duce portul la mașina ta. Alege una deliberat, pentru că amestecarea lor produce o conexiune care funcționează din motivul greșit.

Pentru acces direct, obține numele sau adresa privată proprie a gazdei bazei de date și portul ei de la cine o administrează. Adresa gateway-ului VPN nu este adresa bazei de date decât dacă este aceeași mașină. Apoi confirmă că ascultătorul este într-adevăr legat de acea interfață, pentru că o rută către o interfață nu creează un ascultător pe ea.

Pasul 2: redirecționează portul doar dacă ascultătorul rămâne local

Dacă baza de date trebuie să rămână doar pe loopback, redirecționeaz-o prin SSH și leagă și capătul local la loopback. Adresa de legare din stânga aparține laptopului tău; ținta din dreapta este interpretată din partea serverului SSH, cum descrie referința OpenSSH. Inversarea acestor două roluri este motivul obișnuit pentru care o redirecționare pare să funcționeze, dar nu se conectează la nimic.

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

Dacă SSH ajunge pe un host de salt în loc de gazda bazei de date, loopback-ul din dreapta se referă la hostul de salt, iar ținta trebuie schimbată într-o adresă la care ajunge acel host. ExitOnForwardFailure prinde o eroare la stabilirea redirecționării, dar nu dovedește că conexiunile ulterioare la țintă reușesc. Ține activă verificarea cheii gazdei și nu oferi portul de redirecționare întregii tale rețele LAN legându-l la toate interfețele.

Oprește-te dacă baza de date trebuie să rămână doar pe loopback și nu poți folosi SSH. Atunci accesul direct este varianta greșită, nu o configurație de impus.

Pasul 3: forțează clientul pe TCP

Pe Unix, un client MySQL căruia i se dă localhost alege implicit un socket Unix, așa că schimbarea doar a portului îl poate lăsa să caute un socket care nu are nimic de-a face cu redirecționarea ta. Folosește protocolul TCP explicit și adresa loopback pentru ca clientul să deschidă o conexiune la portul tău de redirecționare.

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

Opțiunea de parolă fără valoare întreabă în loc să pună secretul pe linia de comandă, și acesta este obiceiul care merită păstrat. Alte instrumente au propriul comutator pentru aceeași distincție, iar unii driveri tratează și localhost special. Verifică ce face clientul tău în loc să presupui că indicatorul a fost transmis. Contul bazei de date are nevoie și de o permisiune care să corespundă sursei pe care o vede serverul, iar aceea este gazda de redirecționare, nu laptopul tău.

Oprește-te dacă instrumentul nu poate fi forțat pe TCP. Atunci folosește alt client sau accesul direct la ascultătorul privat.

Pasul 4: dovedește la ce punct final ai ajuns de fapt

Întreabă serverul ce crede că este conexiunea. Variabilele de nume de gazdă, port și socket îți spun dacă ai venit prin TCP și care ascultător a răspuns, iar lista de conexiuni arată adresa sursă pe care serverul a înregistrat-o. Acea dovadă este mai utilă decât încă o schimbare de rută.

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

Notează la ce punct final ai încercat: un socket Unix local, portul tău de redirecționare sau ascultătorul privat. Aceste trei eșecuri au remedii diferite, iar schimbarea rutei VPN în timp ce clientul vorbește încă cu localhost-ul greșit este efort irosit. Ține separate în notițe și autentificarea SSH și autentificarea bazei de date, pentru că un eșec într-una arată ca un eșec în cealaltă dintr-un client desktop. Apoi elimină redirecționarea când ai terminat.

Lista se termină când poți numi punctul final, protocolul clientului, adresa sursă pe care a văzut-o serverul și permisiunea care a permis-o. Patru fapte, iar următoarea problemă de conexiune durează minute în loc de o după-amiază.