Раздел: Документация
0 ... 81 82 83 84 85 86 87 ... 125 и номер порта которого заданы клиентом. После успешной (или неудачной) попытки соединения этот сервер возвращает клиенту пакет, имеющий следующие поля: О Version Number (номер версии) - 8-битное поле, содержащее код ответа, которое должно быть равно 0; О SOCKS Result Code (код результата SOCKS) - 8-битное поле, обозначающее успешное или неудачное выполнение запроса CONNECT. Если в данное сообщение входит код неудачи, то отправив ответ, сервер SOCKS разрывает соединение с клиентом, в противном же случае начинает обмен данными между клиентом и сервером (см. рис. 15.1). Клиентская программа посылает серверу SOCKS запрос на соединение с IP-адресом и номером порта удаленного сервера, а также идентификатором пользователя Сервер SOCKS проверяет правила. Разрешен ли запрос? -Нет- Клиент извещается о неудачной попытке установки соединения Да Сервер SOCKS пытается установить соединение с удаленным сервером. Установлено ли соединение? т Да -Нет- Клиент извещается о неудачной попытке установки соединения Клиент извещается об успешной установке соединения. Начинается обмен данными между клиентом и сервером Рис. 15.1 При запросе на установку соединения сервер SOCKS должен проверить, разрешено ли оно правилами Как настраивается сервер SOCKS? SOCKS - это протокол, и производители могут изменять детали его реализации. Например, эталонная версия SOCKS V5 от NEC использует файл конфигурации /etc/socks5. conf на сервере и файл /etc/libsocks5. conf на клиенте. Чтобы определить, включена ли в ваш брандмауэр поддержка SOCKS, обратитесь к его документации. Версия 5 В последней версии протокола SOCKS добавлена поддержка аутентификации и возможность создания proxy-серверов не только для TCP, но и для UDP, а также включена поддержка доменных имен и адресации IPv6. Более подробную информацию о протоколе IPv6 вы найдете в главе 21. -; : , Запрос BIND После успешной установки соединения с помощью запроса CONNECT, клиентская программа может послать серверу SOCKS запрос BIND, сообщая ему о своем намерении установить входящее соединение с сервером приложений. Содержимое пакета с запросом BIND совпадает с содержимым запроса CONNECT, за исключением кода команды SOCKS, который должен быть равен 2. Если после проверки своих правил сервер SOCKS определит, что запрошенное соединение разрешено, он возвратит клиенту пакет с ответом, аналогичным ответу на запрос CONNECT. Сервер SOCKS выделяет сокет, к которому может подключиться сервер приложений, и возвращает клиентской программе ответ с двумя дополнительными полями: О Destination Port (порт получателя) - порт, выделенный сервером SOCKS для получения данных от сервера приложений; О Destination IP Address (IP-адрес получателя) - IP-адрес адаптера сервера SOCKS, принимающего данные от сервера приложений. Задавать его необходимо, если на сервере SOCKS установлено несколько сетевых адаптеров. Когда значение этого поля равно 0, клиент использует адрес, заданный в исходном запросе CONNECT, отправленном серверу SOCKS. Клиентская программа формирует запрос с информацией о сокете и передает его удаленному серверу приложений. Получив запрос, сервер приложений устанавливает соединение с сервером SOCKS. Последний проверяет, исходит ли это соединение от того же узла, который указан в исходном запросе BIND, и если это так, то посылает клиенту новый ответ, сообщая ему, что соединение было создано (см. рис. 15.2). Как видите, протокол SOCKS может применяться для установки соединения клиент-сервер через межсетевой экран, но сам по себе не выполняет никаких специфичных для приложения проверок. Настройка сервера SOCKS позволяет разрешать или запрещать доступ к службе определенным узлам, сетям и т.д., но не в состоянии запретить или разрешить выполнение каких-либо функций приложения. Такая функциональность должна обеспечиваться работающим с SOCKS приложением. В отличие от пакетного фильтра, сервер SOCKS не просто передает IP-пакеты между клиентом и сервером, поскольку между ними нет прямого IP-соединения. Клиентская программа посылает серверу SOCKS запрос на установку входящего соединения, содержащий IP-адрес и номер порта удаленного сервера, с которым было установлено соединение, и идентификатор пользователя Сервер SOCKS проверяет правила. Разрешен ли запрос? -* Да Сервер SOCKS получает свободный сокет (IP-адрес и номер порта) и сообщает его клиенту t Клиент сообщает серверу полученный IP-адрес и номер порта I Сервер SOCKS осуществляет обмен данными между клиентом [ и сервером Рис. 15.2. После установки соединения клиент может направить серверу SOCKS запрос BIND с целью создания входящего соединения с удаленным сервером В SOCKS V4 запрос CONNECT, посылаемый клиентской программой, включал в себя идентификатор пользователя. Сервер SOCKS использовал эту информацию, проверяя, разрешено ли данное соединение правилами. SOCKS также может проверять имя пользователя посредством протокола IDENT. Но процедура авторизации пользователя на удаленном сервере остается при этом без изменений. То есть при установке соединения по протоколу FTP имя пользователя и пароль пересылаются в незашифрованном виде и подвергаются риску быть перехваченными. В SOCKS V5 включена спецификация интерфейса, позволяющего устанавливать соединения с помощью любых протоколов аутентификации. При подключения к серверу SOCKS клиент посылает серверу сообщение с номером версии SOCKS и одним или несколькими возможными «методами» авторизации. Хотя формат пакета позволяет задавать до 255 различных методов, Клиент извещается -Нет—► о неудачной попытке установки соединения 0 ... 81 82 83 84 85 86 87 ... 125
|
