MySQL localhost через VPN: це досі локальний процес

База даних, яку застосунок називає localhost, розташована на сервері, а не на вашому ноутбуці. Використайте приватний слухач або SSH-перекидання, потім змусьте клієнт працювати через TCP.

Застосунок на офісному сервері підключається до 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, і автентифікацію бази, бо невдача в одній з настільного клієнта виглядає як невдача в іншій. Потім приберіть перекидання, коли закінчите.

Список закінчується, коли ви можете назвати кінцеву точку, протокол клієнта, адресу джерела, яку бачив сервер, і дозвіл, який це дозволив. Чотири факти, і наступна проблема зі з'єднанням займає хвилини, а не півдня.

Схожі статті