Переадресация портов: доступ к ресурсам удаленных сетей

Переадресация портов: доступ к ресурсам удаленных сетей

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

Переадресация локального порта

По существу, переадресация (перенаправление) локального порта (local port forward) является запросом к протоколу SSH прослушать порт клиента TCP (очень жалко, но в силу достаточно серьезных причин протокол UDP не поддерживается). По мере поступления данных их перенаправляют по каналу через SSH-соединение на заданную машину, видимую с сервера. Образующийся при этом локальный трафик может быть послан на внешний IP-адрес машины, который в целях удобства обычно равен значению «127.0.0.1», а ключевое слово «localhost» ссылается на «этот хост» вне зависимости от значения внешнего IP-адреса.

Синтаксис для переадресации локального порта довольно прост:

ssh -L listening_port:destination_host:destination_port user@forwarding_host

Давайте исследуем эффект запуска процедуры переадресации порта, используя в качестве примера систему IRC (глобальная система, посредством которой пользователи могут общаться друг с другом в реальном масштабе времени). Рассмотрим порт, к которому пользователь хочет получить доступ из другой сети. Очень полезно, когда благодаря identd IRC работает незащищенным. Ниже показан пример необработанного трафика, который поступает во время подключения порта:

effugas@OTHERSHOE ~

$ telnet newyork.ny.us.undernet.org 6667

Trying 66.100.191.2...

Connected to newyork.ny.us.undernet.org.

Escape character is “^]”.

NOTICE AUTH :*** Looking up your hostname

NOTICE AUTH :*** Found your hostname, cached

Подключимся к удаленному серверу и прикажем клиенту SSH прослушивать попытки подключения IRC к локальному хосту. При получении каких-либо данных они посылаются удаленному хосту, который виден как newyork. ny.us.undernet.org, порт 6667.

effugas@OTHERSHOE ~

$ ssh effugas@libertiee.net -

L6667:newyork.ny.us.undernet.org:6667

Password:

Last login: Mon Jan 14 06:22:19 2002 from some.net on pts/0

Linux libertiee.net 2.4.17 #2 Mon Dec 31 21:28:05 PST 2001

i686 unknown

Last login: Mon Jan 14 06:23:45 2002 from some.net

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

effugas@OTHERSHOE ~

$ telnet 127.0.0.1 6667

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is “^]”.

NOTICE AUTH :*** Looking up your hostname

NOTICE AUTH :*** Found your hostname, cached

NOTICE AUTH :*** Checking Ident

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

$ irc Effugas 127.0.0.1

*** Connecting to port 6667 of server 127.0.0.1

*** Looking up your hostname

*** Found your hostname, cached

*** Checking Ident

*** No ident response

*** Welcome to the Internet Relay Network Effugas (from

Случай, когда конфигурация организована в виде растущего сверху вниз большого дерева меню, намного сложнее. Работа с таким деревом раздражает, потому при желании поменять сервер необходимо каждый раз модифицировать дерево. Фактически в этом случае нужно повторно построить соответствие между именами и IP-адресами. Вместо имени newyork.ny.us. undernet.org приложению возвращается его фактический IP-адрес. Нужно, чтобы вместо него был возвращен адрес 127.0.0.1. Для этого модифицируют hosts-файл, который почти всегда проверяется сервером DNS перед началом просмотра. Этот файл позволяет пользователю вручную установить соответствие между именами и их IP-адресами. Синтаксис записей hosts-файла прост:

bash-2.05a$ tail -n1 /etc/hosts 10.0.1.44 alephdox

Вместо непосредственной посылки IRC по адресу 127.0.0.1 следует модифицировать файл таким образом, чтобы он содержал следующую строчку:

effugas@OTHERSHOE /cygdrive/c/windows/system32/drivers/etc

$ tail -n1 hosts

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

effugas@OTHERSHOE /cygdrive/c/windows/system32/drivers/etc

$ irc Timmy newyork.ny.us.undernet.org

*** Connecting to port 6667 of server

newyork.ny.us.undernet.org

*** Looking up your hostname

*** Found your hostname, cached

*** Checking Ident

*** No ident response

Обратите внимание, что расположение hosts-файла изменяется в зависимости от используемой платформы. Почти все UNIX-системы используют директорию /etc/hosts, Win9x – WINDOWSHOSTS, WinNT – WINNT SYSTEM32DRIVERSETCHOSTS, а WinXP – WINDOWSSYSTEM32 DRIVERSETCHOSTS. Полагая, что Cygwin поддерживает Symlinks (по крайней мере, версию, способную правильно работать с файлами ярлыков Windows (Windows Shortcut files)), в соответствии со здравым смыслом было бы неплохо выполнить что-то похожее на ln – s HOSTSPATHHOSTS /etc/hosts.

Обратите внимание на то, что на самом деле переадресация порта с помощью протокола SSH не удовлетворяет требованию гибкости. Переадресация порта требует предварительного объявления адресатов, значительных административных издержек, и ей присущи все виды ограничений. Помимо всего прочего, несмотря на возможность указания при переадресации различных портов для получателя и отправителя (например, 16667:irc.slashnet. org:6667), никто не сможет обратиться к переадресованным портам по имени, поскольку обратно они разрешаются к одному и тому же IP-адресу 127.0.0.1. Также необходимо точно знать, каким хостам обязательно следует предпринять попытку переадресации портов, например для просмотра Web-сети, а это очень рискованное предположение. Помимо того что невозможно организовать полноценную обработку страниц, обслуживающих многочисленные адреса (каждая из них может быть послана одному и тому же серверу по порту 80 соединения по протоколу HTTP), любые сервера, сведения о которых не включены в hosts-файлы, будут «просачиваться» во внешнюю сеть.

Примите во внимание, что у протокола SSL точно такие же недостатки обработки сетевого Web-трафика, поскольку он не предусматривает передачу через сервер страниц по протоколу HTTPS. Напомним, что протокол HTTPS – это тот же протокол HTTP, но с дополнительным использованием протокола SSL. (Действительно, это является нарушением спецификации, потому что в данном случае блокировки и адреса будут ссылаться на многие хосты.)

Данный текст является ознакомительным фрагментом.