Триколор 

Что такое socks5 прокси. Написание простейшего SOCKS4 сервера на языке Assembler. Установка исходящего UDP-соединения

Такой прокси сервер контролирует права клиента для доступа к внешним ресурсам и передаёт запрос к серверу. SOCKS может использоваться и противоположным способом, разрешая внешним клиентам соединяться с серверами за межсетевым экраном (брандмауэром).

В отличие от HTTP прокси серверов, SOCKS передаёт все данные от клиента, ничего не добавляя от себя, то есть с точки зрения конечного сервера, SOCKS прокси является обычным клиентом. SOCKS более универсален - не зависит от конкретных протоколов уровня приложений (7-го уровня модели OSI) и базируется на стандарте TCP/IP - протоколе 4-го уровня. Зато HTTP прокси кэширует данные и может более тщательно фильтровать содержимое передаваемых данных.

Этот протокол был разработан Дэвидом Кобласом (David Koblas), системным администратором MIPS Computer Systems. После того, как в году MIPS вошла в состав Silicon Graphics (SGI), Коблас сделал доклад о SOCKS на Симпозиуме по Безопасности Usenix (Usenix Security Symposium), и SOCKS стал публично доступным. Протокол был расширен до четвёртой версии Ин-Да Ли (Ying-Da Lee) из NEC Systems Laboratory.

Протокол SOCKS 4

SOCKS 4 предназначен для работы через фаервол без аутентификации для приложений типа клиент-сервер, работающих по протоколу TCP , таких, как TELNET , FTP и таких популярных протоколов обмена информацией, как HTTP , WAIS и GOPHER . По существу, SOCKS-сервер можно рассматривать как межсетевой экран, поддерживающий протокол SOCKS.

Типичный запрос SOCKS 4 выглядит следующим образом (каждое поле - один байт):

Запрос Клиента к SOCKS-Серверу:

  • поле 1: номер версии SOCKS, 1 байт (должен быть 0x04 для этой версии)
  • поле 2: код команды, 1 байт:
    • 0x02 = назначение TCP/IP порта (binding)
  • поле 3: номер порта, 2 байта
  • поле 4: IP-адрес , 4 байта
  • поле 5: ID пользователя, строки переменной длины, завершается null-байтом (0x00). Поле предназначено для идентификации пользователя (см. Ident)

Ответ Сервера SOCKS-Клиенту:

  • поле 1: null-байт
  • поле 2: код ответа, 1 байт:
    • 0x5a = запрос предоставлен
    • 0x5b = запрос отклонён или ошибочен
    • 0x5c = запрос не удался, потому что не запущен identd (или не доступен с сервера)
    • 0x5d = запрос не удался, поскольку клиентский identd не может подтвердить идентификатор пользователя в запросе
  • поле 3: 2 произвольных байта, должны быть проигнорированы
  • поле 4: 4 произвольных байта, должны быть проигнорированы

Протокол SOCKS 5

SOCKS 5 расширяет модель SOCKS 4, добавляя к ней поддержку UDP , обеспечение универсальных схем строгой аутентификации и расширяет методы адресации, добавляя поддержку доменных имен и адресов IPv6 . Начальная установка связи теперь состоит из следующего:

  • Клиент подключается, и посылает приветствие, которое включает перечень поддерживаемых методов аутентификации
  • Сервер выбирает из них один (или посылает ответ о неудаче запроса, если ни один из предложенных методов не приемлем)
  • В зависимости от выбранного метода, между клиентом и сервером может пройти некоторое количество сообщений
  • Клиент посылает запрос на соединение, аналогично SOCKS 4
  • Сервер отвечает, аналогично SOCKS 4

Методы аутентификации пронумерованы следующим образом:

  • 0x00 - аутентификация не требуется
  • 0x01 - GSSAPI
  • 0x02 - имя пользователя / пароль
  • 0x03-0x7F - зарезервировано IANA
  • 0x80-0xFE - зарезервировано для методов частного использования

Начальное приветствие от клиента:

  • поле 2: количество поддерживаемых методов аутентификации, 1 байт
  • поле 3: номера методы аутентификации, переменная длина, 1 байт для каждого поддерживаемого метода

Сервер сообщает о своём выборе:

  • поле 1: Версия SOCKS, 1 байт (0x05 для этой версии)
  • поле 2: выбранный метод аутентификации, 1 байт, или 0xFF, если не было предложено приемлемого метода

Последующая идентификация зависит от выбранного метода.

Запрос клиента:

  • поле 1: номер версии SOCKS (должен быть 0x05 для этой версии)
  • поле 2: код команды, 1 байт:
    • 0x01 = установка TCP/IP соединения
    • 0x02 = назначение TCP/IP порта (binding)
    • 0x03 = ассоциирование UDP-порта
  • поле 3: зарезервированный байт, должен быть 0x00
  • поле 4: тип адреса, 1 байт:
    • 0x01 = адрес IPv4
    • 0x03 = имя домена
    • 0x04 = адрес IPv6
  • поле 5: назначение адреса
    • 4 байта для адреса IPv4
    • 16 байт для адреса IPv6
  • поле 6: номер порта, 2 байта

Ответ сервера:

  • поле 1: номер версии SOCKS, 1 байт (0x05 для этой версии)
  • поле 2: код ответа, 1 байт:
    • 0x00 = запрос предоставлен
    • 0x01 = ошибка SOCKS-сервера
    • 0x02 = соединение запрещено набором правил
    • 0x03 = сеть недоступна
    • 0x04 = хост недоступен
    • 0x05 = отказ в соединении
    • 0x06 = истечение TTL
    • 0x07 = команда не поддерживается / ошибка протокола
    • 0x08 = тип адреса не поддерживается
  • поле 3: байт зарезервирован, должен быть 0x00
  • поле 4: тип последующего адреса, 1 байт:
    • 0x01 = адрес IPv4
    • 0x03 = имя домена
    • 0x04 = адрес IPv6
  • поле 5: назначение адреса
    • 4 байта для адреса IPv4
    • первый байт - длина имени, затем следует имя домена без завершающего нуля на конце
    • 16 байт для адреса IPv6
  • поле 6: номер порта, 2 байта

Реализации

  • Sun Java System Web Proxy Server - кеширующий прокси сервер для Solaris, Linux, Windows. Поддерживает HTTPS, NSAPI I/O фильтры, динамическую реконфигурацию и обратный прокси.
  • DeleGate - многофункциональный шлюз прикладного уровня и прокси сервер, работающий на различных платформах. Кроме SOCKS также поддерживает HTTP(S), FTP , NNTP , SMTP , POP , IMAP , LDAP , Telnet , DNS и другие протоколы.
  • 3proxy - легкий прокси-сервер с поддержкой SOCKS-proxy
  • WinGate - многопротокольный прокси сервер с поддержкой SOCKS для Windows.
  • OpenSSH позволяет динамически создавать туннели, заданные через подмножество протокола SOCKS.

См. также

Ссылки

  • RFC 1928 (англ.) - SOCKS Protocol Version 5
  • RFC 1928 (рус.) - Протокол SOCKS 5
  • RFC 1929 (англ.) - Username/Password Authentication for SOCKS V5
  • RFC 1961 (англ.) - GSS-API Authentication Method for SOCKS Version 5
  • SOCKS: A protocol for TCP proxy across firewalls (англ.) - Протокол SOCKS 4

Wikimedia Foundation . 2010 .

Смотреть что такое "SOCKS" в других словарях:

    SOCKS - is an Internet protocol that allows client server applications to transparently use the services of a network firewall. SOCKS is an abbreviation for SOCKetS [ ]… … Wikipedia

    SOCKS - Saltar a navegación, búsqueda SOCKS es un protocolo de Internet que permite a las aplicaciones Cliente servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de SOCKetS . Los clientes que hay detrás… … Wikipedia Español

    Сетевой протокол, который позволяет клиент серверным приложениям прозрачно использовать сервисы за межсетевыми экранами (фаерволами). SOCKS это сокращение от «SOCKetS» (сокеты, гнёзда). Клиенты за межсетевым экраном, нуждающиеся в доступе к… … Википедия

    Socks - im Briefing Room des Weißen Hauses Betty Currie und Socks … Deutsch Wikipedia

    Socks - sobre el pupitre de la Sala de Prensa de la Casa Blanca. Socks (en español: Calcetines, marzo de 1989 20 de febrero de 2009) fue el gato de la familia del Presidente de los Estados Unidos Bill Clinton durante su presidencia. Fue la única mascota… … Wikipedia Español

SOCKS сокращение от «SOCKetS» (сокеты, гнёзда) разработан для того, чтобы дать возможность приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Он дает пользователям возможность преодолевать межсетевой экран организации и получать доступ к ресурсам, расположенным в сети Интернет. SOCKS является “посредником уровня приложений”: он взаимодействует с общими сетевыми средствами (например, Telnet и браузер Netscape) и с помощью центрального сервера (прокси-сервера) от имени вашего компьютера устанавливает связь с другими центральными компьютерами.


SOCKS был разработан много лет назад Дейвом Кобласом из компании SGI, и сегодня этот код можно бесплатно получить через Интернет. С момента первого выпуска этот код пережил несколько крупных модификаций, но каждая из них распространялась совершенно бесплатно. SOCKS версия 4 решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, основанными на протоколе TCP, включая Telnet, FTP и популярные информационные протоколы, такие как HTTP, Wide Area Information Server (WAIS) и GOPHER. SOCKS версия 5, RFC 1928, является дальнейшим расширением четвертой версии SOCKS. Он включает в себя UDP, расширяет общую рамочную структуру, придавая ей возможность использования мощных обобщенных схем аутентификации, и расширяет систему адресации, включая в нее имя домена и адреса IP v6.

В настоящее время предлагается создать механизм управления входящими и исходящими многоадресными сообщениями IP, которые проходят через межсетевой экран. Это достигается определением расширений для существующего протокола SOCKS V.5, что создает основу для аутентифицированного перехода межсетевого экрана одноадресным пользовательским графиком TCP и UDP. Однако ввиду того, что поддержка UDP в текущей версии SOCKS V.5 имеет проблемы с масштабируемостью и другие недостатки (и их обязательно нужно разрешить, прежде чем переходить к многоадресной передаче), расширения определяются двояко: как базовые расширения UDP и как многоадресные расширения UDP.


Функционирование SOCKS заключается в замене стандартных сетевых системных вызовов в приложении их специальными версиями. Эти новые системные вызовы устанавливают связь с прокси-сервером SOCKS (который конфигурируется самим пользователем в приложении или системным файлом конфигурации), подключаясь к хорошо известному порту (обычно это порт 1080/ТСР). После установления связи с сервером SOCKS приложение отправляет серверу имя машины и номер порта, к которому хочет подключиться пользователь. Сервер SOCKS реально устанавливает связь с удаленным центральным компьютером, а затем прозрачно передает данные между приложением и удаленной машиной. При этом пользователь даже не подозревает, что в канале связи присутствует сервер SOCKS.


Трудность с использованием SOCKS состоит в том, что кто-то должен проводить работу по замене сетевых системных вызовов версиями SOCKS (этот процесс обычно называется “SOCKS-ификацией” приложения). К счастью, большинство обычных сетевых приложений (Telnet, FTP, finger, whois) уже SOCKS-ифицированы, и многие производители включают поддержку SOCKS в свои коммерческие приложения. Кроме того, SOCKS V.5 включает эти процедуры в свою общую библиотеку: на некоторых системах (например, на машинах Solaris) можно автоматически SOCKS-ифицировать приложение, поставив общую библиотеку SOCKS перед “shared libc” в вашей строке поиска библиотек (переменная среды LD__LIBRARY_PATH в системах Solaris).

Доброго времени суток, дорогие друзья, знакомые, читатели, почитатели и прочие личности. В этой статье, как Вы поняли из заголовка, речь пойдет о том, что такое SOCKS сервер и зачем он вообще нужен.

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

Общее и подробное описание SOCKS

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

Он передает данные, полученные от первого клиента второму и обратно. В отличии от , через SOCKS прокси можно пустить любой трафик (скажем, ). Кроме того SOCKS передает "чистые" данные, не добавляя от себя ничего лишнего, поэтому его сложнее выявить.

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

Второе, зачем можно использовать эти сервера, - это для анонимности, а именно скрытия . В таком случае к удаленному интернет-серверу подключение устанавливаете не Вы, а SOCKS прокси, поэтому конечный сервер вряд ли получит какую-либо информацию о Вас и Вашем компьютере.

Послесловие

Вот такие дела. Надеюсь теперь Вам хотя бы примерно понятно, что это такое вообще и зачем оно в общем и целом может быть необходим.

О том, как конкретно работать с SOCKS и прочими прокси для скрытия своего IP будет написано в отдельной статье, если конечно она кому-то будет нужна и интересна.

Как и всегда, если остались какие-то вопросы, мысли, дополнения и всё такое прочее, то добро пожаловать в комментарии к этому материалу.

При работе с прокси очень важно выбрать правильный тип прокси под ваши задачи, чтобы избежать возможных проблем и достигнуть поставленных целей. Чаще всего используются HTTP прокси и Socks5 прокси. Отличия между ними заключаются в степени анонимности, используемому протоколу, способу передачи данных, используемых при работе прокси, а также в некоторых дополнительных функциях. Давайте разберём каждый тип прокси отдельно.

Особенности HTTP прокси

Начнём с HTTP прокси. При своей работе они используют HTTP протокол, который предназначен для посещения сайтов, загрузки и передачи файлов, и при работе с некоторыми программами, которые используют этот протокол для соединения через прокси. Запросы, выполняемые при работе с HTTP прокси серверами, не отправляются напрямую, а используют прокси сервер как посредника, отправляя запросы от его имени.

Также в HTTP протоколе прокси доступно кэширование, что ускоряет загрузку страниц за счёт использования сохранённых файлов, а ещё контроль и фильтрация сетевого трафика, установка ограничения скорости, блокирование нежелательных ресурсов, сбор статистики путём сохранения логов и.т.д.

Прокси этого протокола отличаются по степени анонимности. Выделяются следующие типы HTTP прокси по анонимности:

Прозрачные прокси, которые не маскируют настоящий IP адрес, а также не скрывают факт использование прокси сервера для доступа к ресурсу. Такие прокси используются редко, в основном, чтобы перенаправить пользователя на другой прокси сервер,

Анонимные Прокси. Передают информацию о том, что используются прокси, однако, ваш IP адрес маскируется и подменяется другим IP адресом, предоставляя надёжный уровень безопасности.

Элитные прокси. Скрывают использование прокси, а также надёжно маскируют IP адрес, что делает их самыми безопасными среди HTTP прокси. Сервер, к которому вы попытаетесь получить доступ будет считать, что ваше подключение осуществляется напрямую, без использования прокси сервера.

Отдельно стоит выделить HTTPS прокси, которые используют протокол SSL. Они представляют собой подвид HTTP протокола, который использует защищённое соединение. Сетевой трафик, передаваемый этими прокси надёжно зашифрован, что гарантирует высочайший уровень анонимности. Как правило, такие прокси используются для обеспечения безопасности банковских сетей, в коммерческих организациях для создания безопасных корпоративных сетей и в прочих подключениях, требующих безопасности. Остальные особенности такие же, как и у HTTP протокола.

Особенности Socks5 прокси

Другой протокол, который пользуются популярностью у пользователей - Socks5. Прокси сервера, работающие с этим протоколом изначально анонимны, поскольку они пропускают сетевой трафик в чистом виде, не раскрывая HTTP заголовков. Поэтому сервер, к которому вы пытаетесь получить доступ, не узнает о использовании прокси сервера, а также не получит ваш IP адрес.

Socks5 прокси, поддерживают следующие сетевые протоколы: HTTP, HTTPS, FTP и их особенности: кеширование, SSL соединение, аутентификация. Помимо этого, прокси протокола Socks5 используют UDP и TPC соединения, что расширяет сферу их применения и делает их наиболее функциональными из современных прокси серверов. Изначально Socks5 протокол предназначался для работы с программным обеспечением. По этой причине, большинство программ поддерживает этот протокол для подключения через прокси. А ещё прокси сервера Socks5 имеют приятную особенность, которая позволяет выстраивать цепочки из прокси серверов, что полезно для решения некоторых задач при работе в интернете.

Если сравнивать прокси HTTP и Socks5, то предпочтительней использовать вторые. Так как они анонимней, поддерживают больше функций, а также работают с любыми сайтами и программами, поддерживающие соединение через прокси. вы можете у нас на сайте, оформив заказ в личном кабинете.

Статья посвящена протоколу SOCKS5 - его внутреннему устройству, практическому применению, а также серверам и клиентам SOCKS, доступным для платформы Unix

[Валентин Синицын (val AT linuxcenter DOT ru)]

- Извини, Пух, - сказала САВА. - Тигра сжевал все провода от почтового сервера, и почта долго никак не приходила...
- Провода, - подумал Пух злобно. - Носки вязать из таких проводов.

Андрей Щербаков «9600 бод и все-все-все...»

В этой статье мы поговорим о протоколе SOCKS[сноска: «socks» - англ. «носки», «чулочки» ]. С его помощью можно решать самые разные задачи: организовывать защищенный доступ к службам, расположенным за межсетевым экраном (firewall), скрывать свой истинный IP-адрес во время работы с недружелюбными сетевыми ресурсами или реализовать универсальный прокси-сервер, поддерживающий любые протоколы прикладного уровня (HTTP, FTP, POP3/SMTP, ICQ и т.д.). К сожалению, несмотря на всю простоту и богатство возможностей SOCKS, многие системные администраторы не достаточно хорошо знакомы с ним и не представляют, чем он может быть полезен. Хочется надеяться, что после прочтения данного материала незаслуженно забытый протокол займет достойное место в их арсенале. Сразу же оговоримся: все последующее изложение будет относиться к пятой версии SOCKS, SOCKS5. Предыдущая, четвертая версия (SOCKS4), все еще имеет хождение в Сети, однако, ее возможности более ограничены.

К слову сказать, название протокола не имеет ничего общего с упомянутыми в эпиграфе чулочными изделиями и является простым сокращением от «SOCK-et-S» - «гнезда», или, в более привычном уху компьютерного специалиста переводе - «сокеты». Термин был предложен создателями в качестве рабочего варианта, да так и прижился. Как известно, сокеты лежат в основе любого API, реализующего сетевое взаимодействие - Unix, Winsock и т.п. Чтобы послать данные по сети, приложению достаточно просто записать их в сокет, подобно тому, как это делается при сохранении информации в локальном файле. И в том, и в другом случае программе не приходится заботиться о том, что происходит «за кулисами» - дополнение пользовательских данных служебной информацией, разбивка на сегменты с последующей их инкапсуляцией в датаграммы и физическая отправка осуществляется другими частями операционной системы - стеком TCP/IP и драйверами устройств, о которых приложению ничего не известно. Такое «разделение труда» позволяет как угодно изменять процедуру доставки сообщений, при условии, что интерфейс прикладного программирования остается постоянным. Именно эта особенность и лежит в основе идеологии SOCKS. Основная задача данного протокола - внедрить в «нормальный» процесс обмена данными некоего посредника, называемого SOCKS-сервером или SOCKS-прокси. Когда клиент (поддерживающее SOCKS приложение: web-браузер Mozilla, клиент ICQ Miranda IM и др., см. ниже) желает отправить какую-либо информацию по сети, он устанавливает соединение не с реальным адресатом, а с SOCKS-сервером, который, в свою очередь, пересылает данные по назначению, но уже от своего имени. С точки зрения «настоящего» сервера (например, web-узла, который пользователь желает просмотреть в Mozilla Firefox) SOCKS-прокси является самым обыкновенным клиентом. Таким образом, сущность (IP-адрес) истинного клиента оказывается скрытой от обслуживающего его сервера. Это весьма удобное обстоятельство таит в себе потенциальную опасность (можете спрятаться вы , но ведь могут и от вас ), поэтому реально существующие SOCKS-сервера имеют развитые схемы контроля доступа (запрет входящих и исходящих соединений по заданному перечню адресов) и поддерживают авторизацию пользователей по паролю (см. ниже).

Отметим, что коль скоро SOCKS работает на более низком по сравнению с прикладным (а именно, транспортном) уровне модели OSI, его поддержка не потребует никаких изменений в логике работы клиента, а тем более - сервера. Действительно, все что нужно - это модифицировать реализацию функций, отвечающих за создание сетевого подключения и отправку данных: connect(), bind(), send() и т.п. На практике это обычно достигается перехватом системных вызовов с их последующей подменой поддерживающими SOCKS пользовательскими аналогами. Никаких правок в исходном коде клиентских приложений, а тем более самого доступа к исходным текстам, как правило, не требуется. Эта мощная процедура известна как «соксификация» и будет подробно рассмотрена ниже.

Теперь, когда мы получили общее представление о SOCKS, можно перейти к более детальному рассмотрению данного протокола.

Спецификация SOCKS5

Протокол SOCKS5 подробно описан в RFC1928. В отличие от монстроподобных стандартов вроде «HTTP 1.1», спецификация SOCKS умещается на 9 страниц и может быть без труда разобрана любым желающим. Предлагаемые здесь сведения являются ее кратким конспектом и призваны помочь вам в этом несложном деле.

Как уже отмечалось ранее, SOCKS5 является протоколом транспортного уровня. Его «соседи» - TCP и UDP непосредственно используются для передачи данных, поступающих с прикладного уровня (от пользовательских приложений), а значит, SOCKS-прокси должен уметь корректно работать с каждым из них. Отметим также, что протокол ICMP, используемый утилитами ping и traceroute, находится ниже транспортного уровня, а потому соксификации, к сожалению, не поддается.[Сноска: существуют нестандартные расширения протокола SOCKS, позволяющие работать и с ICMP, однако, в данной статье они рассматриваться не будут ].

Прежде чем отправлять какие-либо данные, клиент должен пройти процедуру авторизации на SOCKS-сервере. Для этого он открывает TCP-соединение с портом 1080 (значение по умолчанию) SOCKS-сервера и отправляет по нему сообщение, содержащее кодовые номера поддерживаемых им методов аутентификации. SOCKS-сервер выбирает один из методов по своему усмотрению и сообщает его номер клиенту. Перечень некоторых из возможных значений приведен в таблице 1. Как легко видеть, аутентификация может отсутствовать (на практике это скорее всего означает, что SOCKS-сервер различает клиентов по их IP-адресам) или производиться на основании имени пользователя и пароля. В последнем случае возможно большое количество различных вариантов, от тривиального «Username/Password Authentication» (RFC 1929) предусматривающего передачу пароля в открытом виде до куда более безопасного CHAP (зашифрованный пароль, открытые данные) и GSSAPI (RFC 1961), которое может использоваться для полной криптографической защиты трафика. После успешной авторизации клиент получает возможность посылать запросы (команды), устанавливать исходящие соединения и даже принимать входящие.

Установка исходящего TCP-соединения

Для установки исходящего TCP-соединения, клиент отправляет SOCKS-серверу запрос «CONNECT», в котором указывает адрес и порт доставки. Для идентификации узла-получателя могут использоваться как IP-адреса (поддерживаются IPv4/IPv6), так и полноценные доменные имена. В последнем случае SOCKS-сервер берет на себя заботу по их разрешению, так что сеть, в которой работает клиент, в принципе может обходиться и без DNS-сервера. В ответном сообщении SOCKS-сервер сообщает код ошибки (как обычно, 0 обозначает, что операция прошла успешно), а также IP-адрес (BND.ADDR) и TCP-порт (BND.PORT), которые будут использоваться для фактической связи с запрошенным узлом. Поскольку SOCKS-сервера, как правило, имеют более одного сетевого интерфейса, данный IP-адрес может отличаться от того, с которым было установлено управляющее соединение. После этого клиент открывает новый TCP-сеанс с BND.ADDR:BND.PORT и осуществляет отправку данных. Исходящее TCP-соединение разрывается одновременно с закрытием управляющей сессии. Заметим, что запрос «CONNECT» может быть отклонен SOCKS-прокси, если адреса источника (клиента) или получателя (сервера) запрещены [Сноска: или явно не разрешены, в зависимости от конкретной реализации и выбранной политики ] к обслуживанию системным администратором.

Установка исходящего UDP-соединения

В отличие от потокового протокола TCP, подразумевающего установку сеанса, протокол UDP является датаграммным, а потому несколько более сложным в обращении. Его поддержка появилась лишь в SOCKS5.

Перед отправкой UDP-датаграмм клиент запрашивает у SOCKS-сервера UDP-ассоциацию , используя для этого команду «UDP ASSOCIATE». UDP-ассоциация - это своего рода виртуальный сеанс между клиентом и SOCKS-сервером. В исходящем запросе клиент указывает предполагаемые адрес и порт, которые будут выступать в качестве источника будущих UDP-датаграмм. Если на момент установки UDP-ассоциации эта информация еще не известна, клиент должен использовать комбинацию 0.0.0.0:0 (или, скажем, x.x.x.x:0, если неизвестен только номер порта). В ответном сообщении SOCKS-сервер указывает IP-адрес (BND.ADDR) и UDP-порт (BND.PORT), на которые следует направлять исходящие датаграммы. При этом адрес и порт их реального получателя указываются прямо в теле (можно сказать, что имеет место UDP-инкапсуляция). Э ти параметры, наряду с адресом и портом отправителя используются для принятия решения о допустимости отправки датаграммы. Как легко видеть, это создает дополнительную нагрузку на SOCKS-сервер: правила фильтрации необходимо применять к каждой UDP-датаграмме, тогда как в случае TCP-соединения его легитимность оценивается один раз, в момент исполнения SOCKS-сервером команды «CONNECT». Согласно требованиям стандарта, SOCKS-сервер должен следить за тем, чтобы IP-адрес отправителя датаграммы совпадал с адресом узла, создавшего UDP-ассоциацию. UDP-ассоциация разрушается одновременно с закрытием управляющего TCP-сеанса, в рамках которого была послана команда «UDP ASSOCIATE».

Многие из существующих SOCKS-серверов испытывают серьезные проблемы, если между ними и клиентом, запросившим UDP-ассоциацию, располагается межсетевой экран с функцией NAT (Network Address Translation). Причина этого кроется в изменении адреса и порта отправителя, которое происходит в тот момент, когда UDP-датаграмма пересекает межсетевой экран. Как следствие, сервер и ничего не подозревающее клиентское приложение начинают говорить на разных языках: предполагаемый адрес и порт источника, указанные в команде «UDP ASSOCIATE» перестают соответствовать реальным параметрам получаемых SOCKS-сервером датаграмм. В результате они оказываются отброшенными как не принадлежащие UDP-ассоциации. Проблему можно было бы решить, указав в качестве предполагаемого источника 0.0.0.0:0 (см. выше), что должно интерпретироваться SOCKS-сервером как «любая UDP-датаграмма, пришедшая с того же адреса, что и команда на создание ассоциации». К сожалению, большинство из реально существующих SOCKS-серверов трактуют стандарт более узко и не позволяют одновременно установить в ноль и предполагаемый адрес, и порт отправителя. Из протестированных автором реализаций описанный здесь «фокус с пробросом UDP через NAT» позволяет проделать лишь одна - Dante.

Прием входящих соединений

Эта достаточно оригинальная возможность может оказаться полезной в случаях, когда клиент и «настоящий» сервер в описанной выше схеме меняются местами, что может произойти, например, в протоколах типа FTP. В целях дальнейшего рассмотрения будем предполагать, что между “клиентом” (стороной, собирающейся принять входящее соединение) и “сервером” (стороной, инициирующей входящее соединение) уже установлен “прямой” канал связи при помощи команды “CONNECT”. Для открытия “обратного” канала “клиент” должен послать SOCKS-серверу команду “BIND”, указав в ее параметрах IP-адрес и порт, которые будут использоваться им для приема входящего соединения. В ответ на это SOCKS-сервер сообщает IP-адрес и порт, выделенные им для поддержания “обратного” канала. Предполагается, что «клиент» передаст эти параметры «серверу» , используя средства, предоставляемые протоколами прикладного уровня (например, команду «PORT» протокола FTP). После того, как SOCKS-сервер примет (или отбросит) входящее соединение, он повторно уведомляет об этом «клиента», сообщая ему IP-адрес и порт, используемые “сервером”. Отметим, что прием входящих соединений может осуществлять лишь приложение, разработчики которого позаботились о поддержке SOCKS еще на этапе проектирования. В противном случае (если приложение работает с SOCKS-сервером через программу-соксификатор), оно не сможет предоставить корректную информацию об адресе ожидающего “обратной связи” сокета (т.е. сформирует неверную команду “PORT” в рассмотренном выше примере с FTP).

«Цепочки» SOCKS

Давайте, работайте. Шесть арендованных “на раз” роутеров, через которые пробегает сигнал. И все достаточно стойкие к взлому.

Сергей Лукьяненко “Лабиринт отражений”

Архитектура протокола SOCKS5 позволяет легко объединять SOCKS-сервера в каскады, или, как их еще называют «цепочки» («chains»). Примечательно, что все необходимые для этого действия могут быть произведены на стороне клиента. К «звеньям» цепочки предъявляется единственное требование: они должны «доверять» друг другу (т.е. допускать установку входящих и исходящих соединений). Если образующие каскад SOCKS-сервера не являются анонимными (т.е. используют схемы аутентификации Username/Password, CHAP или подобные), необходимо также, чтобы пользователь мог успешно пройти процедуру авторизации на каждом из них.

Предположим, что у нас имеется набор из N SOCKS-серверов с именами socks1, socks2, ..., socksN, удовлетворяющих всем вышеперечисленным требованиям. Тогда для создания каскада клиент может поступить следующим образом:

    В случае исходящего TCP-соединения: клиент подключается к socks1, проходит (при необходимости) процедуру авторизации и посылает команду «CONNECT», указав в качестве адреса доставки socks2. Выполняя этот запрос, socks1 создаст новое соединение с socks2 и будет исправно передавать всю идущую по нему информацию клиенту, при этом socks2 не будет даже догадываться, с кем он общается на самом деле. Далее процедура повторяется до тех пор, пока не будет установлено соединение между socks(N-1) и socksN. Последний сервер каскада подключается к непосредственно узлу, который интересует клиента. Передача данных происходит в обычном режиме: клиент отправляет пакет на сервер socks1, который, в свою очередь, передает его socks2, ... и так до тех пор, пока не будет достигнут конечный узел.

    В случае исходящего UDP-соединения: клиент подключается к socks1, проходит процедуру авторизации и последовательно посылает две команды: “CONNECT” (адрес доставки - socks2) и “UDP ASSOCIATE”. Таким образом, создаются два новых соединения: виртуальный UDP-канал между клиентом и socks1, а также TCP-сессия между socks1 и socks2. Используя эту TCP-сессию, клиент (от имени socks1) посылает команду “UDP ASSOCIATE” на сервер socks2 (открывает UDP-канал между socks1 и socks2) и “CONNECT” на сервер socks3. Процедура продолжается до тех пор, пока между всеми SOCKS-серверами каскада не будут установлены виртуальные UDP-каналы. Чтобы отослать какие-либо данные, клиент предварительно производит N-кратную инкапсуляцию UDP-датаграммы, указывая в качестве адреса доставки последовательно: socks1, socks2, socks3, socksN и адрес реального получателя, а затем отправляет ее на сервер socks1. Отметим, что на практике данный вариант каскадирования встречается крайне редко. Это связано с тем, что SOCKS-сервера, как и NAT Firewall"ы, могут изменить порт источника датаграммы, что приведет к проблемам, подробно описанным в разделе “Установка исходящего UDP-соединения”.

Используя цепочки SOCKS-серверов, не требующих аутентификации, клиент может значительно повысить анонимность работы в Интернете (см. эпиграф). В Сети можно найти множество программ, реализующих описанные здесь схемы. Таковыми, например, являются SocksChain (http://www.ufasoft.com/socks/ ) для Windows или ProxyChains ( ) для Unix. Каскадирование SOCKS-серверов является также неотъемлемой частью некоторых соксификаторов, в первую очередь, FreeCap (http://www.freecap.ru/ ).

SOCKS-сервера

Теперь, когда принципы работы SOCKS-сервера нам хорошо знакомы, пора переходить от теории к практике. В мире существует большое количество программ, реализующих протокол SOCKS5. Они охватывают все популярные операционные системы (Unix, Windows, ...) и способы распространения (freeware, shareware, open-source и т.д.). Здесь мы вкратце рассмотрим наиболее известные (или интересные с точки зрения автора) реализации.

Начнем, пожалуй, с SOCKS5 Reference Implementation (http://www.socks.permeo.com/), выполненной компанией NEC и принадлежащей в настоящий момент фирме Permeo. Текущая версия имеет номер 1.0r11 и датирована августом 2000 года. Как легко догадаться по названию, этот сервер является справочной реализацией протокола и, вообще говоря, не предназначен для промышленного использования. Однако, по не очень понятным мне причинам, он был включен в порты FreeBSD, а посему является де-факто стандартом на данной платформе. Продукт имеет поддержку GSSAPI и распространяется в исходных текстах, но по несвободной лицензии. Коммерческое применение данного сервера запрещено.

Dante, разработанный норвежской компанией Inferno Nettverk, особенно популярен среди сторонников Linux. Продукт развивается, хотя и не очень бурно (последняя версия, 1.1.15, датирована 31 января 2005 года) и вполне пригоден для практического применения. Как уже упоминалось ранее, Dante позволяет корректно работать с UDP-ассоциациями даже в том случае, если они проходят через NAT Firewall. Программа распространяется в исходных текстах по лицензии BSD. В состав Dante входит библиотека для прозрачной соксификации Unix-приложений (см. ниже)

Валентин Синицын (val AT linuxcenter DOT ru) - Универсальный прокси-сервер