Мы настраиваем и поддерживаем стандартные веб-приложения, которые наши клиенты размещают на управляемых серверах различных веб-хостеров. Обычно приложение состоит из веб-приложения на PHP и базы данных (в основном MySQL).
Для наших клиентов мы хотим предложить услугу резервного копирования, которая выходит за рамки того, что предлагают веб-хостеры (обычно срок хранения составляет четыре недели). Мы хотим сделать резервную копию веб-приложения (нет проблем) и базы данных (проблема).
Один из веб-хостеров имеет настройку, которая предотвращает доступ пользователя к базе данных MySQL с помощью mysql.sock. Вместо этого у них есть отдельное имя (например, user123.mydatabaseserver.com) для самого управляемого сервера. Подключение к базе данных возможно только с помощью -h параметр для mysql, как это:
mysql -u mydbuser -p -h user123.mydatabaseserver.com
Теперь обычно мы делаем резервную копию баз данных с нашего резервного сервера, используя SSH-туннель, который подключается к живому управляемому серверу, и порт перенаправляет порт MySQL на резервный сервер, затем подключается к базе данных на резервном сервере через туннель и запускается mysqldump с переадресованным портом. Однако из-за параметра принудительного имени хоста это невозможно в данном случае.
Мы знаем, что можем подключиться к управляемому серверу, выгрузить туда базу данных, а затем скопировать полученный файл резервной копии, используя scp или какие-то другие меры, но я хотел увидеть, не упускаю ли я что-то, что позволило бы нам не использовать хранилище и / или время вычислений живого управляемого сервера для этой резервной копии.
Есть ли решение, использующее только переадресацию портов?
Изменить 1: Попытка сделать проблему более ясной
Сервер A (система резервного копирования) Сервер B (сервер приложений) Сервер C (сервер базы данных)
Сервер A должен создать резервную копию базы данных на сервере C. Однако разрешения на доступ MySQL позволяют только серверу B подключаться к серверу C и получать доступ к базе данных.
В этом конкретном случае сервер B и сервер C имеют одинаковый IP-адрес, но кажется, что хостер отключил доступ к MySQL через сокеты и разрешает только соединения TCP / IP.
Между тем, у меня возникла идея связать порт SSH вперед:
Свяжите порт 22222 на сервере B с портом 3306 на сервере C, затем привяжите 44014 на сервере A к 22222 на сервере B. Однако попытка SSH на сервере C с сервера B приводит к сообщению об ошибке: host address xxx.xx.xxx.xx not allowed.
Вам не нужен SSH-туннель для перехода от B к C, поскольку веб-приложение на B подключается к C с помощью обычных сокетов, верно?
На сервере A вы должны вызвать SSH следующим образом:
ssh -L44014:serverc:3306 user@serverb
Это устанавливает SSH-туннель между A и B. Когда ваш процесс резервного копирования, запущенный на сервере A, подключается к localhost: 44014, туннель заставит процесс sshd на сервере B подключиться к порту 3306 на сервере C. Из точки сервера C Похоже, что соединение приходит с сервера b на какой-то случайный клиентский порт.
Если вы хотите использовать это в сценарии, вы также можете передать -N вариант, чтобы не порождать оболочку, просто перенаправьте порт. Таким образом, вы можете запустить команду в фоновом режиме и убить ее, когда туннель вам больше не нужен:
ssh -NL44014:serverc:3306 user@serverb &
TUNNEL_PID=$!
# do the backup on localhost:44014
kill $TUNNEL_PID
Если администраторы сервера B отключили перенаправление локального порта, вы можете использовать socat имитировать это поведение, но это немного сложнее. Здесь мы создаем один socat локально, чтобы данные проходили через stdio ssh, и удаленный socat для перенаправления их в соответствующий сокет. Чтобы он работал, у вас должен быть уже работающий вход без пароля по ssh:
socat TCP-LISTEN:44014 EXEC:"ssh user@serverb socat STDIO TCP:serverc:3306"