Этот пример связан с MongoDB, но основная проблема связана с туннелированием SSH, но материал MongoDB должен добавить ценность.
Здравствуй,
Я пытаюсь вызвать локальный узел MongoDB, который является частью ReplicaSet, расположенного в центре обработки данных. TCP / IP будет туннелироваться через SSH от локального до дата-центра.
Все боксы, локальные и дата-центры, работают под управлением CentOS.
Это отлично работает при создании туннеля в дата-центре box1 к локальному узлу, используя:
ssh -v -4 -f -N -o TCPKeepAlive=no -o ServerAliveInterval=15 -L27017:127.0.0.1:27017 -g a_user@server_i_have_ssh_access_to
box1 может получить доступ к оболочке Mongo локального узла с помощью команды (cmd 1):
mongo --host localhost --port 27017
box2 также может получить доступ к оболочке Mongo локального узла с помощью команды (cmd 2):
mongo --host box1 --port 27017
box2 в дата-центре также может подключаться к box1: 27017, перенаправленному порту моего локального узла.
однако было бы намного предпочтительнее, проще и должна быть возможность настроить обратный прямой переход между локальным узлом и box1 на тех же портах, что и выше. Используя команду:
ssh -v -4 -f -N -o TCPKeepAlive=no -o ServerAliveInterval=15 -R27017:127.0.0.1:27017 -g a_user@box1
теперь я могу подключиться из box1 к локальному узлу, используя cmd 1 выше, однако, cmd 2 не работает с:
Error: couldn't connect to server box1:27017} (anon):1139 exception: connect failed
Любые идеи?
По умолчанию -R слушает только интерфейс loopback (по умолчанию для -L есть все интерфейсы). Следовательно, cmd1 работает, потому что он запускается локально на box1, но cmd2 не работает, потому что он запускается на box2. Исправление заключается в изменении -R одному из:
-R:27017:127.0.0.1:27017
-R'*:27017:127.0.0.1:27017'
Все, о чем я могу думать, это TCP Wrappers или какая-то другая аутентификация не работает. Что-нибудь в /var/log/auth.log если это ОС на базе Debian или аналогичная?