Библиотека Интернет Индустрии I2R.ru

При подключении локальной сети к Internet один из компьютеров выступает в роли шлюза: через модем или другим способом связывается с Internet, а остальные работают через него. Для полноценной работы в Internet компьютер должен иметь реальный (доступный из Internet) IP-адрес, в противном случае он не получит извне ни одного IP-пакета, так же как человек без полного почтового адреса не сможет получать писем. Но, как правило, реальный IP-адрес выделяются только комьпьютеру-шлюзу, имеющему непосредственное соединение с Internet. При подключении через модем IP-адрес обычно назначается ему динамически из адресного пула провайдера. При постоянном подключении он статический.

С момента назначения разница между динамическими и статическими адресами исчезает (вопреки распространенному заблуждению). На шлюзовом компьютере, независимо от типа подключения, смогут работать как клиентские, так и серверные программы. Причем услуги сервера, работающего на такой машине, будут доступны из обеих сетей - и из Internet, и из локальной сети. (Нежелательные соединения извне могут быть исключены программными средствами безопасности, но это уже другой вопрос.) Это происходит из-за того, что шлюз имеет как минимум два сетевых интерфейса - например, модем и сетевую карту. И, соответственно, два IP-адреса: один "реальный", назначаемый контроллеру удаленного доступа (пример: 204.91.242.35), другой - внутренний, назначаемый сетевой карте в локальной сети (пример: 10.1.1.1). На других компьютерах локальной сети тоже могут работать программы обоих типов, но доступны они будут только внутри локальной сети (intranet), так как в Internet отсутствует маршрутизация для внутренних адресов такого типа (в данном примере - 10.*.*.*).

Благодаря такой организации сети убиваются два зайца: 1) экономятся дефицитные реальные IP-адреса; 2) осуществляется некоторая базовая защита компьютеров в локальной сети (кроме шлюза) от вторжения извне. Но это исключает возможность работы в Internet с любого компьютера локальной сети, кроме шлюзового. Поэтому в таких сетях обязательно используются прокси-серверы, которые заставляют шлюзовой компьютер выполнять запросы на получение информации по просьбе и от имени других компьютеров сети. Шлюзовой компьютер принимает запрос (в виде URL, например) от компьютера в своей сети, сам выполняет этот запрос в Internet и возвращает результат компьютеру в локальной сети.

Для большинства стандартных клиентских приложений (пакет Internet Explorer. например) возможностей традиционных прокси-серверов вполне хватает. Но есть приложения, которым требуется временно выступать в роли сервера, даже когда они работают на машинах пользователей. Приведу два примера.

Протокол FTP при обычном получении файла клиентской программой с FTP-сервера требует установки двух TCP-соединений. Первое - управляющее, через которое FTP-клиент дает команды серверу. Его устанавливает клиентская программа при подключении к серверу. Второе соединение инициируется FTP-сервером к клиенту по IP-адресу и порту, указанному FTP-клиентом через управляющее соединение. Такие вторичные соединения устанавливаются сервером для передачи клиенту списка файлов и самих файлов. В этот момент они фактически меняются ролями: клиент принимает соединения, а сервер соединяется. В локальной сети функции FTP-клиента берет на себя FTP-прокси-сервер, однако часть возможностей FTP при этом теряется, так как браузер на рабочем месте пользователя будет уже "клиентом клиента". Если же клиентская FTP-программа не может работать через прокси (как известная программа FAR), то от использования ее приходится вовсе отказаться.

Второй пример. Все большее распространение приобретают программы для онлайновых переговоров (chat). Часть из них являются клиентами chat-серверов, расположенных в Internet, и достаточно легко могут быть настроены для работы через прокси. Большая группа программ (MS NetMeeting, ICQ, AOL Messenger и др.) позволяет связываться напрямую, без посредничества какого-либо сервера в Internet. Например, NetMeeting позволяет делать вызов по IP-адресу. В этом случае программа на компьютере одного из участников беседы берет на себя роль сервера. А если один из пользователей (или даже оба) находятся в локальной сети и не имеют возможности устанавливать прямое соединение из-за отсутствия реального IP-адреса у одного или обоих? Тоже придется отказаться от этих программ.

Большинство прокси-серверов являются узкоспециализированными и рассчитаны на конкретные прикладные протоколы (HTTP, FTP, RealAudio и т. д.), то есть для новых протоколов требуются новые прокси-серверы…

Весь описанный здесь спектр проблем решается с помощью Socks-серверов.

Как работает Socks5

Socks-сервер устанавливается на шлюзовых компьютерах, то есть на границе локальной сети и Internet. Socks обладает двумя ключевыми особенностями, выделяющими его из группы прокси-серверов.

1. Он не зависит от высокоуровневых протоколов (HTTP, FTP, POP3, SMTP, NNTP и т. д.), так как осуществляет представительство клиентов на более низком уровне (TCP и UDP).
2. Приложение в локальной сети может попросить Socks-сервер выступить в роли сервера от лица клиента. То есть приложение в локальной сети сможет принимать соединения извне, несмотря на отсутствие реального IP-адреса.

Вообще говоря, многие из описанных проблем решаются просто путем отображения портов с помощью Mapping-proxy (тема для отдельного разговора), но Socks - более рациональное средство, не требующее в отличие от MAP знания тонкостей конкретных протоколов и приложений. Через Socks5 можно заставить работать даже приложения, которые и понятия не имеют о прокси! Пример - уже упомянутый FAR v1.5. Это "перенаправление" через прокси делается, например, программой SocksCapture (NEC). Многие современные программы сами умеют работать через Socks. Примеры - Mirabilis ICQ, MS Internet Explorer, Netscape Navigator - хотя все с некоторыми оговорками, о которых позже.

В протоколе Socks5 есть запросы (от Socks-клиента Socks-серверу) со следующим смыслом:

• Установи TCP-соединение от моего лица с таким-то сервером и передавай между нами данные в обе стороны (установленное соединение дальше работает как простое отображение, без "вникания" Socks-сервера в суть происходящего в канале - это могут быть команды и данные любых высокоуровневых протоколов).
• Работай сервером от моего лица на таком-то TCP-порте, принимай входящие соединения и передавай мне для обработки (после приема соединения Socks-сервер опять-таки тупо передает данные между двумя сторонами, не вникая в содержание).
• Установи UDP-отображение заданного порта (UDP не ориентирован на соединения, поэтому ярко выраженных клиентов и серверов нет, обе стороны можно считать и тем и другим).

Фактически Socks-сервер является программно-управляемым mapping-proxy, причем с описанным единым интерфейсом. Все mapping-proxy так или иначе программно управляются, но под руководством администратора сети (человека), и отображения статичны. А Socks-сервер управляется прикладными программами, и отображения устанавливаются, только когда они нужны, и на то время, пока они нужны.

Запросы Socks хорошо согласуются с запросами, посылаемыми программами к интерфейсу winsock, именно поэтому существует возможность "насильно" заставить любую Internet-программу пойти через Socks-сервер, даже если она сама не умеет. Для этого такие программы, как SocksCapture, перехватывают обращения этой программы к функциям wsock32.dll (и другим реализациям winsock) и преобразуют их в запросы к Socks-серверу незаметно для самой программы.

Socks4 и Socks5

Цифры в названии означают версию протокола. Socks5 - последняя версия, определенная в RFC1928. От Socks4 его отличают следующие новые возможности:

1. Socks-клиент может передавать не только IP-адрес хоста, с которым необходимо устанавливать соединение, но и доменное имя хоста. Socks5-сервер сам получит IP по имени. Таким образом, в локальных сетях, работающих через Socks5, можно обойтись без локального DNS-сервера. Socks4 требовал его наличия.
2. Socks5 поддерживает не только TCP, но и UDP. Вместе они покрывают почти все множество используемых прикладных протоколов. Из широко используемых программ разве что диагностические утилиты ping и tracert пользуются "сырыми" (raw) сокетами и не могут работать через TCP и UDP.
3. Socks5-сервер может согласовывать с клиентом способ аутентификации.
4. Socks5 может использовать не только принятые схемы адресации в Internet, но и будущие - такие, как IPv6 (IPng).

Socks5 и ICQ</p>

ICQ - первое из популярных приложений, которое тяжело полноценно использовать в локальных сетях без наличия Socks5-сервера. В отличие от подавляющего большинства современных приложений, ICQ очень широко использует протокол UDP (почти для всех своих функций, начиная с регистрации на сервере icq.mirabilis.com, заканчивая передачей файлов), поэтому использование Socks5 напрашивается само собой. Тем более что ICQ сама предлагает использовать Socks.

Однако ICQ не полностью использует возможности, предоставляемые Socks5. Так, при соединении с сервером icq.mirabilis.com клиент ICQ, работающий на компьютере в локальной сети, пытается сам выяснить IP-адрес этого сервера у DNS, вместо того чтобы просто передать имя хоста серверу Socks5. В результате ICQ (текущие версии, вплоть до ICQ98a) не сможет работать без локального DNS-сервера или DNS-прокси.

Здесь надо отметить, что ICQ98 использует новую версию собственных протоколов поверх UDP по сравнению с недавними выпусками ICQ 1.113. Новый протокол намного интенсивнее использует UDP. Теперь даже при обычном использовании интерфейса ICQ (открытии, закрытии его окон, например) на mirabilis отправляются UDP-пакеты (неизвестно для чего, возможно, собирают статистику активности использования), средний размер пакетов тоже увеличен. Так что есть определенный смысл продолжать использовать более старые версии ICQ.

Socks и браузеры

Браузеры Explorer и Navigator в использовании Socks "блещут консерватизмом": используется Socks4. UDP браузерам не нужен, но такую полезную возможность Socks5, как избавление от локального DNS-сервера, они игнорируют явно зря. К сожалению, Socks4 и Socks5 не имеют обратной совместимости, и не все Socks5-серверы могут обрабатывать Socks4-запросы, посылаемые браузерами.

Socks и SocksCapture

SocksCapture и подобные программы помогут вам приручить в локальной сети большинство из тех программ, которые не умеют работать через прокси самостоятельно. Это обеспечивается за счет перехвата обращений этих программ к функциям winsock и направления этих вызовов через Socks-сервер. SocksCapture позволяет довольно гибко настраивать и сохранять сетевую конфигурацию этих программ: через какой Socks-сервер ее запускать, в каком режиме работать с DNS и др.

Socks-сервер запускается на шлюзовом компьютере, а SocksCapture является клиентской по отношению к нему программой и должен устанавливаться на каждом компьютере в локальной сети.

Что не может делать Socks

Поскольку Socks-прокси не знает, какие высокоуровневые протоколы он через себя пропускает, он не может им "помогать". В основном это касается кэширования. Socks не может узнать, какие ресурсы сети извлекаются с его помощью, и, соответственно, не может при следующем обращении к этому ресурсу "подставить" старое содержание немедленно без выполнения запроса.

Второе ограничение - когда клиентская программа просит Socks-прокси выполнить за него серверную функцию (прими для меня входящее TCP-соединение), Socks-прокси не гарантирует, что он будет "слушать" именно тот номер порта, который хотел бы слушать клиент, так как на шлюзовой машине этот порт может быть уже занят другим сервером или другим потоком Socks-сервера, обслуживающим другого клиента. Таким образом, почти невозможно организовать работу, например, Web-cервера, находящегося внутри локальной сети, но принимающего соединения через Socks-сервер, - так как внешний клиент не будет заранее знать, с каким портом соединяться. То есть через Socks-прокси клиентское приложение сможет быть сервером, но только временным и только после того, как эта пара - клиент и сервер - уже установили первичное соединение и могут передать через него номер порта для вторичного соединения. Этот номер назначается Socks-сервером и сообщается Socks-клиенту. В таком режиме могут работать, например, FTP-клиенты и ICQ. Для выдачи постоянных внутренних серверов "наружу" через прокси лучше пользоваться обычным mapping-прокси с постоянными отображениями портов.

Где взять эти программы

Socks-сервер:

• Eserv/2.0. http://www.enet.ru/win/cherezov/e-serv.htmlМногофункциональный сервер для Internet/intranet (HTTP/SMTP/POP3/NNTP/Proxy). В том числе Socks-сервер для WinNT/95. Разработчик - автор этой статьи.
• WinGate/2.1. http://wingate.net/Многофункциональный прокси-сервер. В том числе Socks-сервер. WinNT/95.
• NEC's socks5 implementation (WinNT): http://www.socks.nec.com/ or ftp://ftp.nec.com/pub/socks/socks5/

SocksCapture:

• SocksCapture (NEC) http://www.socks.nec.com/

Mirabilis ICQ http://www.mirabilis.com/

FAR ftp://rwntug.quarta.msk.ru/WinUtil/Rar/

Узнать, как использовать возможности Socks5 в своих программах, можно в RFC1928.