5. Адресация
Тип адреса содержащегося в адресном поле (DST.ADDR, BND.ADDR),
определяется содержимым поля ATYP:
адрес является адресом IP v4, длинна адреса 4 октета
поле адреса содержит имя домена. Первый октет адресного поля содержит
число октетов в последующем за ним имени, завершающий NUL-октет в конце
строки не применяется.
адрес является адресом IP v6, длинна адреса 16 октет
6. Ответы
SOCKS-запрос посылается клиентом как только он установил соединение с
SOCKS-сервером и выполнил аутентификацию. Сервер обрабатывает запрос и
посылает ответ в следующей форме:
Код:
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Где:
Код:
o VER версия протокола: X'05'
o REP код ответа:
o X'00' успешный
o X'01' ошибка SOCKS-сервера
o X'02' соединение запрещено набором правил
o X'03' сеть недоступна
o X'04' хост недоступен
o X'05' отказ в соединении
o X'06' истечение TTL
o X'07' команда не поддерживается
o X'08' тип адреса не поддерживается
o X'09' до X'FF' не определены
o RSV зарезервирован
o ATYP тип последующего адреса
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o BND.ADDR выданный сервером адрес
o BND.PORT выданный сервером порт (в сетевом порядке октетов)
Значения зарезервированных (RSV) полей должны быть установлены в X'00'.
Если выбранный метод аутентификации требует особое формирование пакетов
с целью проверки целостности и/или конфедициальности, запросы должны
инкапсулироваться в пакет, формат которого определяется выбранным
методом.
CONNECT
В ответ на CONNECT, BND.PORT содержит номер порта, который сервер
назначает для соединения с указанным хостом, а BND.ADDR содержит
связанный IP-адрес. Выданный BND.ADDR зачастую отличается от
IP-адреса, который клиент использует для доступа к SOCKS-северу,
так как такие сервера часто имеют несколько IP-адресов. Ожидается,
что сервер будет использовать DST.ADDR и DST.PORT и адрес клиента
при обработке запроса CONNECT.
BIND
Запрос BIND используется в протоколах, которые требуют чтобы клиент
принимал соединение со стороны сервера. Хорошим примером этого
является FTP, который использует основное соединение клиент-к-серверу
для комманд и сообщений, но может использовать соединение
сервер-к-клиенту для передачи данных по запросу (например LS, GET, PUT).
Ожидается, что клиентская сторона прикладного протокола будет
использовать запрос BIND только для установки вторичного соединения,
после первичного соединения, установленного с использованием CONNECT.
Ожидается, что сервер будет использовать DST.ADDR и DST.PORT
при обработке запроса BIND.
SOCKS-сервер посылает два ответа клиенту в течении операции BIND.
Первый послыается после того, как сервер создает и привязывает
новый сокет. Поле BND.PORT содержит номер порта, который SOCKS-сервер
выделил для входящего соединения. Поле BND.ADDR содержит связанный
IP-адрес. Клиент может использовать эту информацию для уведомления
(через первичное соединение) приложения-сервера об адресе для
взаимодействия. Второе уведомление происходит после ожидаемого
входящего соединения или неудачной попытке входящего соединения.
При втором ответе поля BND.PORT и BND.ADDR содержат адрес и номер
порта присоединившегося хоста.
UDP ASSOCIATE
Запрос UDP ASSOCIATE используется для установления соединения
посылающим UDP-сообщения процессом. Поля DST.ADDR и DST.PORT содержат
адрес и порт, на который клиент собирается слать UDP-датаграммы
после установки соединения. Сервер может использовать эту информацию
в целях ограничения доступа. Если клиент не располагает информацией
об адресе на момент запроса UDP ASSOCIATE, то клиент должен заполнить
нулями номер порта и адреса.
UDP-связь обрывается, когда обрывается TCP-соединение выполнившее
запрос UDP ASSOCIATE.
В ответе на запрос UDP ASSOCIATE, поля BND.PORT и BND.ADDR определяют
порт и адрес, куда клиент должен слать UDP-датаграмы для пересылки.
Обработка ответов
Когда приходит ответ с сообщением о неудаче (значение REP не равно
X'00'), то SOCKS сервер должен оборвать TCP-соединение вскоре после
посылки ответа. Это должно произойти не более чем спустя 10 секунд
после определения причин вызвавших неудачу.
При получении ответа с сообщением об удаче (значение REP равно X'00'),
если запросом был BIND или CONNECT, то клиент может начинать передавать
данные. Если выбранная схема аутентификации требует особое формирование
пакетов с целью проверки целостности и/или конфедициальности, данные
должны инкапсулироваться в пакет, формат которого определяется выбранным
методом. Подобно этому, когда данные для клиента получаются
SOCKS-сервером, сервер должен инкапсулировать данные согласно тому,
как это требует выбранный метод аутентификации.
7. Процедура для клиентов работающих по UDP
Клиент, работающий по UDP, должен посылать свои датаграмы на
порт пересылающего их UDP-сервера, указанного в поле BND.PORT в
ответе на запрос UDP ASSOCIATE. Если выбранная схема аутентификации
требует особое формирование пакетов с целью проверки целостности
и/или конфедициальности, датаграмма должна инкапсулироваться в пакет,
формат которого определяется выбранной схемой. Каждая UDP-датаграма
содержит в себе заголовок UDP-запроса:
Код:
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
Поля заголовка UDP-запроса:
Код:
o RSV зарезервировано X'0000'
o FRAG текущий номер фрагмента
o ATYP тип адреса:
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o DST.ADDR требуемый целевой адрес
o DST.PORT требуемый целевой порт
o DATA пользовательские данные
Когда пересылающий UDP-датаграммы сервер пересылает датаграмму, он
делает это молча, без какого-либо уведомления выполнившего запрос
клиента. Аналогично, сервер будет молча отбрасывать датаграммы,
которые он не может или не будет пересылать. Когда пересылающий
UDP-датаграммы сервер получает ответную датаграмму с удаленного
хоста, он должен инкапсулировать эту датаграмму используя помимо
заголовка UDP-запроса еще и инкапсуляцию, определяемую выбранной
схемой аутентификации.
Обращение к пересылающему UDP-датаграммы серверу должно производиться
с ожидаемого SOCKS-сервером IP-адреса клиента, который (клиент) будет
посылать датаграммы на BND.PORT, данный в ответе на UDP ASSOCIATE.
Сервер должен отбрасывать датаграммы полученные с любого IP-адреса,
отличного от того, что был записан для этой связи.
Поле FRAG показывает, является ли эта датаграмма самостоятельной или
же фрагментом. Если датаграмма - фрагмент, то установленный старший
бит является признаком последнего фрагмента, в то время как значение
X'00' показывает, что это обычная датаграмма. Значения от 1 до 127
обозначают на позицию фрагменте в последовательности. Каждый
получатель будет иметь REASSEMBLY QUEUE (очередь сборки) и REASSEMBLY
TIMER (таймер сборки) связанные с такой фрагментной датаграммой.
Очередь сборки должна быть переинициализирована и связанные с ней
фрагменты выкинуты всякий раз при истечении таймера сборки или
с приходом новой датаграммы, чье значение в поле FRAG меньше,
чем наибольшее значение поля FRAG датаграмм, обработанных
при сборке фрагмента. Таймер сборки должен быть не менее 5 секунд.
Приложениям рекомендуется избегать фрагментацию везде, где только
это возможно.
Реализация фрагментации опциональна, в реализациях где фрагментация
не поддерживается, должны отбрасываться любые датаграммы, у которых
поле FRAG отлично от X'00'.
Программный интерфейс для UDP работающего через SOCKS должен сообщать
о оставшемся свободном пространстве в буфере для UDP-датаграмы, которое
меньше, чем действительный размер буфера, выделенный операционной
системой:
Код:
o если ATYP равен X'01' - на 10+зависит_от_метода октетов меньше
o если ATYP равен X'03' - на 262+зависит_от_метода октетов меньше
o если ATYP равен X'04' - на 20+зависит_от_метода октетов меньше
Иными словами, так как в заголовке UDP-запроса, включенного в датаграмму,
нет информации о длинне данных, то приложение должно помнить об этом
самостоятельно.
8. Замечания по безопасности
Этот документ описывает протокол для работы на прикладном уровне
с файрволлами в IP-сетях. Безопасность такой работы в большой
степени зависит от особенностей аутентификации и инкапсуляции
методов, обеспеченных в конкретной реализации и выбранных
во время соединения клиента с SOCKS-cервером.
При выборе метода аутентификации администраторы должны проявить особое
внимание.