MySQL localhost через VPN: это по-прежнему локальный процесс

Приложение на офисном сервере подключается к MySQL по адресу localhost, вы копируете это имя хоста в настольный клиент, и соединение либо не удаётся, либо открывает другую базу данных. VPN ничего не изменил в значении слова: localhost по-прежнему означает ту машину, на которой запущен клиент. VPN переместил пакеты, а не интерфейсы. Решите, до какой конечной точки должен добраться ноутбук, прежде чем трогать маршрут.

Шаг 1: решите, до какой конечной точки должен добраться ноутбук

Обе схемы законны и отвечают на разные вопросы. Прямой доступ означает, что база данных слушает приватный адрес, до которого достаёт туннель, и ноутбук подключается к этому адресу. Переброшенный доступ означает, что база остаётся на loopback, а сеанс SSH переносит порт на вашу машину. Выберите одну осознанно, потому что их смешение даёт соединение, которое работает по неверной причине.

Для прямого доступа возьмите собственное приватное имя или адрес хоста базы и его порт у того, кто ею управляет. Адрес шлюза VPN не является адресом базы, если это не та же машина. Затем убедитесь, что слушатель действительно привязан к этому интерфейсу, потому что маршрут к интерфейсу не создаёт на нём слушателя.

Шаг 2: перебрасывайте порт только если слушатель остаётся локальным

Если база должна оставаться только на loopback, перебросьте её через SSH и привяжите локальный конец тоже к loopback. Адрес привязки слева принадлежит вашему ноутбуку; цель справа интерпретируется со стороны SSH-сервера, как описывает справочник OpenSSH. Путаница этих двух ролей — обычная причина того, что переброс выглядит работающим, но ни к чему не подключается.

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

Если SSH попадает на промежуточный хост, а не на хост базы, loopback справа относится к промежуточному хосту, и цель нужно сменить на адрес, до которого этот хост достаёт. ExitOnForwardFailure перехватывает неудачу установки переброса, но не доказывает, что последующие соединения с целью удаются. Оставьте проверку ключа хоста включённой и не предлагайте порт переброса всей вашей локальной сети, привязав его ко всем интерфейсам.

Остановитесь, если база должна оставаться только на loopback, а SSH использовать нельзя. Тогда прямой доступ — неверная схема, а не конфигурация, которую нужно навязать.

Шаг 3: заставьте клиент работать через TCP

В Unix клиент MySQL, получивший localhost, по умолчанию выбирает Unix-сокет, поэтому смена только порта может оставить его в поисках сокета, не имеющего отношения к вашему перебросу. Используйте явный протокол TCP и адрес loopback, чтобы клиент открыл соединение с вашим портом переброса.

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

Опция пароля без значения спрашивает, а не помещает секрет в командную строку, и это привычка, которую стоит сохранить. У других инструментов есть свой переключатель для того же различия, а некоторые драйверы обращаются с localhost тоже особо. Проверьте, что делает ваш клиент, вместо того чтобы предполагать, что флаг перенёсся. Учётной записи базы тоже нужно разрешение, соответствующее источнику, который видит сервер, а это хост переброса, а не ваш ноутбук.

Остановитесь, если инструмент нельзя заставить работать через TCP. Тогда используйте другой клиент или прямой доступ к приватному слушателю.

Шаг 4: докажите, до какой конечной точки вы действительно добрались

Спросите сервер, чем он считает соединение. Переменные имени хоста, порта и сокета говорят, пришли ли вы по TCP и какой слушатель ответил, а список соединений показывает адрес источника, который сервер записал. Это доказательство полезнее очередной смены маршрута.

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

Запишите, какую конечную точку вы пробовали: локальный Unix-сокет, ваш порт переброса или приватный слушатель. У этих трёх неудач разные исправления, а смена маршрута VPN, пока клиент ещё говорит с неверным localhost, — напрасный труд. Держите в заметках отдельно и аутентификацию SSH, и аутентификацию базы, потому что неудача в одной из настольного клиента выглядит как неудача в другой. Затем уберите переброс, когда закончите.

Список заканчивается, когда вы можете назвать конечную точку, протокол клиента, адрес источника, который видел сервер, и разрешение, которое это позволило. Четыре факта, и следующая проблема с соединением занимает минуты вместо половины дня.