Примите во внимание, что у протокола SSL точно такие же недостатки обработки сетевого Web-трафика, поскольку он не предусматривает передачу через сервер страниц по протоколу HTTPS. Напомним, что протокол HTTPS – это тот же протокол HTTP, но с дополнительным использованием протокола SSL. (Действительно, это является нарушением спецификации, потому что в данном случае блокировки и адреса будут ссылаться на многие хосты.)
Однако локальная переадресация портов –
совсемне бесполезная игрушка. Локальная переадресация портов полезна для переадресации всех однопортовых, однохостовых сервисов. Сам по себе протокол SSH является однопортовым, однохостовым сервисом. И как будет показано чуть позже, в этом кроются все различия.
Переадресация динамического порта
То, что переадресация локального порта в какой-то степени неуправляема, еще не означает, что протокол SSH не может быть использован для туннелирования различных типов трафика. Это всего лишь означает необходимость применения более элегантных решений. И действительно, одно из них было найдено. Исследования протокола SSH показали, что в начале сессии, во время перехода слушающего порта в состояние ожидания соединения, клиент не сообщает заинтересованному серверу о переадресации порта до тех пор, пока соединение не будет полностью установлено. Более того, при переназначении слушателю различных портов через туннель SSH сведения об адресате в различных TCP-соединениях могут изменяться. Для приложения существовал единственный простой способ динамического информирования протокола SSH о месте предполагаемого указания сокета. Клиент мог по требованию переадресовать порт путем использования протокола SOCKS4…
Древний протокол SOCKS4 был разработан для предоставления клиенту простейшего способа информирования о своих намерениях модуля доступа прокси (модуль доступа прокси (proxy) – механизм, посредством которого одна система представляет другую в ответ на запросы протокола) сервера, к которому клиент пытается подключиться. Модули доступа прокси являются нечто большим, чем просто серверами, обслуживающими сетевые подключения клиентов, которые желают получить доступ к сети. Клиент передает модулю доступа запрос для сервера, к которому клиент хотел бы подключиться. После этого модуль доступа прокси передает запрос по сети, а ответ на него пересылает обратно клиенту. Это именно то, что требовалось для переадресации (перенаправления) динамического порта (dynamic port forwards) протокола SSH. Можно ли в этой ситуации использовать управляющий протокол, подобный протоколу SOCKS4? Протокол SOCKS4, основанный на добавлении всего лишь нескольких бит в конец и начало TCP-сессии, характеризуется практическим отсутствием непроизводительных издержек при передаче пакета. Он уже интегрирован в большое число ранее существовавших приложений. В состав протокола включены даже хорошо продуманные упаковщики (упаковщик (wrapper) – программные средства создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы), которые позволяют реализовать любые приложения, а не только suid-приложения, с поддержкой сетевых возможностей и умеющих работать с модулем доступа прокси.
Найденное решение было вполне приемлемым. Приложения могли выдавать запросы, а протокол мог отвечать на них. Все необходимые для клиента вещи были для него понятны. По этой причине в пакет OpenSSH, начиная с его первой общедоступной версии 2.9.2p2, была встроена поддержка протокола SOCKS4 (для этого необходимо всего лишь обновить клиентскую часть, хотя новейшие сервера работают устойчивее, если они используются для этой цели). Неожиданно была рождена виртуальная частная сеть VPN (Virtual Private Network) для бедных. Запустить механизм переадресации динамического порта очень просто. Для этого достаточно указать порт для прослушивания: ssh – Dl istening_port user@host. Например,
effugas@OTHERSHOE ~/.ssh
$ ssh effugas@10.0.1.10 -D1080
Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
Last login: Mon Jan 14 12:08:15 2002 from
localhost.localdomain
[effugas@localhost effugas]$
В результате все подключения к адресу 127.0.0.1:1080 будут вынуждены пересылать в зашифрованном виде свои данные через адрес 10.0.1.10 любому адресату, запрошенному приложением. Процесс получения приложений, которые могут выдать подобные запросы, несколько грубоват, но это намного проще уловок, столь необходимых для переадресации локальных портов. Теперь приведем несколько примеров настроек. Internet Explorer 6: создание безопасной работоспособной Web-сети
Читать дальше
Конец ознакомительного отрывка
Купить книгу