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 хваща неуспеха да се установи препратката, но не доказва, че по-късните връзки към целта успяват. Оставете проверката на ключа на хоста включена и не предлагайте порта за препратка на цялата си LAN, като го вържете към всички интерфейси.

Спрете, ако базата данни трябва да остане само на 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 удостоверяването и удостоверяването на базата данни отделно в бележките, защото провал в едното изглежда като провал в другото от настолен клиент. После премахнете препратката, когато приключите.

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