Назад | Перейти на главную страницу

autossh не работает для двух и более туннелей - или есть альтернатива?

Я пытаюсь использовать SSH-сервер в качестве шлюза для подключения к больше, чем один внутренние серверы. Внутренний в этом контексте означает, что они не доступны напрямую, им не назначен публичный IP-адрес.

Таким образом, сценарий должен выглядеть следующим образом (пример с 2 серверами, может быть больше) с общедоступным IP-адресом шлюза 123.456.789.45, внутренним - 10.12.40.13.

+--------+                 +---------+                +----------+
| client |--> 2214/tcp --> |         | --> 22/tcp --> | Server 1 |
+--------+                 |         |                +----------+
                           | Gateway |
+--------+                 |         |                +----------+
| client |--> 2215/tcp --> |         | --> 22/tcp --> | Server 2 |
+--------+                 +---------+                +----------+

Мой первый подход состоял в том, чтобы настроить их от шлюза до серверов с чем-то вроде

ssh -N -L 123.456.789.45:2214:127.0.0.1:22 tunnel-user@server1
ssh -N -L 123.456.789.45:2215:127.0.0.1:22 tunnel-user@server2

Пока это работает, я столкнулся с проблемой того, что туннели не слишком надежны и дают сбой то здесь, то там. Следующим логическим шагом была попытка получить autossh Бег. И тут у меня куча проблем. Первый туннель можно без проблем установить, используя

autossh -M 20000 -f -N -L 123.456.789.45:2214:127.0.0.1:22 tunnel-user@server1

Я могу получить доступ к server1, подключившись к шлюзу через порт 2214 извне. Однако я не могу запустить и запустить второй с помощью autossh. Покатавшись пару часов сейчас, я решил попробовать наоборот. Так:

Второй подход заключался в том, чтобы настроить их с серверов на шлюз. Опять же, хотя вариант с чистым ssh работает примерно так ...

ssh -R 123.456.789.45:2214:127.0.0.1:22 tunnel-user@gateway # <- init from server 1
ssh -R 123.456.789.45:2215:127.0.0.1:22 tunnel-user@gateway # <- init from server 2

... использование autossh не работает.

autossh -M 20000 -f -R 123.456.789.45:2214:127.0.0.1:22 tunnel-user@gateway

Журналы просто ничего не говорят. Системный журнал по крайней мере придумывает

ssh exited prematurely with status 0; autossh exiting

Кто-нибудь знает, как решить autossh проблема при любом подходе? Есть что-то похожее на autossh что я могу дать шанс? Есть ли способ добиться чего-то вроде обновления чистой версии ssh, упомянутой выше?

На всех задействованных серверах установлены последние обновления Ubuntu 10.04 LTS и autossh 1.4b.

ssh ssh-tunnel

Из документации autossh:

autossh использует ssh для построения цикла пересылки ssh (от локального к удаленному, от удаленного к локальному), а затем отправляет тестовые данные, которые он ожидает получить обратно.

-M порт [: echo_port] указывает используемый базовый порт мониторинга. Без эхо-порта этот порт и порт непосредственно над ним (порт + 1) должны быть чем-то другим, что не используется. autossh отправит тестовые данные на базовый порт мониторинга и получит их обратно на порт выше. Например, если вы укажете «-M 20000», autossh настроит переадресацию, чтобы он мог отправлять данные на порт 20000 и получать их обратно на 20001.

если вы дважды используете -M 20000, это не должно произойти. Используйте для этого разные порты (с одним пространством между ними, поэтому -M 20000 и -M 20002 будут работать). Я рекомендую выполнить "man autossh" и прочитать документацию по autossh, она также доступна в Интернете: http://www.manpagez.com/man/1/autossh/ . Если вы используете много туннелей autossh, вы можете настроить специальную службу эха (снова из документации autossh):

В качестве альтернативы может быть указан порт для удаленной эхо-службы. Это должен быть порт 7, если вы хотите использовать стандартную службу эха inetd. Когда указан эхо-порт, используется только указанный порт монитора, и он передает сообщение монитора в обоих направлениях. Это позволяет autossh проверять соединение без блокировки портов для каждого туннеля на удаленной стороне.

Если вы хотите использовать для этого xinetd, вот мое отклонение эхо-службы:

service echo
{
        flags                   = REUSE
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/bin/cat
        log_on_failure          += USERID
        only_from               = 127.0.0.1
        disable                 = no
}

тогда вы можете использовать -M 20000: 7 для всех туннелей с разных машин. если у вас несколько туннелей на одном компьютере, используйте несколько параметров -L или -R или используйте другой порт, например -M 20002: 7

Вы можете указать оба туннеля в одной команде ssh.

ssh -R 123.456.789.45:2214:127.0.0.1:22 -R 123.456.789.45:2215:127.0.0.1:22 tunnel-user@gateway

Или вы можете попробовать добавить туннели в файл .ssh / config следующим образом, чтобы командная строка не была слишком переполнена:

host server1
        RemoteForward 123.456.789.45:2214:127.0.0.1:22
        RemoteForward 123.456.789.45:2215:127.0.0.1:22

не знаю про автосш ....

но почему бы вам не попробовать параметр конфигурации ssh ProxyCommand? (http://undeadly.org/cgi?action=article&sid=20070925181947)

вам нужно будет настроить .ssh / config в клиентах следующим образом:

Host Server1
    HostName Server1
    ProxyCommand ssh gateway:2214 nc %h %p 2> /dev/null

удачи!

Вы можете настроить несколько туннелей в автосшфайл конфигурации. К сожалению, это не очень хорошо задокументировано. Для двух туннелей с указанными вами данными и на основе PubkeyAuthentication я бы сделал это так (SuSE 11 SP 4):

    In /etc/sysconfig/autossh

    # Number of autossh instances to spawn on start.
    AUTOSSH_SPAWNS="3"

    # All options except for the first must end with "_<number>"

    AUTOSSH_OPTIONS_1="tunnel-user1@server1 \
    -i /home/tunnel-user1/.ssh/id_rsa \
    -M 0 -f -N -L2214:127.0.0.1:22 -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=60 -o ServerAliveCountMax=3 
    -o StrictHostKeyChecking=no"

    AUTOSSH_OPTIONS_2="tunnel-user2@server2 \
    -i /home/tunnel-user2/.ssh/id_rsa \
    -M 0 -f -N -L2215:127.0.0.1:22 -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=60 -o ServerAliveCountMax=3
    -o StrictHostKeyChecking=no"

Конечно, все остальное, что касается успешного ssh-соединения с ключами, должно быть на месте

pub ключи туннелей-пользователей на серверах
/home/tunnel-user[1|2]/.ssh/authorized_keys файлы
туннель-пользователь должен существовать на шлюзах и серверах
и быть настроенным в /etc/ssh/sshd_config
на шлюзе sshd_config AllowTcpForwarding должен быть установлен yes так же как PermitTunnel

Я использовал другой подход для решения этой проблемы. Сначала мне удалось запустить туннели SSH от клиентов во время загрузки. Я написал для этого сценарий init.d, сделал его сервисом и позволил марионетке обрабатывать его.

Однако это было слишком хлопотно, и я решил развернуться и использовать NAT и переадресацию портов через сервер шлюза и его конфигурацию UFW. Несмотря на то, что это не ответ на проблему SSH, вот решение, устраняющее основную проблему:

В /etc/ufw/sysctl включен net/ipv4/ip_forward=1 и побежал sysctl -p

В /etc/ufw/before.rules

*nat
:POSTROUTING ACCEPT [0:0]

# forward traffic from eth1 through eth0
-A POSTROUTING -s 10.12.40.0/24 -o eth0 -j MASQUERADE

# some DNAT rules
-A PREROUTING -i eth0 -p tcp --dport 2214 -j DNAT --to-destination 10.12.40.14:22
-A PREROUTING -i eth0 -p tcp --dport 2215 -j DNAT --to-destination 10.12.40.15:22

#
COMMIT

и побежал ufw disable && ufw enable. Все, что нужно было, кроме проверки правильности маршрутизации на клиенте.

Другой подход, желаемый результат. Спасибо всем, что прочитали и подумали о моей проблеме и @sonassi: Я попробую ваше предложение с OpenVPN, как только у меня появится немного больше времени и потребуется больше, чем порт SSH.