Безопасное соединение через Интернет средствами Secure Shell - VPN "для бедных"

В работе системного администратора рано или поздно возникает потребность в организации связи с объектами, находящимися вне LAN. Потребности могут быть самые разнообразные, в основном не зависящие от исполнителя, но способы решения проблемы неизбежно одни и те же. В простом случае это Dial-Up с его недостатками. Если есть постоянное подключение к Интернету и предприятие может себе это позволить, реализуется VPN с использованием ipsec. Эта технология впечатляет своими возможностями и перспективностью, однако отличается сложностью настройки. Что можно предложить в качестве альтернативы, учитывая что в реальной жизни редко требуется полноценное соединение с поддержкой всех протоколов TCP/IP?

Наблюдая, как специалист по оборудованию Cisco настраивает VPN, я обратил внимание, что вначале он подключается к удаленной стороне с помощью SSH (Secure Shell), и это было действительно необходимо. Таким образом, даже если у вас работает полноценный VPN, вы все равно будете иногда пользоваться SSH. Возникает резонный вопрос — можно ли обойтись одним SSH? Для большинства случаев ответ будет положительным.

Что характерно, у большинства администраторов SSH ассоциируется исключительно со значением этой аббревиатуры: Secure SHell, то бишь с удаленным исполнением комманд и передачей ввода/вывода по защищенному каналу. А ведь начиная с 2-й версии протокола (если вы не в курсе, SSH — это не только программный продукт, но и протокол) с помощью SSH можно организовать так называемое перенаправление портов (port forwarding, можно сказать и туннелирование) для пробрасывания TCP-соединений через защищенный канал.

Именно об этой возможности SSH я расскажу вам в этой статье. Тестирование проводилось на операционной системе Red Hat Linux 8.0, но отмечу, что данный продукт доступен практически на любой платформе.
Рассмотрим случай, когда необходимо связать два удаленных на значительное расстояние компьютера и обеспечить связь по какому либо “небезопасному” сервису TCP. В моем случае таковым является клиентское подключение к SAP R/3-серверу по одному из TCP-портов 3200-3299. Но в статье мы рассмотрим упрощенную ситуацию с сервисом telnet — также весьма небезопасным.
Итак, с хоста В необходим доступ к telnet-сервису на хосте А. Оба хоста являются шлюзами в Интернет для соответствующих LAN.

Проверим наличие установленных компонентов на обоих хостах:

A#rpm –qa | grep –i ssh
openssh-askpass-gnome-3.4p1-2
openssh-3.4p1-2
openssh-server-3.4p1-2
openssh-askpass-3.4p1-2
openssh-clients-3.4p1-2
kdessh-3.0.3-3

Необходимыми в данном случае являются openssh-3.4p1-2, openssh-server-3.4p1-2, openssh-clients-3.4p1-2 (это справедливо для RH 8.0, система, установленная с другого дистрибутива может утверждать, что есть только openssh-х.х-х без приставок –clients и –server. Не стоит отчаиваться раньше времени ;). Следует также отметить, что и более старые версии openssh, понимающие SSH v.2, поддерживают интересующий нас функционал.
Убедимся в том, что демон sshd стартует на нужных уровнях (опять же, справедливо для RH, если у вас другая система — придумывайте сами, как проверить ;).

A#chkconfig --list | grep ssh

Затем попробуем соединится:

A#ssh root@100.100.100.202

B#ssh root@100.100.100.201

Собственно, этот этап является самым небезопасным, потому что при первом соединении происходит обмен публичными ключами (они заносятся в файл ~/.ssh/known_hosts) партнеров по соединению. Именно в этот момент теоретически возможна атака man-in-the-middle. Разработчики SSH рекомендуют в этом случае проверить подлинность ключей, пользуясь голосовым телефоном. Для этого генерируются fingerprint ключей с помощью команды ssh-keygen –l , которые и сверяются. Но можно с уверенностью сказать, что подобные опасения должны возникать у вас действительно в исключительных случаях. Для удобства в дальнейшей работе рекомендую перейти на аутентификацию с помощью ключей, хотя парольная аутентификация тоже подойдет.
После успешного соединения можно приступать непосредственно к настройке туннеля с одного из хостов. Для этого воспользуемся встроенной в SSH функциональностью, позволяющей перенаправлять порты с одного хоста на другой через установленное SSH-соединение. Напомню, что нам необходимо получить доступ с хоста B к A, к сервису telnet.

 

Запускаем с хоста B SSH-клиент.

B#ssh –NL 50000:127.0.0.1:23 root@100.100.100.201

Опция –L означает открытие порта 50000 локально на запускающей команду машине. Опция –N означает выполнение только туннелирования, без запуска команды. Получаем слушающий порт 50000 на хосте B, который перенаправляет пакеты через соединение SSH (22 порт) на хост A в порт 23. Адрес 127.0.0.1 указывает на то, что используется порт 23 непосредственно хоста A. /* Другими словами, хост В «просит» хост А направить туннель ему (А) в localhost:23 — прим. ред */.
Проконтролировать появление слушающего порта можно командой

B#netstat –an | grep 50000

Открываем дополнительную SSH-сессию и подключаемся к telnet хоста A на хосте B:

B#telnet 127.0.0.1:50000
..
A>_

Показанная схема плохо применима на практике, потому что реальных клиентов может быть много. Для этого используем опцию –g, которая указывает на возможность подключения к слушающему порту на В по всем сетевым интерфейсам.

B#ssh –gNL 50000:127.0.0.1:23 root@100.100.100.201

Теперь мы можем подключиться с клиента C1 через В к сервису telnet хоста A.

 

С1#telnet 10.10.10.202:50000
..
A>_

Остальные клиенты Cx теперь также могут подключиться к сервису telnet хоста A.
Тут возникает справедливый вопрос. Сервис, находящийся в промышленной эксплуатации, обычно находится на отдельной машине, а не на шлюзе в Интернет. Как в этом случае обеспечить доступ к нему через хост A (то есть через наш туннель)? Заменяем адрес 127.0.0.1:23 на адрес и порт необходимого нам сервера. Единственное требование — с хоста A этот адрес должен быть доступен.

Например, нас интересует сервис telnet на хосте S1.

B#ssh –gNL 50000:10.10.10.200:23 root@100.100.100.201

После запуска этой команды, с клиентских рабочих станций Cx доступен сервис telnet сервера S1.

С1#telnet 10.10.10.202:50000
..
S1>_

Пока мы использовали локальное открытие слушающего порта. Но может пригодиться и удаленное открытие. В этом случае можно централизованно открывать туннели с хоста A на множестве типичных хостов B, когда много мелких LAN должны получать доступ к серверу S1 (например, имеем множество сбытовых организаций в разных городах). Режим удаленного перенаправления доступен через опцию –R. Следующая команда устанавливает туннель, аналогичный изображенному на Рис.3, но инициируется он со стороны шлюза A.

A#ssh –gNR 50000:10.10.10.200:23 root@100.100.100.202

В случае, если необходимо использовать несколько сервисов, их можно нагрузить на один процесс. Например, необходимо сделать доступным клиентам Cx дополнительный сервис WWW. Тогда добавляем еще одну опцию –L с перенаправлением порта 80.

B#ssh –f –g –C –L 50000:10.10.10.200:23 –L 50080:10.10.10.200:80 root@100.100.100.201 sleep 9999d

Теперь на рабочих станциях Cx вдобавок к telnet доступен WWW сервера S1 по порту 50080.

С1#lynx http://10.10.10.202:50080

Опция –C позволяет сжимать данные, передающиеся по шифрованному каналу, что может оказаться полезным для экономии полосы пропускания канала в Интернет. Тем более, что зашифрованные данные практически не поддаются сжатию. Опция –f позволяет процессу запуститься в background-режиме и освободить консоль для дальнейшей работы.
Теперь наша схема вполне пригодна для практического применения. Желаю успехов!

 

Александр Мисюк, Alexter at tut.by.
обсуждение статьи