Протокол SOCKS5 [RFC-1928] предназначен для прозрачного и безопасного прохождения сложных протоколов прикладного уровня через межсетевой экран типа посредник приложений (англ. application proxy). Одним из основных требований к безопасности в этом смысле является строгая аутентификация. SOCKS5 завоевал широкую популярность в Интернете из-за простоты своего функционирования в сочетании с широкой универсальностью выполняемых функций. Протокол разработан для обеспечения функционирования клиент/серверных приложений поверх TCP или UDP (в отличии от версии 4) и работает в виде некоей прослойки между прикладным и транспортным уровнями, не предоставляя никаких сервисов сетевого уровня. Протокол различает работу TCP- и UDP-клиентов.
Когда TCP-клиент хочет установить соединение с сервером, который доступен только через межсетевой экран, он должен установить соединение с управляющим портом SOCKS-сервера (номер порта, зарегистрированный IANA, – 1080). В рамках управляющего соединения сервер обрабатывает запрос и производит следующие действия:
согласовывает метод аутентификации клиента;
аутентифицирует клиента выбранным методом;
в случае необходимости производит трансляцию имени удаленного сервера в сетевой адрес (например, DNS-имени в IP-адрес).
Затем SOCKS-сервер устанавливает два соединения вне управляющего соединения для передачи данных.
Соединение между собой и удаленным сервером, в рамках которого он от своего имени будет пересылать все запросы клиента и принимать ответы на них; порт SOCKS-сервера в сторону удаленного ресурса выбирается произвольно динамически, и в случае необходимости сообщается клиенту (в рамках управляющего соединения).
Соединение между собой и клиентом, в рамках которого клиентом будут передаваться запросы к удаленному серверу и возвращаться SOCKS-сервером ответы на них от удаленного ресурса; порт SOCKS-сервера в сторону клиента выбирается произвольно динамически и всегда сообщается клиенту (в рамках управляющего соединения).
Как и в любой прокси-технологии (англ. рoху – посредник),клиент никогда не производит соединения непосредственно с удаленным сервером. Все данные как в прямом, так и в обратном направлении проходят через SOCKS-сервер.
Еще один важный момент: поскольку аутентичность клиента является одной из наиболее важных функциональных нагрузок протокола SOCKS5, то в нем заложена жесткая привязка к управляющему соединению. Как только случайно или предумышленно разрывается соединение клиента на управляющий порт, сразу же SOCKS-сервер перестает транслировать данные как в прямом, так и в обратном направлении во всех "рабочих" соединениях данного клиента. Это касается как TCP, так и UDP-соединений.
Для обеспечения совместимости реализация протокола обязательно должна поддерживать аутентификацию GSS-API и желательно поддерживать аутентификацию username/password.
Если в запросе указан тип Connect, то происходит активное подключение (клиент инициирует сессию к удаленному ресурсу). В этом случае поля BND.ADDR и BND.PORT содержат адрес и порт, на которых SOCKS-сервер открыл соединение в сторону клиента. В рамках этого соединения SOCKS-сервер будет транслировать все данные, пришедшие от удаленного сервера. При запросе типа Connect адрес и порт соединения, открытого SOCKS-сервером в сторону удаленного ресурса, остаются для клиента неизвестными.
Если в запросе указан тип Bind, то это означает, что подключение должно было произойти по пассивной схеме. Если бы не было межсетевого экрана, то клиент должен был открыть на ожидание сессии произвольный порт, сообщить его номер удаленному серверу, а уже тот – инициировать сеанс на указанный номер порта клиента. Классическим примером протокола, требующего по умолчанию для передачи данных именно такой тип соединения, является FTP. Однако межсетевой экран, если такой существует между клиентом и сервером, не должен позволять удаленному хосту инициировать соединения на произвольный (как это кажется экрану, ведь номер был выделен операционной системой динамически) порт клиента (а для МСЭ соединение покажется именно инициированным извне на "случайный" порт).
Существует два решения этой проблемы. Можно заставить межсетевой экран "читать" команды протоколов прикладного уровня (например, того же FTP), выделять в них сообщения от клиента с указанием номера открытого им порта и временно заносить этот порт в список разрешенных к соединению со стороны удаленного сервера. Данная технология носит наименование application recognition (AR) – распознавание приложений, у нее есть и несомненные преимущества и недостатки.
Второй метод основан на использовании прокси-серверов прикладного уровня, каковым и является SOCKS-сервер. Рассмотрим, как происходит соединение.
1. Клиент отправляет SOCKS-серверу запрос типа Bind.
2. SOCKS-сервер открывает в сторону удаленного ресурса динамически произвольный порт в режиме ожидания соединения и сообщает клиенту в рамках управляющей сессии в первом своем ответе адрес и порт открытого соединения (поля BND.ADDR и BND.PORT).
3. Клиент формирует запрос прикладного уровня, в котором требовалось указать порт пассивного соединения, но подставляет туда не свой адрес, а присланные от SOCKS-сервера параметры.
4. Как только в адрес открытого SOCKS-сервером в режиме ожидания порта приходит первый пакет от удаленного ресурса (запрос на инициирование соединения), SOCKS-сервер высылает в рамках управляющей сессии второй ответ клиенту, указывая в полях BND.ADDR и BND.PORT адрес и порт, открытые им для этого потока уже в сторону клиента.
5. После установления всех соединений SOCKS-сервер начинает прозрачно транслировать данные в обоих направлениях подобно тому, как если бы соединение устанавливалось по типу Connect.
Для запроса UDP-Associate, используемого для возможности пересылки UDP-датаграмм через межсетевой экран, в полях BND.ADDR и BND.PORT ответа SOCKS-сервер указывает свои адрес и порт, куда клиент обязан посылать UDP-запросы, которые должны пересылаться удаленному ресурсу. Напомним, что ассоциация сразу же прекращается с разрывом управляющего ТСР-соединения.
Клиент должен направлять свои датаграммы (UDP-relay) SOCKS-серверу, производя инкапсуляцию (сокрытие значимых данных) датаграммы, если это требуется выбранным методом аутентификации.
Несколько слов о том, зачем было необходимо включать в ответ SOCKS-сервера поле BND.ADDR, и использовать именно его, а не первоначальный адрес управляющей сессии, при открытии клиентом вторичных соединений. Дело в том, что при разработке протокол SOCKS5 позиционировался как схема, позволяющая создавать целый кластер прокси-серверов, работающих под управлением мастер-сервера. В этом случае мастер-сервер поддерживает только управляющие сессии со всеми подключенными к кластеру клиентами, а всю нагрузку на собственно трансляцию потоков данных (то есть вторичные соединения) несут распределенно несколько "рабочих" серверов.
При обработке каждого очередного запроса от клиента мастер-сервер по какому-либо правилу выбирает один "рабочий" сервер и обменивается с ним всей необходимой информацией о запросе. Затем в ответе клиенту в поля BND.ADDR и BND.PORT подставляются уже координаты "рабочего" сервера трансляции.
В заключение необходимо добавить, что существуют отдельные документы, описывающие способы аутентификации SOCKS. Для метода GSS-API – это [RFC-1961], для метода username/password – [RFC-1929].
