Туннель ТСР как выделенный канал

Oрганизация туннелей ТСР через защищенные соединения SSH во многих случаях представляет собой эффективную альтернативу ресурсоемким решениям VPN. Туннели можно стабилизировать таким образом, что они смогут неплохо переносить разрывы соединения. Это особенно прогодится в средах с фиксированной оплатой и динамической системой DNS. К тому же стабильные туннели подходят для удаленного доступа к сетям без собственного сервера SSH.

SSH расшифровывается как Secure Shell и предназначается в первую очередь для защищенного терминального доступа к вычислительным системам. Поэтому возможность создания туннеля ТРС во время сеансов SSH между соответствующим клиентом и сервером является, скорее, побочным эффектом. К числу вероятных применений относятся и такие, когда главная цель — не терминальный доступ, а защищенный туннель между двумя сетями. SSH поддерживает подобные сценарии благодаря способности активизировать туннели с локальной стороны для всех пользователей сети, терминировать туннель на любом конечном устройстве целевой сети и даже инициировать обратные («входящие») туннели. К ним могут обращаться все сетевые пользователи на противоположной стороне, а завершаются они на определенных конечных устройствах в локальной сети. Характерно, что самим пользователям туннеля клиент SSH вовсе не нужен, им важно лишь знать точку входа (IP-адрес и порт TCP) желаемого туннеля.

Защищенные туннельные соединения ТСР хоть и не могут сравниться по своей производительности с виртуальными частными сетями (Virtual Private Network, VPN), однако во многих случаях их вполне достаточно для создания коммуникационного соединения между отдельными автономными сетями. Очевидные примеры — соединения между независимыми малыми офисными или домашними сетями (Small Office/Home Office, SOHO) или соединения между домашними офисами и предприятием. Такие сценарии оказались возможны благодаря доступу к Internet через DSL с фиксированной ставкой и поддержкой квазинепрерывной работы, а также благодаря динамической службе имен доменов (Domain Name System, DNS), применение которой позволяет обеспечить непрерывную доступность даже в случае замены открытого IP-адреса.

СТАБИЛЬНЫЕ ТУННЕЛИ

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

• даже после серьезного разрыва (к примеру, смена IP-адреса при подключении DSL с противоположной стороны) туннельное соединение должно восстанавливаться автоматически;
• туннель должен оставаться стабильным и в том случае, когда в течение длительного времени полезные данные не передаются. Особого внимания требуют маршрутизаторы NAT на противоположной стороне, поскольку они могут прервать «неиспользуемые» сеансы по истечении тайм-аута;
• туннели не должны зависеть от присутствия отдельных пользователей, как это обычно имеет место в случае сеансов SSH. И клиентской стороне следует — по аналогии с сервером SSH — по качеству равняться на службы NT.

Все эти требования возможно соблюсти в одном решении, что и показывает описанный ниже подход, хорошо зарекомендовавший себя в повседневной практике. Он базируется на операционной системе Windows и соответствующих продуктах от SSH Communications Security, а именно: SSH Secure Shell версии 3.1 для серверов Windows и SSH Secure Shell версии 3.2.3 для рабочих станций. Наряду с удобным графическим клиентом Windows комплект поставки включает также клиент SSH для командной строки (ssh2.exe), которому в дальнейшем отводится главная роль. В командном файле задается бесконечный цикл, автоматически инициирующий новое соединение после каждого разрыва связи. Чтобы эта схема работала без обычной процедуры ввода пароля, используется аутентификация с открытым ключом, что составляет основу решения. В завершение, как со стороны клиента, так и со стороны сервера, может понадобиться организация «тактовых импульсов», они тоже реализуются при помощи командных файлов с бесконечными циклами. В случае необходимости все применяемые командные файлы могут работать в форме, схожей со службами NT.

ДОСТУП С ОТКРЫТЫМ КЛЮЧОМ

В дальнейшем мы будем исходить из того, что с обеих сторон запланированного туннельного решения уже установлены сервер и клиент SSH для Windows и для них заданы стандартные параметры. На стороне сервера для туннельных сеансов рекомендуется создать отдельную учетную пользовательскую запись. После чего в графическом клиенте SSH для Windows задается обычным образом соответствующий профиль доступа. Тогда терминальный доступ становится возможен через учетную запись и пароль как для графического клиента, так и для клиента с командной строкой (ssh2.exe).

Если оба функционируют, то на следующем шаге необходимо перейти к аутентификации с открытым ключом. Это достаточно подробно описано в документации, поэтому мы отметим лишь наиболее важные пункты: в меню Edit/Settings графического клиента надо выбрать пункт Global Settings/User Authentication/Keys для вызова инструментария управления ключами и создать новую пару. Сохраненный на клиентском компьютере секретный ключ обычно защищается паролем (парольная фаза). От этого следует отказаться, чтобы в будущем можно было осуществлять беспарольный доступ через клиента с командной строкой (соответствующее предупреждение инструментария управления ключами при задании пустой парольной строки следует проигнорировать). Небольшая «дыра» в системе безопасности действительно возникает, поскольку незащищенный секретный ключ может быть использован в злонамеренных целях, если попадет в руки посторонним людям. Поэтому на клиентском компьютере необходимо предпринять все меры, чтобы к файлу с ключом не получили доступ третьи лица.

Остальное представляет собой достаточно рутинную работу: если есть соединение SSH с сервером, то секретный ключ может быть загружен на него сразу же, в противном случае это придется проделать позже при помощи инструментария управления ключами. Беспарольный доступ SSH несложно проверить с помощью графического клиента, для чего в пункте Authentication/Authentication Methods соответствующего профиля на первом месте надо указать метод открытого ключа. Однако для желаемой поддержки открытого ключа клиентом с командной строкой нужен последний решающий шаг: посредством инструментария управления ключами в подпункте Public key authentication for the ssh2.exe Command Line Client при помощи кнопки Configure следует активизировать разрешение на использование. Беспарольный доступ через клиента с командной строкой к оболочке серверной системы должен стать возможным после ввода ssh2 user@host.

ТУННЕЛЬНЫЕ СЕАНСЫ

Однако доступ к оболочке не нужен для последующих туннельных сеансов, и в ssh2.exe он деактивируется при помощи параметра -S (заметим, что параметр -h позволяет получить справочную информацию). Стоит задуматься о том, чтобы деактивировать терминальное использование на самом сервере SSH — если он задействован только или почти исключительно для туннельных соединений — либо ограничить его пользователями с административными правами. Необходимые настройки производятся в меню конфигурации сервера SSH в пункте User Authentication/User Restrictions/Permit User Terminal, где на выбор предлагаются варианты ответа: yes, no и admin. Эта установка является глобальной. Деактивация терминальных сеансов должна быть обязательно учтена в клиентских настройках, поскольку в противном случае туннельное соединение может сорваться. Конечно же для предотвращения потенциального злоупотребления можно применить и другие методы ограничения на стороне сервера.

Во врезке «Командные файлы» приводится пример командного файла с вызовом SSH2, инициирующим различные туннели как в исходящем (-L), так и во входящем направлении (-R). Параметр -g (gateway, т. е. шлюз) определяет, что исходящие туннели также могут быть использованы другими компьютерами локальной сети. А входящие туннели могут быть доступны всем машинам удаленной сети. Посредством цикла с небольшой паузой ожидания (sleep.exe) командный файл пытается столько раз установить новое соединение после разрыва старого, сколько потребуется для его восстановления.

В целом с этим командным файлом главное уже сделано. Однако практика показывает, что для бесперебойной длительной работы туннельных соединений необходимы так называемые тактовые импульсы, с одной стороны, для поддержания соединения, с другой — для того, чтобы обеспечить быстрый разрыв соединения, если принимающая система уже действительно недостижима. Последнее приобретает особое значение в том случае, когда противоположная сторона меняет IP-адрес (к примеру, после принудительного отключения), и клиент SSH обращается к ней через динамический адрес DNS. Тактовые импульсы также реализуются при помощи командного файла. Причина их применения заключается в том, что интегрированные в клиент и сервер SSH функции контроля рабочего состояния недостаточно быстро реагируют на разрыв соединения.

ТАКТОВЫЕ ИМПУЛЬСЫ

Примеры различных вариантов реализации тактовых импульсов также приведены во врезке. Их объединяет то, что какое-либо простое приложение ТСР регулярно пользуется исходящим туннелем, создавая тем самым трафик IP. Наличия с противоположной стороны соответствующего приложению сервера не требуется, решающим фактором является лишь рабочее состояние нужного туннеля ТСР. И здесь речь идет о командном файле с бесконечным циклом. В качестве приложения ТСР с командной строкой идеально подходит (начиная с Windows 2000) telnet, поскольку он может работать через любой порт. В Windows NT в роли инструмента командной строки может выступать finger, однако для этого следует включить дополнительный туннель для ТСР-порта 79. Наряду с «доморощенными средствами» хорошо показал себя на практике свободно распространяемый программный инструмент portqry, который — как и telnet — способен работать через разные порты и предлагает детализированные возможности для протоколирования.

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

Во избежание недоразумений тактовые импульсы должны применяться как со стороны сервера, так и клиента лишь в том случае, когда их наличие предполагается конкретным коммуникационным сценарием. Вполне реальны ситуации, когда они излишни и представляют собой ненужный балласт. Завершая тему командных файлов с бесконечным циклом, следует отметить, что начиная с Windows 2000 по качеству работы они схожи со службами NT. Поэтому пользователю нет нужды заботиться об отдельных командных вызовах, передача данных по туннелю SSH происходит на стороне клиента почти с тем же уровнем готовности, что и у службы NT. Так, к примеру, регистрация пользователей не нужна.

ОБРАТНЫЕ ТУННЕЛИ

И в заключение еще одно замечание об обратных туннелях. Описанная здесь постоянная или, по крайней мере, полупостоянная передача данных по туннелям открывает в связи с обратными туннелями безусловно интересную для удаленных систем возможность соединения в любой момент с сетью, в которой нет своего общедоступного сервера SSH. Отправитель и получатель просто меняются местами. Целевая система не должна быть доступна в Internet через SSH, достаточно, если к источнику может обращаться и поддерживать с ним соединение один-единственный клиент. Над этим аспектом следует задуматься администраторам крупных корпоративных сетей, где имеются компетентные в данной области пользователи. С технической точки зрения с помощью описанных методов вполне возможно создание обратного туннеля SSH для подключения к собственному рабочему компьютеру и через него к корпоративной сети из домашнего офиса в обход «официальных» путей доступа.

Когда создаются обратные туннели, их использование рекомендуется ограничивать. На практике, например, хорошо зарекомендовала себя технология «туннеля в туннеле»: при организации обратного туннеля для второго соединения SSH в противоположном направлении от удаленной сети к серверу SSH в Intranet удаленные пользователи должны обращаться к локальной сети только через него. Это, с одной стороны, является предохранительным барьером, с другой — открывает перед удаленными пользователями с соответствующими правами доступа возможность применения графического клиента SSH. Таким образом туннели можно создавать и для соединений FTP, что, к сожалению, невозможно в случае клиента SSH с командной строкой.

Курт Пфайлер — редактор LANline. С ним можно связаться по адресу: pf@lanline.awi.de.

? AWi Verlag

Командные файлы

Следующий пример представляет командный файл c бесконечным циклом и вызовом SSH. После обрыва соединения программа ждет 30 с. В примере определены три исходящих туннеля для HTTP и VNC, а также один «слепой» туннель для тактовых импульсов. Кроме того, для соединения SSH в противоположном направлении предусмотрен обратный туннель.

LOOP
echo %date% %time%
ssh2 -S -g -L 8080:192.168.25.161:80 -L
5901: localhost:5900 -L 79:localhost:4711 -R
2222:192.168.7.15:22 user@account.dyndns.org

sleep 30s
goto LOOP

При помощи похожей командной конструкции генерируются тактовые импульсы. В данном случае используется telnet:

LOOP
echo %date% %time%
telnet localhost 79
sleep 15s
goto LOOP

Вместо telnet можно применять Finger, если определен туннель для порта 79:

finger @localhost

Свободно распространяемый программный инструмент portgry также подходит для генерации тактовых импульсов, он предлагает хорошие возможности для протоколирования в виде индикатора статуса порта:

LOOP
portqry -n 192.168.7.204 -e 8090 -i -q
if %errorlevel% ==%STAT% goto SLEEP
set STAT=%errorlevel%
echo %date% %time% %STAT%
:SLEEP
sleep 15s
goto LOOP

Указание: portqry не может обращаться к адресату localhost. В качестве варианта можно указывать реальный IP-адрес локального компьютера.