Переадресация SSH-порта на хост, которому необходимо связаться с третьим хостом для доступа к MySQL
Мы настраиваем и поддерживаем стандартные веб-приложения, которые наши клиенты размещают на управляемых серверах от разных веб-хостеров. Обычно приложение состоит из веб-приложения на 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.
1 ответ
Вам не нужен 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 локально, чтобы заставить данные проходить через ssh stdio, и удаленный socat, чтобы перенаправить их в соответствующий сокет. Чтобы это работало, у вас должен быть уже работающий ssh без пароля:
socat TCP-LISTEN:44014 EXEC:"ssh user@serverb socat STDIO TCP:serverc:3306"