Глава 18. Прокси-серверы SQUID и SOCKS.

18.1. Что такое прокси-сервер?

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

Нет смысла устанавливать прокси на своей домашней машине, так как функции кэширования выполняет сам браузер. Прокси-сервер стоит применять лишь в том случае, если в вашей сети есть несколько компьютеров, которым нужен выход в Интернет. Если один из них уже запрашивал какой-то интернет-ресурс, то следующий пользователь, обратившийся за этим же ресурсом, получит ответ не из Интернета, а из кэша прокси- сервера, то есть значительно быстрее.

SQUID — это нечто большее, чем просто посредник. Это своеобразный стандарт кэширования информации в сети Интернет. В силу повсеместной распространенности SQUID, в книге я уделил его конфигурированию большое внимание.

Прокси-сервер SQUID образуют несколько программ, в числе которых сам демон squid, а также программа dnsserver — программа обработки DNS-запросов. Когда запускается squid, то сначала он запускает заданное количество процессов dnsserver, каждый из которых работает самостоятельно и может осуществлять только один поиск в системе DNS. За счет этого уменьшается общее время ожидания ответа DNS.

18.2. Установка SQUID.

Я использую версию squid 2.5. Пакет squid входит в состав современных дистрибутивов, а если его у вас почему-то нет, то скачать можно с www.squid-cache.org.

При сборке SQUID из исходных кодов первым шагом должна быть команда.

# ./configure --prefix=/usr/local/squid.

SQUID будет установлен в каталог, заданный ключом prefix. Другие ключи сценария configure перечислены в таблице 18.1.

Ключи сценария configure Таблица 18.1.

Ключ	Назначение
--enable-icmp	Измерить путь до каждого HTTP-сервера при запросах с помощью ICMP
--enable-snmp	Включить SNMP-мониторинг
--enable-delay-pools	Управление трафиком
--disable-weep	Отключить Web Cache Coordination Protocol
--enable-kill-parent-hack	Более корректный shutdown
--enable-splaytree	Позволяет увеличить скорость обработки ACL

18.3. Настройка SQUID.

Сервер SQUID использует файл конфигурации squid.conf, который обычно располагается в каталоге /etc/squid (или /usr/local/squid/etc — более ранние версии). Подробнее на отдельных настройках мы остановимся чуть позже. А сейчас просто по шагам произведем настройку SQUID. Отредактируйте в этом файле следующие строки.

Укажите прокси-провайдера (тот сервер, который станет вашим «соседом» (neighbour, peer)):

Cache_peer proxy.isp.ru.

Установите объем памяти, разрешенный для кэша squid, в байтах, и каталог для дискового кэша:

Cache_mem 65536.

Cache_dir ufs /usr/local/squid/cache 1024 16 256.

Где 1024 — количество мегабайтов, отводимое под кэш в указанном каталоге. В этом каталоге будут храниться кэшированные файлы. Стоит ли говорить, что если у вас несколько жестких дисков, то кэш нужно разместить на самом быстром из них.

Укажите узлы, которым разрешен доступ к прокси-серверу:

Acl allowed_hosts src 192.168.1.0/255.255.255.0.

Acl localhost src 127.0.0.1/255.255.255.255.

Укажите разрешенные SSL-порты:

Acl SSL_ports port 443 563.

Запретите метод CONNECT для всех портов, кроме указанных в acl SSL_ports:

Http_access deny CONNECT !SSL_ports.

Запретите доступ всем, кроме тех, кому можно:

Http_access allow localhost.

Http_access allow allowed_hosts.

Http_access allow SSL_ports http_access deny all.

Пропишите пользователей, которым разрешено пользоваться SQUID (в рассматриваемом примере это den, admin и developer):

Ident_lookup on.

Acl allowed_users user den admin developer.

Http_access allow allowed_users.

Http_access deny all.

Тэги maximum_object_size и maximum_object устанавливают ограничения на размер передаваемых объектов.

Ниже приведен пример запрета доступа к любому URL, который соответствует шаблону games, и разрешения доступа ко всем остальным:

Acl GaMS url_regex games.

Http_access deny GaMS.

Http_access allow all.

18.4. Запуск SQUID.

Первый раз squid нужно запускать с ключом -z, чтобы создать и очистить каталог кэша:

# /usr/local/squid/bin/squid -z.

Еще несколько полезных ключей, с которыми можно запускать squid, перечислены в таблице 18.2.

Ключи запуска squid Таблица 18.2.

Ключ	Назначение
-а порт	Задает альтернативный порт для входящих HTTP-запросов
-d	Включает ражим вывода отладочной информации в стандартный поток ошибок
-f файл	Задает альтернативный файл конфигурации, который должен будет использоваться вместо стандартного squid.conf
-h	Выдает справочную информацию
-k reconfigure	Посылает сигнал HUP, что приводит к тому, что SQUID заново прочитает свой конфигурационный файл
-k shutdown	Завершение работы прокси-сервера. При этом он подождет, пока будут завершены все соединения
-k interrupt	Немедленно завершить работу прокси-сервера, без ожидания завершения соединений
-k kill	Завершение без закрытия журналов
-u порт	Задает альтернативный порт для входящих ICP-запросов
-s	Включает журналирование с помощью syslog
-v	Выдает информацию о версии SQUID
-z	Очищает каталог кэша
-D	Запрещает DNS-тест при запуске
-N	Запрещает становиться демоном (фоновым процессом)
-Y	Более быстрое восстановление после сбоев

18.5. Расширенные настройки SQUID. Конфигурационный файл squid.conf.

18.5.1. Параметры сети.

В файле squid.conf могут быть заданы следующие параметры сети:

♦ http_port — порт для запросов клиентов. С этого порта прокси-сервер будет ожидать и обрабатывать запросы клиентов. Значение по умолчанию равно 3128;

♦ icp_port — порт для общения с соседями через ICP. Если «соседей» (peer) нет, то установите icp_port 0. По умолчанию используется значение 3130. При использовании этого параметра нужно установить ключ --enable-htcp для директивы htcp_port 4827;

♦ tcp_outgoing_address — при отправлении информации указанный адрес будет использован в качестве исходного. Значение по умолчанию: tcp_outgoing_address 255.255.255.255;

♦ udp_outgoing_address — то же самое, что и предыдущая директива — но только для ICP. Значение по умолчанию: udp_outgoing_address 255.255.255.255. То же, но для ICP при приеме — директива udp_incoming_address со значением по умолчанию 0.0.0.0;

♦ passive_ftp on | off — по умолчанию этот режим включен, но если прокси-сервер находится за брандмауэром, то параметр passive_ftp нужно выключить.

18.5.2. Параметры соседей.

«Соседи» — это другие кэширующие серверы, в кэшах которых SQUID ищет запрошенный ресурс перед тем, как обратиться к нему напрямую. Так, SQUID-сервер локальной сети может обратиться к серверу провайдера, региона и т.д. в расчете на то, что чем больше пользователей, тем больше шанс найти копию запрошенных данных ближе, чем по оригинальному адресу. Существует два типа «соседей»:

♦ parent (старший): если запрошенных данных не оказалось в кэше у parent, тот пересылает запрос дальше и возвращает подчиненному готовый ответ. Если SQUID получает отказ (TCP_DENIED) от parent, то обращается к ресурсу напрямую;

♦ sibling (равный): если запрошенных данных не оказалось в кэше у sibling, то он просто возвращает сообщение об этом, не предпринимая никаких дальнейших действий.

Каждый «сосед» прописывается отдельной строкой следующего формата:

Cache_peer hostname type proxy-port icp-port options.

Где: hostname — имя узла-«соседа»;

 type — тип соседа: parent — старший, sibling — одного уровня;

 proxy-port — порт прокси-сервера;

 icp-port — порт ICP;

 options — параметры.

18.5.3. Управление кэшем.

За управление кэшем отвечают следующие директивы:

♦ cache_mem <число> — задает размер оперативной памяти, отводимой под кэш. Размер этот указывается в байтах, килобайтах, мегабайтах (MB) или гигабайтах (GB). По умолчанию используется значение 8 MB;

♦ cache_dir <тип> <каталог> <размер> <1уровня_кат> <2уровня_кат> — задает местоположение кэша на диске и его параметры:

 • тип — тип хранения. Практически всегда используется значение ufs;

 • каталог — задает имя каталога, в котором будет храниться кэш;

 • размер — размер (в мегабайтах) отводимого под кэш пространства на жестком диске;

 • 1уровня_кат — максимальное число подкаталогов 1 уровня, которое может быть в указанном каталоге кэша;

 • 2уровня_кат — максимальное количество подкаталогов, которое может быть в каждом из подкаталогов 1 уровня.

Значение по умолчанию: cache_dir ufs /usr/local/squid/cache 100 16 256. Допускается использование нескольких записей с директивой cache_dir для определения нескольких каталогов для размещения кэша;

♦ сасhе_swap_high <число> — процент заполнения кэша, по достижении которого начинается ускоренный процесс удаления старых объектов. Значение по умолчанию равно 95;

♦ cache_swap_low <число> — процент заполнения кэша, по достижении которого прекращается удаление старых объектов. Значение по умолчанию равно 90;

♦ maximum_object_size <число> KB — максимальный размер кэшируемого объекта. Значение по умолчанию равно 4096 KB;

♦ minimum_object_size — файлы меньшего размера не кэшируются. Значение по умолчанию: 0 KB.

18.5.4. Протоколирование.

Ниже перечислены режимы протоколирования SQUID с указанием соответствующих журналов. Если какой-то журнал вам не нужен, установите none вместо имени файла.

♦ cache_access_log /usr/lосаl/squid/lоgs/ассеss.log — протоколирование запросов к SQUID:

♦ cache_log /usr/local/squid/logs/cache.log — протоколирование запусков процессов;

♦ cache_store_log /usr/local/squid/logs/store.log — протоколирование записи объектов в кэш.

18.5.5. Параметры внешних программ.

В конфигурационном файле squid.conf могут быть заданы следующие параметры внешних программ и сервисов:

♦ ftp_user email-адрес — этот email-адрес будет использоваться вместо пароля при анонимном доступе к ftp-серверам;

♦ dns_nameservers список IP-адресов — этот список используется вместо того списка DNS-серверов, который определен в файле /etc/resolv.conf; значение по умолчанию — none;

♦ cache_dns program /usr/local/squid/bin/dnsserver — указывает программу разрешения имен (сервер DNS);

♦ authenticate_program none — позволяет производить аутентификацию клиентов, делающих запросы. При этом должен быть определен ACL proxy_auth;

♦ authenticate_program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd — традиционная программа аутентификации. Определена в ../auth_modules/NCSA.

18.5.6. Параметры администрирования.

Параметры администрирования, которые можно задать в файле squid.conf, таковы:

♦ cache_mgr_email — почтовый адрес, на который будет послано письмо, если SQUID перестанет функционировать;

♦ cache_effective_user nobody — при запуске SQUID от имени root изменить UID на указанный в параметре сасhе_effective_user:

♦ cache_effective_group nogroup — при запуске SQUID от имени root изменить GID на указанный в параметре cache_effective_group;

♦ visible_hostname имя_узла — это имя будет упоминаться в сообщениях об ошибках;

♦ hostname_aliases имя — этот параметр задает список синонимов для имени узла.

18.6. Списки ACL.

ACL (Access Control Lists) — списки контроля доступа. Довольно часто возникает необходимость группировки однотипных параметров в единое целое для их последующей обработки. Для эффективного решения этой задачи используются списки ACL. Например:

Acl SSL_ports port 443 563.

Эта запись означает, что создается список SSL_ports типа port. Элементами списка являются номера портов 443 и 563.

Добавить новый элемент к уже существующему списку можно так:

Acl add SSL_ports port 999.

Удалить ненужный элемент можно с помощью операции del:

Acl del SSL_ports 999.

Переименовать список позволяет операция ren:

Acl ren SSL_ports Allowed_ports.

Удалить все списки вместе с их содержимым позволяет операция flush:

Acl flush.

Стандарт ACL требует, чтобы перед именем списка обязательно был указан символ $. Строго говоря, все перечисленные выше примеры без этого символа неправильны. Однако большинство фильтров, например SQUID, пренебрегают этим требованием, и вы можете указывать имена списков без знака доллара.

Итак, ACL — это определение списка доступа, имеющее следующий формат:

Acl <имя> <тип> <регулярное_выражение>

Типы, которые можно использовать при составлении списков ACL, перечислены в таблице 18.3.

Типы ACL Таблица 18.3.

Тип	Назначение
Src IP-адрес/маска	IP-адрес клиентов
Src IP1-IP2/маска	Диапазон адресов
Dst IP-адрес/маска	URL узлов
Time [день] [Ч1:М1-Ч2:М2]	Время, где день — это одна буква из SMTWHFA
Port	Список портов
Port port1-port2	Диапазон портов
Proto	Протокол — HTTP или FTP
Method	Метод — GET или POST
Browser [-i] рег_выражение	Заголовок браузера клиента, [-i] — игнорируется регистр букв

18.6.1. Параметры доступа.

Параметры доступа в файле squid.conf задаются следующими директивами:

♦ http_access allow | deny aclname — разрешать доступ к прокси по HTTP;

♦ icp_access allow | deny aclname — разрешать доступ к прокси по ICP;

♦ miss_access allow | deny aclname — разрешать получать ответ MISS («не найден») от вас;

♦ cache_peer_access cache-host allow | deny aclname — ограничить запросы к данному соседу — расширение для cache_peer_domain;

♦ proxy_auth_realm Squid proxy-caching web server — строка текста, которая будет выдана на экран клиента при запросе имени/пароля доступа к кэшу.

18.7. Отказ от рекламы. Баннерный фильтр.

Вам не хочется тратить лишнее время на загрузку рекламных баннеров? Мне тоже. К счастью, SQUID позволяет достаточно просто решить эту проблему. Просто вставьте следующие строки в свой файл squid.conf:

Acl good_url url_regex "/usr/local/etc/sguid/acl/good_url".

Acl bad_urlpath urlpath_regex "/usr/local/etc/squid/acl/bad_urlpath".

Acl bad_url url_regex "/usr/local/etc/squid/acl/bad_url".

Http_access deny bad_ur_path !good_url.

Http_access deny bad_url !good_url.

Соответственно, нужно будет создать три файла: good_url, bad_url_path и bad_url. В файл bad_url следует поместить URL с плохой репутацией, например:

^http://.*doubleclick.

^http://.*-ad.flycast.com/server/img/

^http://1000.stars.ru/cgi-bin/1000.cgi.

^http://12.16.1.10/~web_ani/

А в файл bad_url_path — «плохие» пути, например, такие, которые часто бывают у баннеров:

88x31.*gif.

88x31.*GIF.

100x80.*gif.

100x80.*GIF.

100x100.*gif.

100x100.*GIF.

120x60.*gif.

120x60.*GIF.

179x69.*gif.

193x72.*gif.

468x60.*gif.

Примеры файлов good_url, bad_url_path и bad_url можно взять на моей домашней страничке http://dkws.narod.ru.

18.8. Разделение канала с помощью SQUID.

Допустим, вам нужно настроить прокси-сервер таким образом, чтобы одна группа компьютеров работала в Интернете с одной скоростью, а другая — с другой. Это может потребоваться, например, для разграничения пользователей, которые используют канал для работы, и пользователей, которые используют ресурсы канала в личных целях. Естественно, первым пропускная способность канала важнее, чем вторым. С помощью прокси-сервера SQUID можно разделить канал.

Для начала в файле конфигурации squid.conf укажите, сколько пулов, то есть групп пользователей, у вас будет:

Delay_pools 2.

Затем определите классы пулов. Всего существует три класса:

♦ Используется одно ограничение пропускной способности канала на всех.

♦ Одно общее ограничение и 255 отдельных для каждого узла сети класса С.

♦ Для каждой подсети класса В будет использовано собственное ограничение и отдельное ограничение для каждого узла.

В файл squid.conf добавьте следующие директивы:

Delay_class 1 1 # определяет первый пул класса 1 для.

# домашних пользователей.

Delay_class 2 2 # определяет второй пул класса 2 для.

# служащих.

Теперь задайте узлы, которые будут относиться к пулам:

Acl home src адреса.

Acl workers src адреса.

Delay_access 1 allow home.

Delay_access 1 deny all.

Delay_access 2 allow workers.

Delay_access 2 deny all.

Затем укажите ограничения:

Delay_parameters 1 14400/14400.

Delay_parameters 2 33600/33600 16800/33600.

Для пула класса 1 используется одно ограничение для всех компьютеров, входящих в пул — 14400 байт. Первое число задает скорость заполнения для всего пула (байт/сек). Второе — максимальное ограничение.

Для пула класса 2 используются ограничения на всю подсеть и отдельно на каждого пользователя. Если бы у нас был определен пул класса 3, то для него ограничения выглядели бы примерно так:

Delay_parameters 3 128000/128000 64000/128000 12800/64000.

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

18.9. Настройка поддержки прокси у клиентов.

После того, как вы настроили прокси-сервер, осталось напомнить процедуру настройки использования прокси для некоторых распространенных браузеров.

Настройка Internet Explorer под использование прокси-сервера производится следующим образом: в окне Сервис→Свойства обозревателя→Подключение→Настройка сети установите необходимые параметры, то есть имя прокси-сервера и его порт.

Если вам нужно настроить использование прокси-сервера для Netscape Communicator, то выберите из меню Edit→Preferences→Advanced→Proxies→Manual Proxy Configuration→View (рис. 18.1). В появившемся окне установите необходимые параметры, то есть имя прокси-сервера и его порт.

Рис. 18.1. Настройка Netscape Communicator.

Теперь посмотрим, как настроить использование прокси-сервера для популярного Linux-браузера Konqueror. Выберите в строке меню команду Настройка→Настроить Коnquеrоr→Прокси (рис. 18.2). Нажмите кнопку Настроить и укажите имя прокси-сервера и его порт.

Рис. 18.2. Настройка Konqueror.

18.10. Технология SOCKS5, или как использовать аську из локальной сети.

18.10.1. Введение в SOCKS. Прокси-сервер SOCKS5.

Технология SOCKS основывается на использовании одноименных протокола и прокси-сервера. Может возникнуть вопрос: «Зачем нам еще один прокси-сервер, если мы уже рассмотрели SQUID?». А дело в том, что прокси-сервер SQUID работает на протоколах верхнего уровня (HTTP, FTP) и жестко к ним привязан. Однако существуют приложения, работающие непосредственно на транспортных протоколах TCP и UDP и испытывающие проблемы при взаимодействии. Для решения этих проблем и был разработан протокол SOCKS. Он позволяет приложениям, работающим по TCP и UDP, использовать ресурсы сети, доступ к которым ограничен в силу архитектуры или настроек сети.

Классическим и основным примером является использование интернет-пейджера ICQ из локальной сети, защищенной брандмауэром (межсетевым экраном). У локального пользователя нет реального IP-адреса и прямого выхода в Интернет, а весь трафик направляется через сервер-шлюз сети, на котором установлен брандмауэр, не пропускающий трафика от ICQ.

Решает проблему пересечения межсетевых экранов клиент/серверными приложениями, работающими по протоколам TCP и UDP, установка сервера SOCKS на шлюзе. При этом через сервер SOCKS будет осуществляться перенаправление запросов на удаленную машину, а также прозрачная передача трафика после установки соединения.

Нужно отметить, что оба прокси-сервера (SOCKS5 и SQUID) могут быть установлены на одном сервере и функционировать одновременно, не мешая друг другу.

Примечание. Теоретически для решения проблемы пересечения бастиона можно было бы использовать IP-маскарадинг. При этом TCP/UDP-пакеты паковались бы в HTTP-сообщения (или другие протоколы верхнего уровня) и шлюз записывал бы в них свои заголовки (свой IP-адрес). В результате казалось бы, что эти пакеты исходят от него самого. Но такое решение имеет много минусов, обусловленных протоколами верхнего уровня и связанными с ними заморочками. Кроме того, в какой-то степени теряется анонимность: ведь при использовании SOCKS информация об IP вообще не передается (это не предусмотрено самой технологией). А еще, поскольку в SOCKS заголовков HTTP нет совсем, никто не сможет определить, что вы использовали прокси-сервер.

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

Что касается версий протокола, то они отличаются следующим:

♦ SOCKS4 — основывается на TCP;

♦ SOCKS5 — работает как с TCP, так и с UDP. Кроме того, в нем расширена система адресации, поддерживается авторизация и удаленные DNS-запросы.

Клиентами сервера SOCKS5 являются популярные клиенты ICQ и licq, клиентская версия оболочки ssh, а также другие программы.

18.10.2. Настройка сервера SOCKS5.

Популярный прокси-сервер, работающий по протоколу SOCKS5, поддерживает компания Permeo ( www.socks.permeo.com). Я пользуюсь socks5 v1.0 release 11 и настройку рассмотрю на его примере. Этот сервер не в полной мере некоммерческий (лицензия — не GPL), поэтому вам может быть удобнее использовать альтернативы — DeleGate ( www.delegate.org) или Dante ( www.inet.no/dante). О последнем я скажу в п.18.10.4.

Все настройки сервера socks5 содержатся в конфигурационном файле /etc/socks5.conf. В большинстве случаев параметры по умолчанию вполне приемлемы. Сейчас мы рассмотрим пример конфигурационного файла (листинг 18.1), а потом разберемся, что все это означает.

Листинг 18.1. Файл /etc/socks5.conf.

Set SOCKS5_NOREVERSEMAP.

Set SOCKS5_NOSERVICENAME.

Set SOCKS5_NOIDENT.

Set SOCKS5_MAXCHILD 128.

Set SOCKS5_TIMEOUT 10.

Auth - - u.

Permit u - - - - - -

Interface 192.168.0. - eth0.

В первой строке мы отменяем обратное разрешение адресов, благодаря чему сервер будет работать заметно быстрее. Вторая строка означает, что мы будем протоколировать номера портов вместо имен сервисов. Теоретически это тоже должно повысить эффективность работы сервера. Параметр SOCKS5_NOIDENT запрещает рассылку клиентам ident-запросов. Четвертая строка устанавливает максимально допустимое число потомков сервера — не жадничайте. Пятая строка, как вы уже успели догадаться, устанавливает тайм-аут (10 секунд).

Вся остальная настройка сервера выполняется с помощью директив auth и permit. Первая устанавливает тип аутентификации, а вторая разрешает доступ определенным узлам и пользователям. Полный формат директивы auth такой:

Auth <исходный_узел> <исходный_порт> <метод_аутентификации>

В приведенном примере мы будем запрашивать пароль у всех клиентов.

Формат директивы permit:

Permit <аутентификация> <команда> <исх_узел> <узел_назначения> <исх_порт> <порт_назнач> [список_пользователей].

В примере я разрешаю доступ всем и отовсюду с использованием аутентификации. Следующий пример использования директивы permit демонстрирует гибкость этого прокси-сервера:

Permit u cpubt 192.168. - - [100,1000] den.

В этом примере мы разрешаем доступ пользователю den (с использованием пароля, конечно). Пользователь den имеет право использовать Connect, Ping, UDP, BIND и Traceroute (cpubt) с адресов 192.168.*.*. Диапазон входящих (первый «-») и исходящих (второй «-») портов — от 100 до 1000.

В дополнение к директиве permit можно использовать директиву deny такого же формата, но противоположного назначения (запрет доступа).

Директива interface в приведенном примере разрешает все соединения от компьютеров с адресами 192.168.0.* (наша внутренняя сеть) ко всем портам интерфейса eth0.

Имена и пароли пользователей сервера socks5 содержатся в файле /etc/socks5.passwd в формате <имя> <незашифрованный_пароль>. После создания этого файла настройку socks5 можно считать законченной.

18.10.3. Запуск сервера socks5.

Запускается сервер следующей командой:

# /usr/local/bin/socks5 -f -s.

При запуске с этими ключами демон должен перейти в фоновый режим и выводить диагностические сообщения на стандартный вывод (в нашем случае это экран). Если сервер сконфигурирован правильно, вы должны увидеть примерно следующее:

11410: Socks5 starting at Mon Mar 4 19:13:55 2002 in normal mode.

После удачного запуска остановите сервер ( killall socks5) и добавьте его запуск в сценарий автозагрузки системы.

18.10.4. Dante — еще один сервер SOCKS5.

Этот сервер считается более простым в настройке. Он использует файл конфигурации /etc/sockd.conf (листинг 18.2).

Листинг 18.2. Примерный файл /etc/sockd.conf.

Internal: 192.168.0.1 port = 1080.

External: 111.111.111.111.

Client pass {

 from: 192.168.0.0/16 to: 0.0.0.0/0.

}

Pass {

 from: 0.0.0.0/0 to: 192.168.0.0/16.

 command: bindreply udpreply.

 log: connect error.

}

Директива internal определяет ваш внутренний интерфейс (точнее, внутренний IP-адрес), a external — ваш настоящий IP (111.111.111.111). В блоке client pass указываются возможные клиенты вашего сервера (сеть 192.168.0.0), а в блоке pass — имена узлов, которые могут «общаться» с вашими клиентами. В приведенном примере разрешается отвечать клиентам со всех узлов (0.0.0.0). Протоколироваться будут только ошибки соединения.

18.10.5. Настройка клиентов SOCKS5 (ICQ и licq).

Настройку клиентов будем рассматривать на примере двух самых, наверное, популярных SOCKS-клиентов. Сначала рассмотрим настройку программы ICQ для Windows, а потом licq — ICQ-клиента для Linux.

Запустите программу ICQ и нажмите на кнопку ICQ. Из появившегося меню выберите команду Preferences и перейдите в раздел Connections на вкладку Server (рис.18.3). Включите режим использования прокси-сервера и установите тип прокси-сервера — SOCKS5. Потом перейдите на вкладку Firewall и установите параметры прокси-сервера: имя, порт, тип (socks5), имя пользователя и пароль (рис. 18.4).

Рис. 18.3. Свойства соединения ICQ.

Рис. 18.4. Параметры прокси-сервера.

С программой licq будет немножко сложнее. Во-первых, нужно установить на компьютере пользователя программу runsocks, входящую в состав пакета прокси-сервера (эту программу можно также найти в Интернете отдельно), и перекомпилировать licq, включив поддержку SOCKS5. Для этого перейдите в каталог, содержащий исходные тексты licq, и запустите сценарий configure с параметром --enable-socks5:

$ ./configure —enable-socks5.

После этого выполните привычные команды: make; make install.

Теперь нужно создать файл /etc/libsocks5.conf и добавить в него строку:

Socks5 - - - - 192.168.0.1:port.

192.168.0.1 — это адрес вашего SOCKS5-сервера, port — порт, необходимый клиенту (обычно 1080).