MySQL localhost przez VPN: to nadal oznacza proces lokalny

Aplikacja na serwerze biurowym łączy się z MySQL pod localhost, kopiujesz tę nazwę hosta do klienta desktopowego, a połączenie albo zawodzi, albo otwiera inną bazę danych. VPN niczego nie zmienił w znaczeniu tego słowa: localhost nadal oznacza maszynę, na której działa klient. VPN przeniósł pakiety, a nie interfejsy. Zdecyduj, do którego punktu końcowego laptop ma dotrzeć, zanim tkniesz trasę.

Krok 1: zdecyduj, do którego punktu końcowego laptop ma dotrzeć

Oba projekty są zasadne i odpowiadają na różne pytania. Dostęp bezpośredni oznacza, że baza danych nasłuchuje na prywatnym adresie osiągalnym przez tunel, a laptop łączy się z tym adresem. Dostęp przekierowany oznacza, że baza pozostaje na loopbacku, a sesja SSH przenosi port na twoją maszynę. Wybierz jeden świadomie, bo mieszanie ich daje połączenie, które działa z niewłaściwego powodu.

Dla dostępu bezpośredniego zdobądź własną prywatną nazwę lub adres hosta bazy i jego port od tego, kto nim zarządza. Adres bramy VPN nie jest adresem bazy, chyba że to ta sama maszyna. Potem potwierdź, że nasłuch jest rzeczywiście przypisany do tego interfejsu, bo trasa do interfejsu nie tworzy na nim nasłuchu.

Krok 2: przekieruj port tylko wtedy, gdy nasłuch pozostaje lokalny

Jeśli baza ma pozostać tylko na loopbacku, przekieruj ją przez SSH i przypisz także lokalny koniec do loopbacku. Adres przypisania po lewej należy do twojego laptopa; cel po prawej jest interpretowany od strony serwera SSH, jak opisuje dokumentacja OpenSSH. Zamiana tych dwóch ról to zwykła przyczyna tego, że przekierowanie wydaje się działać, ale do niczego się nie łączy.

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

Jeśli SSH trafi na host skoku zamiast na host bazy, loopback po prawej odnosi się do hosta skoku, a cel trzeba zmienić na adres, który ten host osiąga. ExitOnForwardFailure wychwytuje niepowodzenie ustanowienia przekierowania, ale nie dowodzi, że późniejsze połączenia z celem się udają. Zostaw włączone sprawdzanie klucza hosta i nie oferuj portu przekierowania całej swojej sieci LAN, przypisując go do wszystkich interfejsów.

Zatrzymaj się, jeśli baza musi pozostać tylko na loopbacku, a nie możesz użyć SSH. Wtedy dostęp bezpośredni to zły projekt, a nie konfiguracja do wymuszenia.

Krok 3: wymuś na kliencie TCP

W Uniksie klient MySQL, któremu podano localhost, domyślnie wybiera gniazdo uniksowe, więc zmiana samego portu może zostawić go szukającego gniazda, które nie ma nic wspólnego z twoim przekierowaniem. Użyj jawnego protokołu TCP i adresu loopback, aby klient otworzył połączenie z twoim portem przekierowania.

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

Opcja hasła bez wartości pyta, zamiast umieszczać sekret w wierszu poleceń, i to nawyk wart zachowania. Inne narzędzia mają własny przełącznik dla tego samego rozróżnienia, a niektóre sterowniki traktują localhost także wyjątkowo. Sprawdź, co robi twój klient, zamiast zakładać, że flaga się przeniosła. Konto bazy potrzebuje też uprawnienia zgodnego ze źródłem, które widzi serwer, a to host przekierowania, nie twój laptop.

Zatrzymaj się, jeśli nie da się wymusić na narzędziu TCP. Wtedy użyj innego klienta albo dostępu bezpośredniego do prywatnego nasłuchu.

Krok 4: udowodnij, do którego punktu końcowego faktycznie dotarłeś

Zapytaj serwer, czym jego zdaniem jest połączenie. Zmienne nazwy hosta, portu i gniazda mówią, czy przyszedłeś przez TCP i który nasłuch odpowiedział, a lista połączeń pokazuje adres źródłowy, który serwer zapisał. Ten dowód jest użyteczniejszy niż kolejna zmiana trasy.

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

Zapisz, którego punktu końcowego próbowałeś: lokalnego gniazda uniksowego, portu przekierowania czy prywatnego nasłuchu. Te trzy niepowodzenia mają różne poprawki, a zmiana trasy VPN, gdy klient nadal rozmawia z niewłaściwym localhostem, to zmarnowany wysiłek. W notatkach trzymaj też osobno uwierzytelnianie SSH i uwierzytelnianie bazy, bo niepowodzenie jednego wygląda z klienta desktopowego jak niepowodzenie drugiego. Potem usuń przekierowanie, gdy skończysz.

Lista kończy się, gdy potrafisz nazwać punkt końcowy, protokół klienta, adres źródłowy widziany przez serwer i uprawnienie, które to umożliwiło. Cztery fakty, a następny problem z połączeniem zajmuje minuty zamiast popołudnia.