Задача: Доступ к множеству устройств по SSH по доменным именам через сервер с 1 реальным IP. Возможно ли?

Question

[insekt]

Привет, хабралюди.

Столкнулся тут с одной задачей и не знаю есть ли для неё решение. Суть такова.


Есть несколько сотен устройств (что-то типа датчика, с ОС Линукс на борту), которые подключены к Интернету через сотовую сеть. Все устройства подключаются туннелем к серверу в Интернете, сервер имеет 1 реальный IP. При подключении к серверу устройству выдается внутренний IP и имя вида deviceID.mydomain.com. Вопрос. Возможно ли в данной ситуации как-то настроить сервер, чтобы он при обращении по ssh на доменое имя редиректил на внутренний IP устройства? Т.е. чтобы ssh соединение устанавливалось напрямую между пк администратора и устройством.

Answer 1

[J_o_k_e_R]

Вам поможет IPv6. Если реальник статический, то 6to4, иначе туннельные брокеры и 6in4. Вам выдадут подсеть, которую хватит намного больше, чем на сотни устройств. А дальше прописывайте AAAA записи в DNS так, как Вам будет угодно.

Comments

[insekt]

Вы имеете ввиду, что всем внутренним устройствам выдавать v6 адреса?

[J_o_k_e_R]

Да, конечно. Вот пара ссылок в помощь:

version6.ru/6to4/howto
version6.ru/6to4/to-lan

[insekt]

Что-то я до конца не понимаю как это будет работать.
Предположим что всем внутренним устройствам выдал v6 адреса и сделал записи в DNS. Далее с пк с v4 адресом набирает команду ssh deviceID.mydomain.com, а далее что, кто-что ресолвит, где происходит трансляция? Можете вкратце пояснить как пакет с пк админа дойдет до устройства?

[J_o_k_e_R]

У компа админа естественно так же должен быть IPv6. Через 6to4 или 6in4 (туннельный брокер). А дальше хотите по домену обращайтесь, хотите по прямым IPv6 адресам устройств. Только на сервере не забудьте фаервол настроить, чтоб лишний трафик до датчиков не пускать.

[ValdikSS]

Т.к. у автора мобильный оператор, и с большой вероятностью есть NAT, то нужно использовать teredo, т.к. 6to4 не заработает в этом случае. Это я про датчики. На компе админа может быть какой угодно способ подключения ipv6.

[J_o_k_e_R]

Т.к. у автора мобильный оператор, и с большой вероятностью есть NAT, то нужно использовать teredo, т.к. 6to4 не заработает в этом случае. Это я про датчики. На компе админа может быть какой угодно способ подключения ipv6.

У автора туннель от датчиков до сервера с реальником. Через него и можно выдавать ипы из подсети, полученной через 6to4 на этот реальник.

[Slipeer]

Так, на всякий случай, а устройства то сами ipv6 умеют? А то всяко бывает…

Answer 2

[artyomst]

как вариант — посмотреть в сторону nginx с модулем proxy_pass

Answer 3

[sledopit]

man iptables port forwarding ( ну или просто погуглить iptables проброс порта ).
upd. это в случае, если на устройстве, куда надо попасть, стоит свой ssh server.

Answer 4

[Пума Тайланд]

а что вам мешается коннектиться к впн и обращаться по внутренним адресам?

Comments

[shadowalone]

Так я тоже самое предложив выше. Но ответили как-то непонятно :)

Answer 5

[Slipeer]

Читать здесь про проброс авторизации.

Comments

[Slipeer]

Пардон — недоглядел про доменные имена.
С доменными именами не получится:
На сервер с реальным ip будут приходить пакеты с targetip = рельному ip. информации о том из какого DNS имени клиент получил этот ip не будет.
Посмотрите всё-таки в сторону туннелирования через сервер с реальным ip. Если критично обращаться по имени — настройте на клиенте хосты для подключения к разным серверам в «серой» сети.

[insekt]

Огромное спасибо за ссылочку.
Я так понимаю, что вариант с pipe как раз то, что нужно. Может сразу подскажите, при использовании такой настройки можно будет обращаться ко внутренним хостам про по ssh deviceID.mydomain.com и использовать для этого любой ssh клиент?

[Slipeer]

Если критично обращаться по имени — настройте на клиенте хосты для подключения к разным серверам в «серой» сети.

Тут я погорячился — в секции Host нее удастся задать команду для выполнения на удалённом хосте :( Придётся делать либо алиасы команд в шеле либо настраивать подключения в Putty

при использовании такой настройки можно будет обращаться ко внутренним хостам про по ssh deviceID.mydomain.com и использовать для этого любой ssh клиент?

Нет. Так не получится. Можно сделать алиас для ssh вроде:

alias sshconnect='ssh -A <белый ip либо dns хоста с белым ip> ssh '

И пользоваться им:

sshconnect <имя хоста с серым ip либо его серый ip>

Причём имя хоста с «серым» ip должно разворачиваться на хосте с «белым» ip в «серый» ip. И совсем не обязательно должно разворачиваться на клиентском ПК.

[3vi1_0n3]

В таком варианте у вас работает? Я тоже об этом подумал, но как-то так:

$ ssh user@external "/usr/bin/ssh user@internal-123"
user@external's password:
Pseudo-terminal will not be allocated because stdin is not a terminal.
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).

[Slipeer]

Я забыл опцию -t.
Должно быть

ssh -t user@external "/usr/bin/ssh user@internal-123"

Answer 6

[joneleth]

Ничего не понятно. Что за туннель? Каким образом выдается IP и доменное имя? Устройства и ПК администратора в одной локальной сети или нет?

Comments

[insekt]

Отвечу по порядку:
1. Туннель GRE с шифрованием, чтобы не светить передеваемые данные в Интеренете. Туннель между датчиком и сервером в Интернете. Туннель инициируется со стороны датчика, так как он находится за NATом мобильного оператора. Туннель поддерживается в активном состоянии.
2. После установления туннеля в DNS на сервере заносится запись deviceID = IP внутренний. IP сейчас задаются вручную при настройке датчика.
3. Устройства и ПК админов/операторов находятся в разных сетях, но все имеют доступ в Интернет к серверу.

[joneleth]

Ну ответ на вопрос — никак «напрямую» соединение установлено быть не может, в любом случае все пойдет через сервер. Операторы тоже по gre подключаются или просто SSH? Где находится ДНС, на том же сервере?

[insekt]

По поводу «напрямую» я имел ввиду, что необходима только одна сессия между пк админа и датчиком. То что она будет проходить через сервер это не страшно, важно чтобы на сервере не осуществлялась терминация ssh сессии.
От оператора только доступ в Интернет (EDGE/3G). GRE делают сами устройства, там линукс (какая точно версия сейчас не скажу).
DNS сейчас поднят на сервере.

[joneleth]

Ничего хорошего в голову не приходит. Есть NAT, но там порты надо указывать. Есть вот такой костыль serverfault.com/questions/329529/virtual-hosts-for-ssh

Answer 7

[merlin-vrn]

Прямо «как написано», конечно, сделать нельзя. Есть коммерческие SSH, которые умеют коннектиться через-сервер — в них коннктиться к шлюзу, а с него автоматически к нужному хосту.

С OpenSSH можно сделать так: NAT и пробрасывать на разные хосты разные порты, скажем, 22000 на одно устройство, 22001 — на другое.
А чтобы порты не запоминать, имена сделать разные — прописать в .ssh/config
Host: bla1
Port: 22100

Host: bla2
Port: 22101

и так далее, а сами bla1 и bla2 сделать алиасами одного и того же белого адреса. Вот вам и будет — ssh bla1 попадёт на порт 22100 и пробросится на одно устройство, ssh bla2 — на порт 22001 и попадёт на второе, но, конечно, только на том компе, где config настроили.

Лучше не сделаете.

Comments

[insekt]

Как уже говорил, это вариант рассматривался, но пока ищуются другие варианты.

[merlin-vrn]

Как я уже сказал, никакого «виртуального хостинга» в протоколе SSH нет, «другие варианты» кроме вышеперечисленных невозможны. Либо шлюз-ssh, либо nat.

Answer 8

[zibada]

Можно сделать через authorized_keys.

Заводим специального пользователя, ему в ~/.ssh/authorized_keys добавляем ключи всех клиентов.
Напротив каждого ключа можно прописать дополнительные параметры ssh, в том числе есть параметр command, который принудительно запускает команду при авторизации по этому ключу, командой делаем старт локальной ssh-сессии.
Получается что-то вроде:

command="ssh 10.0.1.1" ssh-rsa AAA...A+p1 client1
command="ssh 10.0.1.2" ssh-rsa AAA...A+p1 client2
...

После чего все клиенты просто соединяются с основным сервером на его обычный порт.

С авторизацией на самих внутренних устройствах возможны варианты, например, private-ключи для авторизации на них можно выложить на основном сервере и указывать через параметр -i в команде.

Comments

[impass]

при необходимости парольной аутентификации можно насоздавать на шлюзе N юзеров, каждому из которых прописать в качестве шелла некий скрипт, инициирующий дальнешее подключение во внутренней сети

Answer 9

[insekt]

Скажите, реально ли сделать так?
1. Админ с ПК делает запрос ssh deviceID.mydomain.com. За ответ на запрос отвечает только мой DNS сервер.
2. При ответе на DNS запрос сервер смотрит на поля SRC IP и PORT и создает временную запись в таблице форвардинга.
SRC IP1 PORT1 DST IP SERVER PORT 22 => SRS IP1 PORT1 DST IP HOST123 PORT 22
3. Когда придет запрос от другого ПК, то этот запрос будет иметь дургие значение SRC IP и PORT и соответственно для него будет своя запись.

Comments

[insekt]

deviceID.mydomain.com = IP HOST123

[Slipeer]

Поделитесь веществами — тоже хочу!

А что с Вашим «велосипедом» будет если:
1. Один клиент попытается подключиться к двум разным серым хостам? Пусть даже и по-очереди?
2. Несколько клиентов будут работать с одного ip (терминальынй сервер/NAT/несколько разных консолей)?

И да… боюсь Вам придётся написать свою реализацию DNS сервера.

[insekt]

Да, я понимаю что из области научной фантатики =) но вдруго кого-то на интересную мысль натолкнет.

[insekt]

Ну и все таки попробую ответить на ваши вопросы из спортивного интереса =)
1. Клиент подклчается на 2 хоста, т. е. делает запросы на deviceID1 и deviceID2 соответственно будет две разные записи в НАТ трансляции.
2. Тут не будет отличается от обычной ситуации когда с одного пк несколько сессий открывается. Каждая сессия будет иметь уникальный SRC PORT. При прохождении НАТ это значение сохранится (как правило) или назначится другое уникально.
С DNS делать ничего не надо будет. Надо будет написать небольшой модуль, который будет отслеживать ресолвы и создавать/удалять записи в НАТ трансляции.

[merlin-vrn]

Нет, ваши 1 и 2 работать не будут.

Клиент с IP1 подключается первый раз, для него создаётся трансляция from IP1 to port 22-> dnat to IntIP1:22
Когда он подключается второй раз (а первая сессия активна), потребуется сделать трансляцию вида from IP1 to port 22 -> dnat to IntIP2:22, что невозможно, не удаляя первую. DNS-серверу, делающему трансляцию, неизвестно ничего про SRC-порты, а особенно — какой порт будет выбран системой для ещё не установленног соединения. Итого, более одной сессии с одного удалённого адреса сделать не удастся.

Ерунду вы придумываете, ей-богу.

[insekt]

Да, согласен. Разбили в пух и прах. Как говорится, надежда умерает последней.
Просто как-то не дает покоя мысль, что не элегантного решения для такой задачи =( вот в голову всякая абракатабка и лезет.

[Slipeer]

Это решение ничуть не элегантно, более того — это не решение ;)

Answer 10

[shadowalone]

По-моему самое простое, это поднять на этом сервере vpn, админ подключается по впн к серверу и запросто заходит на все адреса внутренних устройств напрямую.

Comments

[insekt]

Это то понятно. Простые и очевидные решения понятны и известны. Хочется найти красивое решение. Плюс я не упоминал такой момент, операторы, инициирующие ssh сессии — это пользователи 3-х фирм и пускать их на наш сервер ой как не хочется. Гемора с секурностью столько возникнет, что эта задача покажется невинной шалостью.

[shadowalone]

как раз используя vpn Вы ни на какой сервер их не пускаете, просто прогоняете траффик до конечных устройств через сервер. При любом раскладе так и выходит.

А вот как раз, как советуют выше, с ключами на сервере и т.д., тогда да.

Если бы устройств было ни так много (10-30), я бы просто повесил проброс с разных портов и сделал конфиг файл, как советовали выше, но так как устройств много, и скорее всего они будут прибавляться, vpn — лучший выход.
Разрешите впн-юзерам обращение только к необходимым хостам/сетям, и задача решена.

[insekt]

Тогда мне надо заморачиваться тем, чтобы у всех кто подключается была возможность создавать VPN и поддерживать этих пользователей. Среди тех кто подключается есть не только админы (знающие люди), но и много обычных операторов (простые юзеры), кто по бумажке подключается и выполняет стантартные действия.

[shadowalone]

Зачем Вам кого-то поддерживать то? написали стандартную инструкцию по подключению к впн для основных ОС, и послали все клиентам.
если люди подключаются из одной организации(сети), то впн настраивает их админ (не у них локально, а на своем оборудовании, и прописывает маршруты).

Answer 11

[ZetaNeta]

Можно, через iptables