Построение защищенных туннелей (ssh)

Построение защищенных туннелей (ssh)

План:

1. Введение
2. Локальный зашифрованный туннель
3. Удаленный зашифрованный туннель
4. Динамический туннель (socks-proxy)
5. Используемая и рекомендуемая литература.

1. Введение

Представим, что нам нужно подключиться к компьютеру, имеющему серый ip-адрес. Чисто логически, как это можно реализовать? По-любому, между сервером (у которого серый адрес) и клиентом (у которого все равно какой адрес) должен быть какой-то промежуточный хост с внешним адресом, который будет ловить соединения от клиента и перебрасывать каким-либо образом серверу. Можно это реализовать с помощью iptables (DNAT), а можно другим интересным способом, имеющим некоторые принципиальные отличия.
Во-первых, в случае использования защищенного туннеля ssh соединение будет зашифровано так, как будто используется зашифрованный VPN-канал. Кстати, некоторые администраторы преподносят этот способ именно как замену vpn.
Во-вторых, DNAT способен соединить нас с "серым" сервером только в том случае, когда у компьютера, на котором настроен этот самый DNAT имеется маршрут до "серого" сервера (например, они в одной подсети). А при использовании данного метода это обстоятельство совсем не обязательно. Так же, мы сможем решить проблему соединения с серым сервером в том случае, когда он находится за шлюзом, доступ к которому мы получить не можем.

Итак, что мы должны иметь для решения задачи доступа к "серому" серверу:
1) Серый сервер - сервер с запущеными на нем службами и с серым ip-адресом. В этой роли может выступать, например, linux-компьютер или любая клиентская windows-машина c vnc или radmin в качестве сервиса.
2) Белый сервер - управляемый нами linux-сервер с внешним ip-адресом. Он может быть как в одной подсети с Серым сервером, так и в разных. Управляемый - это значит, что у нас есть определенные права доступа к данному серверу по протоколу ssh.
3) Клиент - компьютер, с которого подразумевается соединение к Серому серверу. Он должен иметь удаленный доступ к Белому серверу, что вполне очевидно.

Имеются два варианта решения задачи подключения Клиента к Серому серверу, различающиеся положением Белого сервера в цепочке подключений.

2. Локальный зашифрованный туннель

Сначала рассмотрим тот случай, когда Серый сервер и Белый сервер находятся в разных подсетях и Белый не имеет маршрута до Серого.

Такая задача является самой распространенной и её не решить с помощью DNAT. В данном случае необходимо инициировать тунель от Серого сервера к Белому серверу, в результате которого Белый сервер будет слушать соединения на каком-то из заранее свободных портов и передавать их Серому, т.е. запускать соединения в зашифрованный тунель, выход из которого ведет к Серому серверу. Кстати, выход из этого тунеля на стороне Серого сервера еще не подразумевает конец пути: можно настроить так, что Серый сервер будет перенаправлять вышедшие из тунеля соединения далее к компьютерам, к которым он имеет маршруты.

В случае использования на Сером сервере операционной системы linux (или bsd, разница между которыми в данном случае не принципиальна), это соединение (тунель) устанавливается путем подключения Серого к Белому по протоколу ssh с некоторыми определенными опциями. Опции, которые нам понадобятся, таковы:
а) " -N " Не выполнять никаких команд на Белом сервере после инициализации соединения (т.е. просто повиснуть и все, как раз разработана для установки тунелей). В противном случае у нас будет возможность управлять Белым сервером, но это лишнее, так что отключаем.
б) " -R port:host:hostport " Установить тунель, вход в который будет на Белом сервере, т.е. Белый сервер будет слушать соединения на порте "port", передавать их по зашифрованному тунелю Серому серверу, который в свою очередь будет их при выходе из тунеля перенаправлять в расшифрованном виде на компьютер host (например localhost) на порт hostport.
в) " -g " По-умолчанию, инициированный тунель принимает соединения только от того компьютера, на котором располагается вход в этот тунель. Это сделано в целях безопасности. Данный ключ отменяет это ограничение.

Итак, ближе к делу. На Сером сервере выполняем:
Код: Выделить всё
ssh -N -g -R 6003:localhost:22 user@whiteip
Если демон ssh висит на Белом сервере на другом порте (например 2345), то комманда будет выглядеть так:
Код: Выделить всё
ssh -N -g -p 2345 -R 6003:localhost:22 user@whiteip
whiteip - адрес (ip или полное интернет-имя) Белого сервера. Нам понадобится пароль пользователя user на Белом сервере, а в случае инициации тунеля скриптом, который не сможет ввести пароль, необходимо использовать беспарольную авторизацию по ключам. Далее, из любого места мы можем соединиться с Белым сервером на порт 6003 и в итоге получим подключение к Серому серверу на порт 22. Если бы мы вписали вместо << 6003:localhost:22 >> нечто такое << 6003:192.168.0.2:22 >>, то мы получили бы соединение не с Серым сервером, а с компьютером, находящимся с Серым сервером в одной подсети и имеющим адрес 192.168.0.2.

3. Удаленный зашифрованный туннель

Теперь рассмотрим тот случай, когда Серый сервер и Белый сервер находятся в одной подсети.

Лично я в таком случае предпочитаю использовать DNAT на Белом сервере, но для полноты картины опишем и эту возможность тунелирования. В данном случае трафик, проходящий через интернет, шифруется. На Клиентском компьютере инициируется тунель, ведущий к Белому серверу, при выходе из которого трафик заворачивается на Серый сервер. При этом в тунель может попасть трафик и от соседних для Клиента компьютеров.
Код: Выделить всё
ssh -N -g -L 3389:192.168.0.2:3389 user@whiteip

4. Динамический туннель (socks-proxy)

У ssh есть еще одна интересная возможность - организовывать socks-proxy-server. Для этого необходимо выполнить команду
Код: Выделить всё
ssh -D ip:port user@server
server - компьютер, на котором хотим повесить socks-proxy
user - пользователь на компьютере server
ip - адрес компьютера server, на котором будет висеть socks-proxy
port - порт, на котором будет висеть socks-proxy
В самом простом случае команда будет выглядеть так:
Код: Выделить всё
ssh -D 62.5.246.190:8080 user@localhost

После чего мы можем запустить любое сетевое приложение, поддерживающее соединение через socks-proxy (у меня под рукой оказалось таких два: openvpn-client-gui и аська qip). В настройках которых я прописал ip-адрес 62.5.246.190 и порт 8080 (без аутентификации).

5. Используемая и рекомендуемая литература.

Перенаправление портов в SSH
Howto perform UDP tunneling through SSH connection
Поддержание SSH-туннеля в активном состоянии при помощи Auto