Пробрасываем порты
Пока все нормальные люди спят, доблестный я вспоминает админские навыки и пробрасывает в ночи порты из одного NAT-а в другой.Дано.
I. Тут.
Из виртуалки тут надо прицепиться к интересующему сервису на .2 там.
Решение.
На .1 запускаем
ssh -nNT -L 192.168.1.1:123:10.1.1.2:123 -p 234 user@1.2.3.4Из виртуалки-проги лезем на 192.168.1.1:123. Profit!
Для краткости можно прописать в ~/.ssh/config
Host abc
HostName 1.2.3.4
User user
Port 234
LocalForward 192.168.1.1:123 10.1.1.2:123
IdentityFile ~/.ssh/key_rsaи запускать как
ssh -TNn abc &Подводные камни.
Не все user одинаково полезны ущемлены в правах. Потрачено слишком много времени на попытки починить то, что не сломано (и сломать то, что работает).
Пока не пришла мысль про юзера, была сделана попытка сварганить трёхзвенный костыль из отдельных форвардеров (который всё-равно из-за юзера не взлетел). Там по пути вылазили AllowTcpForwarding, GatewayPorts, PermitOpen.
Глянул повнимательней. Собственно «ущемление в правах» произошло таки из-за PermitOpen (в authorized_keys).
I. Тут.
- Локальная сеть 192.168.1.0.
- В сети машина .1, на которой настроить и запустить теоретически можно всё (если не лень; апгрейд системы и даже установку пары новых прог считаем «ленью»).
- На машине живёт виртуалка, знающая только про 192.168. Что-либо менять даже в стандартных настройках противопоказано. В виртуалке - прога, умеющая ходить лишь на 123-й порт.
- Всё это за NAT-ом. (Реально чуть сложнее, до роутера, за которым начинаются белые адресов - два хопа. :)) Теоретически, можно и тут всё перелопатить, но совершенно не хочется (и отломать что-нибудь можно, и просто леееень).
- Локальная сеть 10.1.1.0.
- В сети машина .2, на которой живёт интересующий сервис (на 123-м порту). Из маршрутизации знает только 10. Какой-либо настройке поддаётся слабо.
- Ещё есть сервер .3, с доступным ssh. Поддаётся аккуратной настройке. Физически далеко, поэтому ошибки категорически противопоказаны.
- Всё это хозяйство за NAT-ом, с единственным портом (234), проброшенным на .3-й ssh. Извне доступно по 1.2.3.4. Ненастраиваемо.
Из виртуалки тут надо прицепиться к интересующему сервису на .2 там.
Решение.
На .1 запускаем
ssh -nNT -L 192.168.1.1:123:10.1.1.2:123 -p 234 user@1.2.3.4Из виртуалки-проги лезем на 192.168.1.1:123. Profit!
Для краткости можно прописать в ~/.ssh/config
Host abc
HostName 1.2.3.4
User user
Port 234
LocalForward 192.168.1.1:123 10.1.1.2:123
IdentityFile ~/.ssh/key_rsaи запускать как
ssh -TNn abc &Подводные камни.
Не все user одинаково полезны ущемлены в правах. Потрачено слишком много времени на попытки починить то, что не сломано (и сломать то, что работает).
Пока не пришла мысль про юзера, была сделана попытка сварганить трёхзвенный костыль из отдельных форвардеров (который всё-равно из-за юзера не взлетел). Там по пути вылазили AllowTcpForwarding, GatewayPorts, PermitOpen.
Глянул повнимательней. Собственно «ущемление в правах» произошло таки из-за PermitOpen (в authorized_keys).