Ssh tunnel from linux to linux

Как получить доступ к серверу Linux за NAT через обратный туннель SSH

Оригинал: How to access a Linux server behind NAT via reverse SSH tunnel
Автор: Dan Nanni
Дата публикации: May 4, 2015
Перевод: Н.Ромоданов
Дата перевода: сентябрь 2015 г.

Вы запустили Linux-сервер дома, который находится за маршрутизатором NAT или защищен брандмауэром. Теперь, когда вы находитесь не дома, вам нужен доступ к домашнему серверу через SSH. Как это настроить? Возможным вариантом будет, безусловно, перенаправление на порт SSH. Однако перенаправление портов может оказаться более сложным в случае, если у вас среда с несколькими вложенными NAT. Кроме того, на выбранное решение могут оказывать влияние различные ограничения, устанавливаемые интернет-провайдерами, например, ограничительные брандмауэры провайдеров, которые блокируют перенаправление портов или NAT с трансляцией адресов, что позволяет пользователям одновременно пользоваться одними и теми же адресами IPv4.

Что такое обратное туннелирование SSH?

Одной из альтернатив перенаправлению портов SSH является обратное туннелирование SSH. Концепция реверсного туннелирования SSH сравнительно проста. Для этого вам понадобится еще один хост (так называемый «хост релея»), находящийся за пределами защищенной домашней сети, к которому вы можете подключиться через SSH из либого места независимо от того, где вы находитесь. Вы можете настроить хост релея на отдельном экземпляре виртуального частного сервера VPS, использующего общедоступный адрес IP. После этого все, что вам потребуется сделать, это настроить постоянный туннель SSH туннель от сервера в вашей домашней сети на хост общественного релея. Благодаря этому вы можете подключаться «в обратном направлении» к домашнему сервера с хоста релея (именно поэтому такой туннель называется «обратным» туннелем). Д тех пор, пока хост релея доступен для вас, вы можете подключиться к домашнему серверу из любого места, где бы вы не находились, причем независимо от того, используется ли в вашей домашней сети ограничивающий NAT или брандмауэр.

Настройка в Linux обратного туннелирования SSH

Давайте посмотрим, каким образом можно создавать и использовать обратный туннель SSH. Предположим следующее. Мы будем настраивать обратный туннель SSH от домашнего сервера homeserver к серверу релея relayserver , так что мы можем получать доступ через SSH к homeserver через relayserver с некоторого другого компьютера, который называется клиентским компьютером clientcomputer . Общедоступным адресом сервера релея relayserver является 1.1.1.1.

На сервере homeserver открываем соединение SSH к серверу релея relayserver следующим образом.

Здесь порт 10022 является портом с любым номером, который вы выберите. Просто убедитесь, что на сервере relayserver этот порт не используется другими программами.

Параметр «-R 10022:localhost:22» определяет ревесный туннель. Он перенаправляет трафик с порта 10022 сервера relayserver на порт 22 на сервере homeserver

Благодаря параметру «-fN» SSH уйдет в фоновый режим сразу, как только вы успешно пройдете проверку подлинности на сервере SSH. Этот параметр полезен в случае, если вы не хотите на удаленном сервере SSH выполнять какие-либо команды, а просто хотите, как в нашем случае, использовать перенаправление портов.

После запуска указанной выше команды вы вернетесь обратно к командной строке сервера homeserver .

Войдите на сервер relayserver и убедитесь, что 127.0.0.1:10022 привязан к sshd . Если это так, то это означает, что обратный туннель настроен правильно.

Теперь с любого другого компьютера (например, с клиента clientcomputer ) войдите на сервер relayserver . Затем получите доступ к серверу homeserver следующим образом.

Единственное, на что следует обратить внимание, это то, что логин/пароль, который вы набираете для localhost , должен быть для сервера homeserver , а не для серевера relayserver , поскольку вы через локальную конечную точку туннеля вошли на сервер homeserver . Так что не вводите логин/пароль для сервера relayserver . После успешного входа в систему, вы будете находиться на сервере homeserver .

Прямое подключение к серверу с NAT через обратный туннель SSH

Хотя описанный выше метод позволяет вам получить доступ к серверу homeserver , который находится за NAT, вам протребуется входить дважды: сначала — на сервер relayserver , а затем — на сервер homeserver . Это связано с тем, что конечная точка туннеля SSH на сервере relayserver привязана к адресу loopback (127.0.0.1).

Но на самом деле, есть способ получить доступ к серверу homeserver , который закрыт NAT, с помощью одного входа на сервер relayserver . Для этого вам нужно сделать, чтобы sshd, расположенный на сервере relayserver , мог перенаправлять порт не только с адреса loopback но и с внешнего хоста. Это достигается путем указания параметра GatewayPorts в sshd , работающего на сервере relayserver .

Откройте файл /etc/ssh/sshd_conf на сервере relayserver и добавьте к нему следующее.

В системе на основе Debian:

В системе на основе Red Hat:

Теперь давайте инициализируем обратный туннель SSH из homeserver следующим образом.

Войдите на сервер relayserver и убедитесь с помощью команды netstat в том, что обратный туннель SSH успешно установлен.

В отличие от предыдущего случая, конечной точкой туннеля теперь является 1.1.1.1:10022 (общедоступный адрес IP сервера relayserver ), а не 127.0.0.1:10022. Это означает, что конечная точка туннеля доступна с внешнего хоста.

Теперь для того, чтобы получить доступ к серверу homeserver , защищенному NAT, введите на любом другом компьютере (например, на клиентском компьютере clientcomputer ), следующую команду.

Хотя в приведенной выше команде 1.1.1.1 является общедоступным адресом IP сервера relayserver , homeserver_user должен быть учетной записью на сервере homeserver . Это связано с тем, что реальный хост, на который вы входите, это homeserver , а не relayserver . Последний просто ретранслирует ваш трафик SSH трафик на сервер homeserver .

Настройка в Linux постоянного обратного туннеля SSH

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

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

В качестве первого шага, давайте установим возможность беспарольного входа через SSH с сервера homeserver на сервер relayserver . Таким образом, программа autossh сможет без вмешательства пользователя перезапускать пропавший обратный туннель SSH.

Затем на сервере homeserver , откуда начинается туннель, установите программу autossh .

На сервере homeserver запустите autossh со следующими аргументами с тем, чтобы создать постоянный туннель SSH, действующий в направлении сервера relayserver .

Параметр «-M 10900» указывает порт на сервере relayserver , для которого будет осуществляться мониторинг и который будет использоваться для обмена тестовыми данными при контроле сессии SSH. Этот порт не должен на сервере relayserver использоваться какой-либо другой программой.

Параметр «-fN» перенаправляется в команду ssh , что позволит туннелю SSH работать в фоновом режиме.

Параметр «-o XXXX» сообщает команде ssh следующее:

• Использовать ключ аутентификации, а не парольную аутентификацию.
• Автоматически принимать (неизвестные) ключи хоста SSH
• Каждые 60 секунд обмениваться сообщениями keep-alive.
• Отправлять до трех сообщений keep-alive без получения каких-либо ответов.

Остальные параметры обратного туннелирования SSH те же самые, что и в предыдущих примерах.

Если вы хотите, чтобы туннель SSH автоматически поднимался при загрузке системы, вы можете в /etc/rc.local добавить указанную выше команду autossh .

Заключение

В этой статье было рассказано о том, как можно использовать обратный туннель SSH для доступа к серверу Linux, который находится за брандмауэром или шлюзом NAT, защищающего сеть от внешнего мира. Было продемонстрировано, как это сделать для случая домашней сети с помощью общедоступного виртуального частного сервера VPS. Вы должны быть внимательны при использовании этого приема для корпоративных сетей. Такой туннель может рассматриваться как нарушение корпоративной политики, поскольку он позволяет обойти корпоративные брандмауэры и может открыть корпоративные сети для внешних атак. Существует большая вероятность, что этот подход может использоваться неправильно или с заведомо плохими целями. Так всегда помнить, что прежде всего вы сами ответственны за все настройки, которые вы осуществляете.

Источник

Создание SSH-туннеля. Часть первая

SSH туннель — это туннель, создаваемый посредством SSH соединения и используемый для шифрования туннелированных данных. Используется для того, чтобы обезопасить передачу данных в интернете. Особенность состоит в том, что незашифрованный трафик какого-либо протокола шифруется на одном конце SSH соединения и расшифровывается на другом.

Строго говоря, SSH-туннели не являются полноценными туннелями и это название следует рассматривать как сложившееся в профессиональной среде устойчивое наименование. Официальное название технологии — SSH Port Forwarding — это опциональная возможность протокола SSH, которая позволяет передать TCP-пакет с одной стороны SSH-соединения на другую и произвести в процессе передачи трансляцию IP-заголовка по заранее определенному правилу.

Понять, как работает SSH туннель очень просто: если представить его в виде point-to-point соединения. Так же как и в PPP, любой пакет, попавший в один конец соединения, будет передан и получен на другом конце туннеля. Дальше, в зависимости от адреса получателя, заданного в IP заголовке, пакет будет либо обработан принимающей стороной туннеля (если пакет предназначается непосредственно ей), либо смаршрутизирован дальше в сеть (если адресатом является другой узел сети).

Проброс локального соединения на удаленную машину

После этого все соединения на ЛокальныйАдрес:ЛокальныйПорт будут перебрасываться удаленному серверу, который будет соединяться с АдресНазначения:ПортНазначения от своего имени.

Проброс удаленного соединения на локальную машину

Для совершения обратного действия нужно выполнить команду с ключом -R :

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

Примеры проброса соединения

У меня физический компьютер с двумя виртуальными машинами. На физической машине — Windows 10 и установлены web-сервер Apache и сервер БД MySQL. На виртуальной машине ssh-server — Ubuntu 18.04 и установлен SSH-сервер. На виртуальной машине web-server — Ubuntu 18.04 и установлен web-сервер Apache и сервер БД MySQL.

• Физическая машина TKMCOMP , ОС Windows 10, ip-адрес 192.168.110.2
• Виртуальная машина ssh-server , ОС Ubuntu 18.04, ip-адрес 192.168.110.8
• Виртуальная машина web-server , ОС Ubuntu 18.04, ip-адрес 192.168.110.12

Все машины находятся в одной локальной сети — для удобства проведения экспериментов с построением туннелей. Хотя с практической точки зрения нужен компьютер с белым ip-адресом и с установленным ssh-сервером — который будет посредником между двумя компьютерами с серыми ip-адресами.

На виртуальной машине web-server работает web-сервер Apache — если на физическом компьютере открыть в браузере страницу http://192.168.110.12 , то увидим дефолтную страницу Apache:

На физической машине TKMCOMP тоже работает web-сервер Apache — если открыть в браузере страницу http://127.0.0.1 , то увидим вывод php-функции phpinfo() :

На виртуальной машине ssh-server необходимо открыть порт для ssh-соединений. У меня это — 2222:

Проброс локального соединения на удаленную машину

Открываем на физической машине PowerShell и выполняем команду:

• точка входа в туннель — физическая машина TKMCOMP , интерфейс localhost
• точка выхода из туннеля — виртуальная машина ssh-server , интерфейс localhost
• пункт назначения tcp-пакетов — виртуальная машина web-server

Теперь у нас есть туннель от 192.168.110.2 до 192.168.110.8: пакеты от физической машины попадают в туннель и будут получены виртуальной машиной ssh-server . А поскольку пункт назначения 192.168.110.12 — пакеты будут направлены дальше в сеть, к виртуальной машине web-server .

На физической машине открываем в браузере страницу http://127.0.0.1:8080 — и видим дефолтную страницу Apache:

Проброс удаленного соединения на локальную машину

Открываем на физической машине PowerShell и выполняем команду:

• точка входа в туннель — виртуальная машина ssh-server , интерфейс localhost
• точка выхода из туннеля — физическая машина TKMCOMP , интерфейс localhost
• пункт назначения tcp-пакетов — физическая машина TKMCOMP (пакеты предназначены ей)

Теперь у нас есть туннель от 192.168.110.8 до 192.168.110.2: пакеты от виртуальной машины ssh-server попадут в туннель и будут получены физической машиной. Откроем на виртуальной машине ssh-server браузер и наберем в адресной строке http://192.168.110.8:8080 или http://127.0.01:8080 . Мы видим вывод функции phpinfo() от web-сервера физической машины:

Однако, если мы откроем браузер на виртуальной машине web-server и наберем в адресной строке http://192.168.110.8:8080 — то ничего не увидим:

Пакеты от виртуальной машины web-server придут на сетевой интерфейс enp0s3 виртуальной машины ssh-server . А перенаправляются в туннель только те пакеты, которые пришли на интерфейс обратной петли loopback . Чтобы это исправить, нужно изменить настройки ssh-сервера — отредактировать файл конфигурации /etc/ssh/sshd_config :

Но это очень радикальный путь, лучше использовать опцию -g в команде создания туннеля. Она действует аналогично GatewayPorts , но уменьшает риск забыть от этой настройке ssh-сервера, когда в ней уже не будет необходимости.

Источник