Для проведения работ у одного из клиентов понадобилось войти на сервер, который доступ к интернету имеет, но находится за NAT’ом, а значит напрямую до него не достучаться. В этом случае, на помощь приходит трюк с backconnect’ом по SSH.
На машине, которая находится за NAT’ом, ставим openssh сервер, запускаем его и выполняем вот такую команду:
# ssh -R 8222:localhost:22 admin@1.2.3.4 -p 2222
Вводим пароль для доступа по SSH и оставляем висеть сессию открытой. Если сессию оставлять открытой не хочется, можно увести процесс в фон добавив перед -R ключи -f -N.
Затем на сервере проверяем соединения, например с помощью netstat, и видим там следующее:
tcp 0 0 127.0.0.1:8222 0.0.0.0:* LISTEN 7589/sshd: root@pts
Нам остаётся просто соединиться по SSH на 127.0.0.1:8222 и мы, через поднятый туннель, попадём на машину за NAT’ом:
[root@vps451870 ~]# ssh root@127.0.0.1 -p8222 root@127.0.0.1's password: Last login: Mon Jul 10 08:29:04 2017 [root@localhost ~]#
Я этот способ так же очень часто использую, когда будучи в поездке нужно попасть на домашний ПК и забрать с него что-то.
А как забиндиться на внешний интерфейс, а не на локалхост?
Ох, как-то упустил комментарий.
А зачем биндиться на внешний интерфейс? Какую задачу, при этом, необходимо решить? Ведь тут смысл в том, что на сервере, от локалхоста и до клиента за натом поднимается туннель. Бинд на внешний интерфейс тут и не нужен, вроде бы. 🙂
А почему не пробросить порт?
Не всегда есть возможность сделать это быстро. Например, клиент оказался за натом от провайдера, плюс натом его роутера, за которым ещё своя сеть построена.
Если есть возможность быстро пробросить порт, то можно пойти и по этому пути. Бекконнект — это просто один из вариантов решения задачи 🙂