ssh и виртуализация

Самое красивое - поднять на 10.1.0.1 сервер ВПН.
Самое простое - впереть DNAT на sshd виртуалок с двух разных портов 10.1.0.1.
А подобия виртуальных хостов и реверс-проксей для ssh как-то не предусмотрено.

Есть rinetd.

Разрулить алиасами на интерфейсе. К интерфейсам прибить имена.

rinetd не решает задачу же, более того, он здесь и не нужен вовсе.
Ну алиасами оно да, красивее, чем портами.

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

Да, просто пробрасываешь порт внутрь.

Если прям совсем удобно (но не совсем безопасно), то переносишь на хосте eth0 в br0, ip-настройки поднимаешь теперь на br0. На виртуалке вручную указываешь, чтобы использовался br0. Вуаля, виртуалка сразу выкинута в локалку.

nginx и ssh вещи малосвязанные. это раз

В ssh нет такого понятия как сайт. Есть такие понятия как доменное имя и IP. Если ты пытаешься присоединится к domain.com, то сначала имя преобразуется в IP адрес, а потом происходит инициализация соединения по этому адресу.

SSH клиент не передаёт SSH серверу имя, которое использовалось при соединении.

Если у тебя vm1.com резолвится в 10.0.3.100, а 10.1.0.1 является шлюзом к 10.0.3.0/29, то твоё решение с добавлением маршрута является и верным, и удобным.

nginx и ssh вещи малосвязанные. это раз

Абстрагируйтесь от примеденных мной в пример технологий(nginx,ssh).
Nginx - это не более чем hostname. ssh не панацея (может быть как фтп, fish, spice и тд)

Если у тебя vm1.com резолвится в 10.0.3.100, а 10.1.0.1 >>является шлюзом к 10.0.3.0/29, то твоё решение с добавлением >>маршрута является и верным, и удобным.

шлюз стоит дальше - а это лишь цепочка forward в iptables разрешенная определенной подсети

(10.0.3.0/29<-forward->10.1.0.1)

Lumi писал

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

vpn - вообще не вариант. Это неправильно и неудобно
Другими словами меня интересует маршрутизация на основании hostname. Надеялся на хитрый финт ушами с использованием firewall)
например в операционных системах windows netbios имя передается вместе с пакетом

hostname<1b>: type NB, class IN

Другими словами меня интересует маршрутизация на основании hostname.

Маршрутизация чего? ssh?

например в операционных системах windows netbios имя передается вместе с пакетом

В системах windows ssh работает по другому?

http://tools.ietf.org/html/rfc4251
http://tools.ietf.org/html/rfc4253
http://tools.ietf.org/html/rfc4254

например в операционных системах windows

Так и сиди на windows.

например в операционных системах windows
Так и сиди на windows.

Прежде чем оставлять комментарии, будьте любезны сначала прочитать топик целиком, а не придираться к моментам, приведенным для примера

Маршрутизация чего? ssh?

Маршрутизация как таковая с использованием iproute и firewall

Абстрагируйтесь от примеденных мной в пример технологий(nginx,ssh). Nginx - это не более чем hostname. ssh не панацея (может быть как фтп, fish, spice и тд)

Прежде чем оставлять комментарии, будьте любезны сначала прочитать топик целиком, а не придираться к моментам, приведенным для примера
Маршрутизация как таковая с использованием iproute и firewall

Пример tcp пакета в котором указан hostname в качестве получателя в студию!

пример есть в предыдущем топике, где упоминался windows

hostname<1b>: type NB, class IN

hostname - не в качестве получателя, но тем не менее в пакете есть

hostname<1b>: type NB, class IN
hostname - не в качестве получателя, но тем не менее в пакете есть

Живой пример в студию! Без разницы, какой траффик будет, но пример в студию! Вот прям чтоб «hostname<1b>: type NB, class IN»

Как ответишь, можешь почитать следующее:

man ssh | grep protocol (network protocol)
man http | grep protocol (application protoco)
ну и самое вкусное на десерт - man OSI.

Потом расскажи нам снова, как роутить ssh, и как в windows сетевые протоколы передают в заголовках hostname. Я думаю посацы не знают.

man ssh | grep protocol (network protocol) man http | grep protocol (application protoco) ну и самое вкусное на десерт - man OSI.

Спасибо кеп!!!!
Либо вы не поняли мою мысль и то чего я хочу добиться. Либо же вы сами не понимаете о чем говорите
Какая разница какой протокол? Все пакеты приходят на layer 3 и их можно роутить на текущем уровне модели osi

Я прекрасно понял, что нужно. ssh сам по себе не подразумевает вещи, когда подключаетесь к сайту и передаёте имя домена, к которому хотите подключиться. Это всё же не уровень приложения.

Абстрагируйтесь от примеденных мной в пример технологий(nginx,ssh).

Нельзя абстрагироваться, не получится. В SSH протоколе имя не участвует в соединении, в HTTP - участвует.

Если ты хочешь, чтоб при использовании стандартного ssh клиента:

ssh vm1.com

у тебя организовывалось соединение на сервер с 10.0.3.100, то надо чтоб vm1.com резолвился на этот самый IP и правила маршрутизации приводили на нужный сервер. Иначе никак, потому что имя vm1.com не передаётся в процессе соединения.

При использовании HTTP всё по-другому, http-клиент передаёт имя домена в HTTP запросе и принимающий сервер может решить, какой контент отдавать, может и редирект сделать, если надо.

Кстати, в HTTPS обратная ситуация, там виртуальные хосты не работают по причине того, что обмен именными сертификатами для установки безопасного соединения происходит в самом начале и передача имени происходит уже после.

И из твоего вопроса непонятно, куда у тебя резолвится vm1.com.

Нельзя абстрагироваться, не получится. В SSH протоколе имя не участвует в соединении, в HTTP - участвует.

Да что ж вы уперлись в имя домена и имя сайта? cдался вам этот ssh. Не зацикливайтесь на приведенных мной в пример протоколах.
Вместо имени пусть будет хоть fqdn, пусть это будет маркировка пакетов в prerouting таблице firewall-a. Да мало-ли еще вариантов?.
Тут не важно как это будет сделано.Главное получить результат, логически, похожий реализацией на описанное мной в первом топике
без использования ненужного здесь vpn и тупых пробросов портов вида 31331--->10.0.3.100:22

Кстати, в HTTPS обратная ситуация, там виртуальные
хосты не работают по причине того, что обмен именными
сертификатами для установки безопасного соединения происходит в самом начале и передача имени происходит уже после

я думаю этот документ опровергает вашу теорию насчет https

https://www.digitalocean.com/community/articles/how-to-set-up-multiple-ssl-ce...

И из твоего вопроса непонятно, куда у тебя резолвится vm1.com.

В идеале, я хочу чтоб он резолвился на 10.1.0.1.
Да и в попросе, явно сказано, что я сейчас хожу по маршруту в подсеть vm(10.0.3.0)

в добавку

http://nginx.org/en/docs/http/configuring_https_servers.html

cat ~/.ssh/config

Host vm1.com
Port 12345

Host vm2.com
Port 54321

проброс

10.1.0.1:12345 -> 10.0.3.100:22

10.1.0.1:54321 -> 10.0.3.101:22

вы хоть читали топик?

Нет. А надо было?

Если тебе надо _все_ так пробрасывать, то забей.

я думаю этот документ опровергает вашу теорию насчет https

Ну так, добавили SNI (фактически, изменили протокол), стало возможно. Расширь протокол SSH, он тебе тоже доменное имя начнёт поддерживать. Как раз это и показывает, что такие веши протоколо-зависимы.

Да что ж вы уперлись в имя домена и имя сайта?

Вот поэтому:

Подскажите как можно при обращении на хост nginx(10.1.0.1) по имени сайта

Ты хоть замаркируйся, но при обращении по одному протоколу nginx будет видеть имя сайта, а по другому - нет.

Сделай более чёткую постановку задачи, а то дибилизм какой-то обсуждаем.

Ну да, что-то на подобии SRV записи для домена, указывающий на сервер ssh зоны было бы наверно не плохо.

А так думаю и правда никак...

Ну разве что поднять какой-нибудь ssh over http, или может как-нибудь можно настроить сокс proxy через веб, не знаю бывает ли такое или нет правда...