Туннели в SSH

 | 20.17

Мой Компьютер, №05 (509), 16.06.2008

Ответ вы уже давно знаете. Конечно, компьютер не может работать без хорошего блока питания. И этот вопрос уже рассматривался на страницах МК, однако прогресс не стоит на месте. Появляются новые процессоры, видеокарты, платы расширения и прочее. И что бы нам не рассказывали представители производителей «железа», мы-то отлично видим, что аппетиты производительных систем только растут. Четыре ядра кушают вдвое больше, чем два, и вчетверо больше, чем одно. Уменьшение техпроцесса помогает, но не решает проблему полностью. О том, что творится с видеокартами из топ-сегмента, даже вспоминать неохота. Ну, допустим, Radeon HD 2900 XT мы забыли, как страшный сон (учитывая то, что подавляющее большинство компьютеров уже на протяжении нескольких лет комплектуется блоками питания с номинальной мощностью 350-400 Ватт, потребляемые этой видеокартой 205 Вт только кошмаром и можно назвать). Но ведь вышли двухчиповые карточки GeForce 9800 GX2 и Radeon HD 3870 X2. А на подходе — еще более прожорливые новинки. Но это пока секрет, ждем, пока производитель (не скажу какой) снимет эмбарго на распространение информации (не скажу о чем)… Впрочем, в Интернете уже достаточно слухов о новом GeForce 280 GTX, энергопотребление которого предположительно будет составлять 150 Вт.

Radeon HD 2900 XT – пока что самая прожорливая видеокарта в истории РС

А ведь из него могут и «бутерброд» сделать. Наподобие 9800 GX2…

Впрочем, и без страшилок нам есть

Все действия будем производить в Ubuntu, но все сказанное актуально и для других дистрибутивов Linux, а также различных вариантов BSD-систем. В большинстве дистрибутивов, ориентированных на десктоп, SSH-сервер устанавливается по умолчанию очень редко, но клиент есть почти в каждом решении. Установить сервер в Debian/Ubuntu очень просто:

$ sudo aptitude install openssh-server

Зачем это нужно?

Вполне очевидно, что туннель, созданный с использованием OpenSSH позволит гарантированно защитить передаваемую информацию от прослушивания и перехвата. То есть его использование делает применение программ-снифферов бесполезными. Но это далеко не все.

Созданные при помощи SSH туннели имеют и другие полезные возможности. Например, использование сжатия трафика позволит уменьшить размер передаваемых данных и, соответственно, увеличить скорость передачи информации. Это могут оценить пользователи, использующие низкоскоростное модемное соединение или работающие через мобильный телефон. Для последних каждый байт трафика золотой.

Такой канал гарантирует требуемое для передачи голоса и видео QoS (Quality of Service). Некоторые сервисы вроде Rapidshare не позволяют скачивать несколько файлов с одного IP-адреса. Обойти ограничение можно при помощи прокси-сервера или туннеля, построенного при помощи SSH. Последние также дают возможность скрыть свой реальный IP. Плюс возможность обхода ограничений, установленных межсетевым экраном.

Туннели дают возможность объединить территориально разрозненные сети для удобства управления и обеспечения безопасности доступа ко внутренним ресурсам. Правда, есть одно ограничение. Туннелинг можно использовать только в том случае, когда между клиентом и сервером создается одно TCP-соединение. Например, для этого вполне подходят протоколы почтовых серверов SMTP, IMAP и POP3, web-трафик, но FTP — нет.

Перенаправление портов

Не всегда есть возможность изменить настройки SSH-сервера, но SSH-аккаунт сегодня найти не проблема. В этом случае туннель можно организовать, перенаправляя трафик с определенного порта в защищенный канал. Обращение к указанному сервису будет происходить уже на выходе канала. Форвардинг через SSH, в зависимости от того, где перенаправляются пакеты, бывает локальным или удаленным.

Локальный форвардинг организуется при помощи параметра -L в вызове команды ssh. Например, для того чтобы перенаправлять все HTTP-соединения в SSH-канал, необходимо выполнить всего одну команду:

$ ssh -l grinder remote.server.com -C -L8080:proxy.server.com:3128 -f sleep 10000

В этом примере grinder — это логин для входа на удаленный сервер remote.server.com, предоставляющий SSH-доступ. На локальной системе для приема соединений будет открыт порт 8080.

Во многих системах открывать соединения с портами ниже 1024 может только root, поэтому и был выбран порт 8080, если вас не устраивает 8080, можете выбрать любой другой — хоть 1234.

На другом конце туннеля подключившийся будет перенаправлен к порту 3128 сервера proxy.server.com. Теперь настраиваем web-браузер на выход в Интернет через прокси, находящийся по адресу localhost:8080, и подключаемся.

Для сжатия трафика OpenSSH использует алгоритм LempleZiv (LZ77), который обеспечивает такую же степень сжатия, как и ZIP. Степень сжатия потока регулируется при помощи параметров в конфигурационном файле /etc/ssh/sshd_config:

Compression yes

CompressionLevel 8

В CompressionLevel допустимо использование целых чисел в диапазоне от 1 до 9. По умолчанию установлена степень сжатия 6. При увеличении числа компрессии следует помнить, что, соответственно, увеличивается и нагрузка на процессор.

Таким же образом можно смонтировать по SSH-каналу удаленный ресурс Samba:

$ ssh -L 8139:server.com:139 [email protected]

Теперь монтируем удаленный ресурс, указав в качестве параметра вместо стандартного 139-го порта на удаленном сервере локальный порт 8139:

$ smbmount //server.com/share /mnt -o username=grinder,ip=localhost,port=8139

Аналогично можно туннелировать и трафик к сервису электронной почты. Для примера организуем передачу почты SMTP-серверу через зашифрованное и сжатое SSH-соединение:

$ ssh -C -l grinder -L 8025:server.com:25 server.com

Проверяем, подключившись к локальному порту 8025:

$ telnet localhost 8025

Trying 127.0.0.1…

Connected to localhost.

Escape character is ‘^]’.

+OK Postfix ready

В ответ получили приглашение Postfix. Такую схему можно применять, например, в том случае, когда почтовый сервер настроен на работу только с локального интерфейса (например, через web-интерфейс). Создав туннель, можно пользоваться удаленно почтовым клиентом.

Теперь настраиваем почтовый клиент для отправки сообщений через localhost:8025.

Чтобы организовать получение почты через SSH-туннель, есть несколько вариантов.

Например, мы получаем почту по протоколу POP3; настроим SSH-туннель, чтобы почта приходила по защищенному каналу (естественно, с сжатием трафика).

$ ssh -C -l grinder -L 8110:mail.server.com:110 server.com

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

$ scp -C -l grinder:/var/spool/mail/grinder /tmp/newmail

Правда, если во время копирования придет новое сообщение, то программа может повести себя не очень адекватно.

Другой вариант — использование fetchmail. Для этого создаем файл .fetchmailrc такого содержания:

poll localhost with protocol pop3 and port 8110:

 preconnect «ssh -f -q -C [email protected]

-L 8110:mail.server.com:110 sleep 10″ password [email protected];

Здесь fetchmail будет подключаться к порту 8110 локального сервера, но перед этим будет создано перенаправление трафика с этого порта на порт 110 компьютера mail.server.com.

Чтобы получить почту, вводим:

$ fetchmail

2 message for user at localhost (38452 octets).

reading message [email protected]:1 of 2 (7123 octets)……. flushed

Использование файла config

Вводить команды каждый раз неудобно. Конечно, можно все их записать в файл и, сделав его исполняемым (chmod +x), запускать. Это на порядок упростит работу.

Но более удобным вариантом настройки форвардинга мне представляется использование конфигурационных файлов: общесистемного /etc/ssh/ssh_config или личного — ~/.ssh/config. Какой из них выбрать, зависит от ситуации.

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

Но если туннелирование будет использоваться только пользователем или нет доступа к системному файлу, то редактировать следует личный файл.

Для примера настроим перенаправление входящей и исходящей почты на mail.server.com по протоколам SMTP и POP3 через защищенный туннель. Создаем такой файл:

$ vim .ssh/config

Host mail

 Hostname mail.server.com

 HostKeyAlias mail

 LocalForward localhost:8025 mail.server.com:25

 LocalForward localhost:8110 mail.server.com:110

 GatewayPorts yes

Теперь, чтобы поднять соединение, достаточно ввести в консоли:

$ ssh mail.server.com

Или используя псевдоним, указанный в HostKeyAlias:

$ ssh mail

Параметр LocalForward, как вы понимаете, соответствует настройкам, применяемым в ключе -L. Только здесь в качестве первого аргумента пишется локальный адрес и порт, а второго — адрес и порт удаленной системы, на который будет перенаправляться трафик на выходе туннеля.

Кстати, аналогичные записи в конфигурационном файле можно создать и для обычных SSH-соединений. Все с той же целью — вводить меньше параметров. Например, настроим подключение к серверу ssh1.server.com, у которого вместо 22-го порта соединения принимаются значения по 2222; учетная запись для входа — user.

$ vim .ssh/config

Host ssh1

 Hostname ssh1.server.com

 Port 2222

 User user

Теперь для подключения достаточно ввести ssh ssh1 и пароль. При большом количестве подключений очень удобно. Альтернатива такому способу — использование индивидуальных файлов с настройками. Например, все настройки подключения к некоторому сервису сохранены в файле ~/.ssh/remoteConfig. Теперь его можно вызвать, набрав:

ssh -F ~/.ssh/remoteConfig

Или создав псевдоним в файле ~/.bashrc:

alias tunnel=’ssh -v -F ~/.ssh/remoteConfig’

Теперь вы можете запускать туннель при помощи одной простой команды:

$ tunnel

Но мы немного отвлеклись. Иногда нужно, чтобы перенаправление было организовано не на локальной системе, а на удаленной. Такой вариант также предусмотрен в SSH и называется удаленный форвардинг. Организуется такой канал при помощи параметра RemoteForward:

$ vim .ssh/config

Host server

   Hostname server.com

   RemoteForward 1110:server.com:110

Теперь вводим:

$ ssh server

И канал создан.

Туннели

Создание туннеля практически аналогично форвардингу. Для этого в /etc/ssh/sshd_config на серверной стороне следует использовать параметр PermitTunnel, а на клиенской — Tunnel. Туннели в OpenSSH могут быть подняты как на втором (канальном), так и на третьем сетевом уровне OSI.

В Ubuntu Linux создание туннеля выглядит так. Сначала правим конфигурационный файл на сервере:

$ sudo vim /etc/ssh/sshd_config

# туннелирование на сетевом уровне

PermitTunnel point-to-point

# разрешаем заход root только с доверенных узлов

PermitRootLogin no

Match Host 192.168.1.*,127.0.0.1

   PermitRootLogin yes

Перезапускаем OpenSSH, чтобы он перечитал настройки:

$ sudo /etc/init.d/ssh restart

После этих шагов в системе должен появиться интерфейс tun0 (в *BSD его придется создавать вручную).

$ ifconfig tun0

 tun0   Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

   POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1

   RX packets:0 errors:0 dropped:0 overruns:0 frame:0

   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

   collisions:0 txqueuelen:500

   RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Конфигурируем его:

$ sudo ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2

Где 10.0.0.1 — это адрес сервера в туннеле, а 10.0.0.2 — адрес клиента.

Опять при помощи ifconfig проверяем его состояние:

$ ifconfig tun0

   inet 10.0.0.1 —> 10.0.0.2 netmask 0xfffffffc

Не забываем добавить в таблицу маршрутизации удаленную подсеть:

$ sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1 tun0

Второй сервер выступает в роли SSH-клиента, процедура конфигурирования здесь чуть проще. Вместо PermitTunnel пишем Tunnel, а все адреса указываем наоборот.

Теперь устанавливаем защищенное соединение между двумя узлами:

$ sudo ssh -f -w 1:1 192.168.1.1 true

Проверим доступность удаленного узла, находящегося за сервером:

$ ping 192.168.1.2

Дополнительную информацию по настройке туннеля в Ubuntu найдете в документе SSH VPN (https://help.ubuntu.com/community/SSH_VPN). Также стоит почитать документацию проекта OpenSSH.

Как видите, сервер OpenSSH позволяет не только управлять удаленной системой, но и организовывать защищенные каналы между двумя узлами или сетями.

Linux forever!

Сергей «grinder» ЯРЕМЧУК

Robo User
Web-droid editor

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *