Начальная настройка прокси-сервера Squid. Установка и настройка Squid на CentOS Порт squid по умолчанию

Squid - это полнофункциональное приложение кэширующего прокси сервера, которое предоставляет сервисы кэширования и прокси для HTTP , FTP и других популярных сетевых протоколов. Squid может осуществлять кэширование и проксирование SSL запросов и кэширование результатов DNS поиска, а также выполнять прозрачное кэширование. Squid также поддерживает широкий набор кэширующих протоколов, таких как ICP (кэширующий интернет протокол), HTCP (гипертекстовый кэширующий протокол), CARP (протокол кэширования маршрутизации) и WCCP (кэширующий протокол перенаправления контента).

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

Установка

В терминале введите следующую команду для установки сервера Squid:

Sudo apt-get install squid

Настройка

Squid настраивается редактированием директив, содержащихся в конфигурационном файле /etc/squid/squid.conf. Следующие примеры иллюстрируют некоторые директивы, которые могут быть изменены для воздействие на поведение сервера Squid. Для более глубокой настройки Squid смотрите раздел .

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

Скопируйте файл /etc/squid/squid.conf и защитите его от записи следующими командами в терминале:

Sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.original sudo chmod a-w /etc/squid/squid.conf.original

1. Для настройки вашего сервера Squid на прослушивание порта 8888 вместо стандартного 3128, измените директиву http_port как показано здесь:

Http_port 8888

2. Измените директиву visible_hostname для того, чтобы присвоить серверу Squid определенное имя хоста (hostname). Это имя необязательно должно быть именем хоста компьютера. В примере оно определено как weezie:

Visible_hostname weezie

3. Используя контроль доступа Squid, вы можете настроить, чтобы использование интернет сервиса прокси было доступно только пользователям с определенных IP адресов. Например, мы проиллюстрируем доступ пользователей только из подсети 192.168.42.0/24:

ACL

Acl fortytwo_network src 192.168.42.0/24

http_access вашего файла /etc/squid/squid.conf:

Http_access allow fortytwo_network

4. Используя великолепные возможности контроля доступа Squid, вы можете настроить возможность использования интернет сервиса прокси только в обычные рабочие часы. Например, мы покажем как настроить доступ сотрудников, которые работают с 9:00 до 17:00 с понедельника по пятницу из подсети 10.1.42.0/24:

Добавьте следующее в конец секции ACL вашего файла /etc/squid/squid.conf:

Acl biz_network src 10.1.42.0/24 acl biz_hours time M T W T F 9:00-17:00

Затем добавьте следующее в начало секции http_access вашего файла /etc/squid/squid.conf:

Http_access allow biz_network biz_hours

После внесения изменений в файл /etc/squid/squid.conf сохраните его и перегрузите приложение сервера squid, чтобы изменения вступили в силу, следующей командой в терминале: sudo /etc/init.d/squid restart

Описание параметров файла конфигурации Squid.conf

Squid.conf это файл конфигурации прокси-сервера Squid .
Статья даёт описание параметров squid.conf , не связывая их между собой.
Пример рабочего файла конфигурации приведен в статье о Squid .

Описание параметров файла

# /etc/squid/squid.conf: файл конфигурации прокси-сервера Squid http_port 192.168.0.1:3128 - где находится прокси hierarchy_stoplist cgi-bin ? | acl QUERY urlpath_regex cgi-bin \? | no_cache deny QUERY |-> запрет кэширования файлов находящихся в каталоге cgi-bin cache_mem 64 MB - объем памяти под кэширование (например 1/3 ОЗУ) maximum_object_size 10240 KB - максимальный размер кэшируемого объекта cache_dir ufs /var/spool/squid 10240 16 256 - местонахождение и структура кеша squid cache_access_log /var/log/squid/access.log - местонахождение файла конфигурации cache_mgr root@сайт - e-mail администратора cache_store_log none - запрет создания файла регистрирующий удаление и перемещение объектов в кеш # cache_store_log /var/log/squid/store.log ssl_unclean_shutdown on - включение поддержки работы squid с браузерами некорректно поддерживающими ssl log_fqdn on - разрешение записи в файлы регистрации доменных имен вместо ip (снижает производительность) emulate_httpd_log on - разрешение создания файлов регистрации squid в формате apache cache_effective_user proxy cache_effective_group proxy # настройка редиректора для фильтрации внешней программой redirector_bypass on - если ни один из экзепляров squidGuard не отвечает то работать напрямую #redirector_bypass off - работать только через squidGuard ##url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf # разрешение использования squidGuard redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf - разрешение использования squidGuard redirect_children 5 - количество одновременно работающих пользователей с редиректором auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours auth_param basic casesensitive off refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 # блок определения имена списков acl all src 0.0.0.0/0.0.0.0 # определение метода элемента acl для метода PURGE (очистка кеша) #ident_lookup on #acl allowed_users myuser root #acl aclname ident myuser root #acl aclname proxy_auth myuser root acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl localnet src 192.168.0.0/255.255.255.0 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 563 acl Safe_ports port 80 21 443 563 70 210 1025-65535 280 488 591 777 # открытые порты, описание см. ниже acl CONNECT method CONNECT # определение метода элемента acl для метода CONNECT acl our_networks src 192.168.0.0/24 acl limited src 192.168.0.31/255.255.255.255 acl full src 192.168.0.1/255.255.255.255 acl god src 192.168.0.2/255.255.255.255 acl poor_urls url_regex -i "/etc/squid/poor/urls" #acl poor_path urlpath_regex -i "/etc/squid/poor/path" acl good_urls url_regex -i "/etc/squid/good/urls" acl good_path urlpath_regex -i "/etc/squid/good/path" acl squidGuard src 192.168.0.31/255.255.255.255 #redirector_access allow squidGuard # блок настройки правил доступа http_access allow manager localhost - разрешение доступа группе manager по протоколу с localhost # правило 2: настраиваем порты и метод подключения # правило 3: группа good # правило 4: группа full http_access deny !Safe_ports - запрет обращения к небезопасным портам http_access deny CONNECT !SSL_ports - запрет обращения к портам, неиспользуемым SSL, с помощью метода CONNECT #http_access deny CONNECT # запрет метода CONNECT http_access deny manager #http_access deny to_localhost # http_access allow localhost - разрешение доступа к squid с локальной машины # http_access allow localnet - разрешение доступа к squid из всей локальной сети http_access allow god all - группе god разрешено всё http_access allow full all !poor_urls - группе full разрешаем выход везде кроме плохих сайтов http_access allow limited good_urls !poor_urls - группе limited запрещаем выход везде кроме разрешенных сайтов http_access deny all - запрет доступа для всех хостов http_reply_access allow all icp_access allow all visible_hostname gw - имя шлюза для отчетов buffered_logs on - поддержка ускорения записи файлов регистрации refresh_pattern [-i] regex min percent max - установка правил выемки объекта из кеша в связи с его устареванием в кеше где regex регистрозависимая маска объекта в виде регулярного выражения [-i] указание игнорирования регистра для regex min минимальное время(в минутах) для объектов, которым оно не задано явно, в течение которого они(объекты) считаются "свежими". Рекомендуемое значение 0. Увеличение этого значения может стать причиной ошибок - выдачи объекта из кэша, в то время как клиенту он нужен актуальный в это конкретное время. percent процент от возраста объекта(время прошедшее с момента последнего изменения) в течении котрого объект считается "свежим". max максимальное время(в минутах) для объектов, которым оно не задано явно, в течение которого они(объекты) считаются "свежими". дополнительные параметры правила override-expire использовать установленное минимальное время "свежести" объектов, если сервер отправляет заголовок Expires, т.е. что объект устарел. Использование этой опции НАРУШАЕТ стандарт HTTP. Включая эту опцию, вы принимаете на себя ответственность за возможные проблемы. override-lastmod использовать установленное минимальное время "свежести" объектов, которые были изменены недавно. reload-into-ims изменяет клиентские запросы "no-cache" или "reload" на "If-Modified-Since". Использование этой опции НАРУШАЕТ стандарт HTTP. Включая эту опцию, вы принимаете на себя ответственность за возможные проблемы. ignore-reload игнорирование клиентских заголовков "no-cache" или "reload". Использование этой опции НАРУШАЕТ стандарт HTTP. Включая эту опцию, вы принимаете на себя ответственность за возможные проблемы. ignore-no-cache игнорировать заголовки "Pragma: no-cache" и "Cache-control: no-cache" принятые от сервера. HTTP RFC никогда не разрешало использовать Pragma заголовки серверами. Это разрешается только клиентам, но сервера все равно отсылают эти заголовки. ignore-private игнорировать заголовки "Cache-control: private" принятые от сервера. Использование этой опции НАРУШАЕТ стандарт HTTP. Включая эту опцию, вы принимаете на себя ответственность за возможные проблемы. ignore-auth кэшировать ответы на запросы авторизации, если внешний(оригинальный) сервер отправил заголовок "Cache-control: public" в ответе. Использование этой опции НАРУШАЕТ стандарт HTTP. Включая эту опцию, вы принимаете на себя ответственность за возможные проблемы. Правила refresh_pattern проходятся по порядку сверху вниз. Первое совпадение и будет использоватся. Если совпадений не найдено, то будут использоватся настройки по умолчанию.

Материалы о построении роутера на базе Squid - одни из самых популярных на нашем сайте. Такое решение позволяет с минимальными затратами (прежде всего на программную часть) организовать и упорядочить доступ к сети интернет на предприятии. Но рассматриваемые нами варианты предназначались преимущественно для работы в составе рабочей группы. Отсутствие интеграции с Active Directory резко снижало удобство применения такого роутера в доменных сетях, поэтому мы решили исправить это упущение.

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

Особенности интеграции с Active Directory

В чем смысл интеграции прокси-сервера Squid в Active Directory? Скажем сразу, что если ваша основная цель - просто раздать интернет всем и без ограничений, ну разве что закрыв социальные сети, то дальше можно не читать, уже описанная нами конфигурация полностью удовлетворит ваши потребности. Основное преимущество интеграции роутера в Active Directory - это использование единой точки аутентификации и управление доступом к сети интернет на базе уже существующих в домене учетных записей и групп безопасности.

Отсюда следуют некоторые особенности. Так прозрачный режим не поддерживает аутентификацию и от него придется отказаться, указывая настройки прокси непосредственно в настройках браузера. Этот процесс несложно автоматизировать при помощи DHCP-сервера и протокола WPAD.

В качестве DNS-серверов, в том числе и на роутере , должны обязательно указываться только доменные DNS, по умолчанию DNS-сервером является каждый контроллер домена. По этой причине роутер не должен иметь роли DNS-сервера. Также, для обеспечения интеграции с AD, роль DHCP-сервера также следует передать Windows Server, обычно на один или несколько контроллеров домена.

Теперь подходим к тому, ради чего все это затевалось. Аутентификация по доменным учетным записям позволяет использовать единую точку входа (SSO, Single Sign-On ), когда пользователь вводит логин и пароль один раз - при входе в систему. Это достигается применением протокола Kerberos , который является способом аутентификации в AD по умолчанию. В отличии от авторов иных руководств, мы не видим смысла настраивать или Basic-аутентификацию, в первую очередь по соображениям безопасности. Тем более Kerberos поддерживают все современные операционные системы.

Следующим шагом является авторизация на основе существующих групп безопасности, это особенно актуально при переходе с Forefront TMG или ISA Server . Это позволяет один раз настроив Linux-сервер дальнейшее управление доступом осуществлять привычным способом - через группы Active Directory, что позволяет снизить порог вхождения для администраторов.

Так как Active Directory имеет более сложную структуру и большее количество "действующих лиц", то чтобы вы не запутались в используемых нами адресах и именах хостов мы подготовили небольшую схему:

В наших примерах будет использоваться домен Active Directory с FQDN именем interface31.lab , за который отвечают два контроллера домена SRV-DC01 и SRV-DC02 с адресами 192.168.31.101 и 102 соответственно. Оба контроллера реализованы на базе Windows Server 2012 R2.

Роутер выполнен на базе Ubuntu Server 14.04 (Debian 7/8) и имеет имя SRV-GW01 с адресом 192.168.31.100. Также в сети имеется группа серверов со статическими адресами 192.168.31.103-105 и клиентские ПК, адреса которым выдаются DHCP сервером из диапазона 192.168.31.111-199.

Настройка сети

Сеть настраивается традиционным образом, посредством правки конфигурационного файла /etc/network/interfaces . Примем что внешней сети соответствует интерфейс eth0 , а внутренней eth1 . В результате настройки у нас должно получиться примерно следующее:

Auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.18.0.106
netmask 255.255.240.0
gateway 172.18.0.1
dns-search interface31.lab
dns-nameservers 192.168.31.101 192.168.31.102

auto eth1
iface eth1 inet static
address 192.168.31.100
netmask 255.255.255.0

post-up /etc/nat

Обратите внимание, что несмотря на то, что в настройках внешнего интерфейса использован внешний адрес и шлюз, адреса DNS-серверов указаны внутренние. Также указана опция dns-search , которая определяет домен для разрешения не FQDN-имен. Это означает, что к каждому короткому имени будет автоматически добавлен указанный домен, например, srv-dc01 будет дополнено до srv-dc01.interface31.lab .

Если вас смущает указание внутренних DNS в настройках внешней сетевой карты, то можете перенести эти строки в секцию eth1, на работу сервера это не повлияет.

DNS-сервера провайдера или публичные DNS следует указать в разделе Серверы пересылки внутреннего DNS-сервера на любом из контроллеров домена.

Если вы получаете сетевые настройки от провайдера по DHCP, то для использования внутренних серверов имен, вместо DNS провайдера секция eth0 должна иметь вид:

Auto eth0
iface eth0 inet dhcp
dns-search interface31.lab
dns-nameservers 192.168.31.101 192.168.31.102

Таким образом явно указанные настройки перекроют полученные автоматом от провайдера.

Сохраняем содержимое файла, перезагружаемся. Проверяем наличие интернета на сервере и разрешение имен. Например, выполните команду:

Nslookup srv-dc02

Ответить вам должен первый указанный доменный сервер имен, в нашем случае 192.168.33.101 и выдать полное FQDN-имя хоста и его IP-адрес.

После чего проверьте разрешение внешних имен:

Nslookup ya.ru

Вы также должны получить ответ от внутреннего сервера. На этом настройку сети можно считать законченной.

Настройка NAT и брандмауэра

Базовая настройка брандмауэра принципиально ничем не отличается от варианта роутера для рабочей группы, за одним исключением. Так как наш прокси является непрозрачным, то существует возможность выхода напрямую через NAT, если по какой-то причине браузер не будет настроен на работу с прокси-сервером. Поэтому ограничим доступ по HTTP (порт 80) для всех клиентов локальной сети, за исключением серверов и отдельных хостов, которым может потребоваться прямой доступ.

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

Создадим и откроем файл /etc/nat

touch /etc/nat

внесем в него следующее содержимое:

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

# Сбрасываем настройки брандмауэра
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

# Разрешаем доступ из локальной сети
iptables -A INPUT -i eth1 -j ACCEPT

# Разрешаем инициированные нами подключения извне
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешаем подключения по SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

#Запрещаем входящие извне
iptables -A INPUT -i eth0 -j DROP

# Разрешаем инициированные нами транзитные подключения извне
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

#Разрешаем HTTP серверам
iptables -A FORWARD -i eth1 -s 192.168.31.101 -p tcp --dport 80 -j ACCEPT
...
iptables -A FORWARD -i eth1 -s 192.168.31.105 -p tcp --dport 80 -j ACCEPT

#Запрещаем HTTP
iptables -A FORWARD -i eth1 -p tcp --dport 80 -j DROP

# Запрещаем транзитный трафик извне
iptables -A FORWARD -i eth0 -o eth1 -j DROP

# Включаем NAT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.31.0/24 -j MASQUERADE

Секция #Разрешаем HTTP серверам подразумевает набор идентичных правил для каждого хоста, которому мы разрешаем выход в интернет в обход прокси. В нашем случае это адреса от 192.168.31.101 до 192.168.31.105, чтобы не загромождать пример мы написали первый и последний, разделив их многоточием (которого в реальном конфиге быть не должно).

Сохраним файл и дадим ему права на исполнение:

Chmod +x /etc/nat

Перезагрузимся:

После чего можно проверить интернет на клиентах, на тех, которые входят в список исключений - он будет, на остальных нет. Другие протоколы: почта (SMTP, POP3, IMAP), FTP, HTTPS и т.п. должны работать на всех клиентах.

Настройка синхронизации времени

Для успешной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы часы роутера были синхронизированы с часами контроллера домена.

Установим NTP-клиент:

Apt-get install ntp

Затем откроем файл конфигурации /etc/ntp.conf и закомментируем все строки, начинающиеся на server . После чего добавим две свои записи:

Server srv-dc01.interface31.lab
server srv-dc02.interface31.lab

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

Затем добавим в конец файла две строки, ограничивающие работу NTP-клиента внутренним интерфейсом:

Interface ignore wildcard
interface listen eth1

Сохраняем файл и перезапускаем службу:

Service ntp restart

Чтобы убедиться, что NTP работает только на внутреннем интерфейсе, выполните:

Ss -l | grep 123

В выводе команды должны быть только внутренние адреса и адреса локальной петли (localhost):

Проверить синхронизацию можно командой:

В выводе обращаем внимание на колонки: when -время с последнего ответа сервера, pool - время опроса сервера, offset - разница времени в секундах.

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

Настройка кеширующего прокси-сервера Squid3

Внимание! Если вы перенастраиваете сервер для рабочей группы, то обязательно удалите пакет dnsmasq или иные DNS и DHCP сервера!

Важно! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid , также аналогичным образом следует изменить все пути, т.е. вместо /etc/squid3 использовать /etc/squid .

Установим прокси-сервер squid3 командой:

Apt-get install squid3

Откроем конфигурационный файл /etc/squid3/squid.conf и зададим минимальную конфигурацию, добавив или раскомментировав в соответствующих секциях указанные строки.

Укажем acl элемент для локальной сети:

Acl localnet src 192.168.31.0/24

Минимальный набор списков доступа:

Http_access allow localnet
http_access allow localhost
http_access deny all

Интерфейсы, порты и режимы работы прокси:

Http_port 192.168.31.100:3128
http_port 127.0.0.1:3128

Настройки кеша:

Cache_mem 1024 MB
maximum_object_size_in_memory 512 KB

cache_dir ufs / var /spool/squid3 2048 16 256

maximum_object_size 4 MB

Настройки лога:

Access_log daemon:/var/log/squid3/access.log squid
logfile_rotate 31

Для squid 3.1 и ниже первая строка должна выглядеть так:

Access_log /var/log/squid3/access.log squid

Сохраните и проверьте конфигурацию:

Squid3 -k check

Если нет ошибок, то перезапускаем squid:

Service squid3 restart

Перестраиваем кэш:

Service squid3 stop
squid3 -z
service squid3 start

На DNS-сервере домена добавьте A-запись для нашего роутера:

Теперь в настройках браузера укажите полное FQDN имя сервера и порт 3128:

Так как никаких ограничений пока не установлено, то вы должны получить доступ в интернет.

Squid — распространенное в среде программистов, системных администраторов и энтузиастов компьютерных сетей решение для создания эффективного прокси-сервера и управления им. Программа особенно привлекательна тем, что она кроссплатформенная. То есть устанавливать и запускать ее можно как в Linux и иных ОС, соответствующих архитектуре Unix, так и в Windows. Возможности данного инструмента — самые выдающиеся. Каким образом их можно задействовать? Есть ли особенности в настройке программы в зависимости от конкретной ОС?

Общие сведения о Squid

Что такое Squid? Под этим названием известен особо производительный прокси-сервер, используемый чаще всего с веб-клиентами. С его помощью можно организовывать одновременный доступ к Интернету для нескольких пользователей. Другое примечательное свойство Squid заключается в том, что он может кэшировать различные запросы. Это позволяет ускорять получение файлов, так как повторно скачивать их из Интернета не нужно. Прокси-сервер Squid также может регулировать скорость интернет-канала при соотнесении ее с фактической нагрузкой.

Squid адаптирован для использования на Unix-платформах. Однако есть версии Squid для Windows и многих других популярных ОС. Данная программа, так же как и многие операционные системы, основанные на концепции Unix, бесплатна. Она поддерживает FTP, SSL, позволяет настраивать гибкий контроль над доступом к файлам. Squid также записывает в кэш DNS-запросы. При этом можно настроить и прозрачный Squid-прокси, то есть работу сервера в формате, когда пользователь не знает, что обращается к Сети через него, а не напрямую. Таким образом, Squid — это мощный инструмент в руках системного администратора или поставщика коммуникационных услуг.

Практическая полезность Squid

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

Состав Squid

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

Установка программы

Установка Squid обычно никаких сложностей не вызывает. Очень легко ставится программа на Linux: достаточно ввести команду $ sudo apt-get install squid.

Что касается Squid для Windows, здесь все немного сложнее. Дело в том, что данная программа не имеет исполняемых файлов — основных элементов приложений для ОС от Microsoft.

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

В дистрибутиве прокси-сервера практически всегда содержится конфигурационный файл типа.conf. Он является главным инструментом настройки доступа к Интернету с компьютера пользователя и иных устройств, объединенных в локальную сеть при задействовании Squid.

Нюансы настройки

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

В случае с Linux можно задействовать для некоторых процедур. Но в целом в данной операционной системе, так же как и в том случае, если ОС, в которой ведется настройка Squid, — Windows, чаще всего задействуется файл squid.conf. В нем прописываются определенные выражения («команды»), в соответствии с которыми сервер выполняет управление подключениями к сети.

Рассмотрим, таким образом, как осуществляется настройка Squid, подробнее. Первым делом необходимо разрешить пользователям сети доступ к серверу. Для этого следует выставить в файле squid.conf соответствующие значения в http_port, а также в http_access. Также полезно будет создать список, предназначенный для контроля доступа, или ACL. Настройки http_port имеют для нас значение, так как наша задача — подготовить Squid только для обслуживания конкретной группы компьютеров. В свою очередь, такой параметр, как http_access, важен, так как с помощью него мы сможем регулировать доступ к конкретным ресурсам Сети, запрашиваемым с тех или иных адресов (возможны и иные критерии — протоколы, порты и иные свойства, содержащиеся в ACL).

Каким образом выставить необходимые настройки? Сделать это очень просто.

Допустим, мы создали компьютерную сеть с диапазоном адресов, начинающимся с 192.168.0.1 и заканчивающимся 192.168.0.254. В этом случае в ACL-настройках следует выставить следующий параметр: src 192.168.0.0/24. Если нам нужно настроить порт, то в файле конфигурации надо сделать запись http_port 192.168.0.1 (только следует указать правильный IP-адрес) и ввести номер порта.

Для того чтобы ограничить доступ к создаваемому с помощью Squid прокси (не считая компьютеров, входящих в локальную сеть), необходимо внести изменения в http_access. Это делается просто — с помощью выражений («команд» - условимся называть их так, хотя, строго говоря, в тексте они таковыми не являются, но в строке терминала вполне соответствовали бы им) allow LocalNet и deny all. Очень важно расположить первый параметр выше второго, так как Squid распознает их по очереди.

Работа с ACL: запрет доступа к сайтам

Собственно, настройки доступа возможны в Squid в очень широком спектре. Рассмотрим примеры полезных в практике управления локальными сетями.

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

Пишем ACL (название группы пользователей) src (интервал IP-адресов, попадающих под регулирование). Строчкой ниже — ACL (название конкретного компьютера) src (IP-адрес соответствующего ПК). После этого работаем уже с http_access. Устанавливаем разрешение на вход в сеть для группы пользователей и отдельного ПК посредством команд http_access allow. Строчкой ниже фиксируем, что доступ остальным компьютерам в сеть закрыт командой deny all.

Настройка прокси Squid также предполагает задействование другого полезного элемента, предусмотренного системой контроля доступа, — dst. Он позволяет зафиксировать IP-адрес сервера, к которому желает подключиться пользователь прокси.

С помощью рассматриваемого элемента мы можем, например, ограничить доступ к той или иной подсети. Для этого можно задействовать команду ACL (обозначение сети) dst (IP-адрес подсети), строчкой ниже — http_access deny (имя конкретного компьютера в сети).

Еще один полезный элемент — dstdomain. Он позволит нам зафиксировать домен, к которому желает подключиться пользователь. Задействуя рассматриваемый элемент, мы можем ограничить доступ того или иного пользователя, например, к внешним ресурсам Интернета. Для этого можно задействовать команду: ACL (группа сайтов) dstdomain (адреса сайтов), строчкой ниже — http_access deny (имя компьютера в сети).

Есть и иные примечательные элементы в структуре системы контроля доступа. В числе таковых — SitesRegex. С помощью данного выражения можно ограничить доступ пользователей на интернет-домены, содержащие определенное слово, например mail (если стоит задача запретить сотрудникам компании обращаться на сторонние почтовые серверы). Для этого можно задействовать команду ACL SitesRegexMail dstdom_regex mail, затем ACL SitesRegexComNet dstdom_regex \.com$ (это значит, что доступ будет закрыт для соответствующего типа доменов). Строчкой ниже — http_accesss deny с указанием компьютеров, с которых выход на внешние почтовые сервера нежелателен.

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

Например, с помощью команды ACL NoSwfFromMail url_regex -i mail.*\.swf$ мы регулируем возможность обращения к почтовым сайтам, в структуре которых присутствуют Flash-ролики. Если нет необходимости включать в алгоритмы доступа доменное имя сайта, то можно задействовать выражение urlpath_regex. Например, в виде команды ACL media urlpath_regex -i \.wma$ \.mp3$.

Запрет доступа к программам

Настройка Squid позволяет запрещать доступ пользователей к тем или иным программам при задействовании ресурсов прокси-сервера. Для этой цели может использоваться команда ACL (название программы) port (интервал портов), строчкой ниже — http_access deny all (имя программы).

Задействование стандартов и протоколов

Настройка Squid также позволяет системному администратору задать предпочтительный протокол использования интернет-канала. Например, если есть необходимость в том, чтобы человек с конкретного ПК выходил в сеть через протокол FTP, то можно задействовать следующую команду: ACL ftpproto proto ftp, строчкой ниже — http_access deny (имя компьютера) ftpproto.

С помощью элемента method мы можем указать то, каким способом должен осуществляться HTTP-запрос. Всего их 2 — GET и POST, но в ряде случаев предпочтителен именно первый, а не второй, и наоборот. Например, возможна ситуация, при которой конкретный сотрудник не должен просматривать почту через mail.ru, однако его работодатель не будет возражать, если человек захочет читать на указанном сайте новости. Для этого системный администратор может задействовать следующую команду: ACL sitemailru dstdomain .mail.ru, строчкой ниже — ACL methodpost method POST, далее — http_access deny (имя компьютера) methodpost sitemailru.

Таковы нюансы, которые включает в себя настройка Squid. Ubuntu используется, Windows или другая совместимая с прокси-сервером ОС, — рассмотренные нами особенности задания нужных параметров в целом характерны для любой программной среды функционирования Squid. Работа с данным ПО - невероятно увлекательный процесс и одновременно несложный в силу логичности и прозрачности основных алгоритмов настройки программы.

Отметим некоторые ключевые моменты, характерные для настройки Squid.

На что обратить внимание при настройке?

Если есть сложности в обнаружении файла squid.conf, который является основным инструментом конфигурирования сервера, то можно попробовать проверить каталог etc/squid.

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

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

В ряде случаев полезно фиксировать величину оперативной памяти, которую будет задействовать Squid. Это можно сделать посредством команды cache_mem. Также полезно указать каталог, в котором будут храниться кэшированные данные, делается это с помощью выражения cache_dir. В первом случае полностью команда будет выглядеть как cache_mem (объем ОЗУ в байтах), во втором - как cache_dir (адрес каталога, количество мегабайтов дискового пространства). Желательно размещать кэш на самых высокопроизводительных дисках, если есть выбор.

Может понадобиться указание компьютеров, которые имеют доступ к прокси-серверу. Это можно сделать с помощью команд ACL allowed hosts src (интервал IP-адресов компьютеров), а также ACL localhost src (локальный адрес).

Если в подключениях задействуются порты типа SSL, то их также можно зафиксировать с помощью команды ACL ssl_ports port (указание порта). Одновременно можно запретить использование метода CONNECT для остальных портов, кроме тех, что указаны в защищенном соединении SSL. Это сделать поможет выражение http_access deny CONNECT! SSL_Ports.

Squid и pfSense

В ряде случаев вместе с рассматриваемым прокси-сервером используется интерфейс pfSense, применяемый в качестве эффективного Каким образом организовать их совместную работу? Алгоритм решения данной задачи не слишком сложный.

Для начала нам нужно поработать в интерфейсе pfSense. Squid, настройка которого уже осуществлена нами, необходимо будет инсталлировать посредством SSH-команд. Это один из самых удобных и безопасных способов работы с прокси-серверами. Для этого необходимо активизировать в интерфейсе пункт Enable Для того чтобы найти его, необходимо выбрать пункт меню System, затем — Advanced, после — Admin Access.

После этого нужно скачать PuTTY - удобное приложение для работы с SSH. Далее, используя консоль, необходимо инсталлировать Squid. Это легко сделать с помощью команды -pkg install squid. После этого необходимо также установить прокси через веб-интерфейс pfSense. Squid (настройка его параметров на данном этапе не производится) можно инсталлировать, выбрав пункт меню System, затем Packages, после — Available Packages. В соответствующем окне должен быть доступен пакет Squid Stable. Выбираем его. Необходимо выставить следующие настройки: Proxy Interface: LAN. Напротив строки Transparent Proxy можно поставить галочку. Выбираем адрес для лога и отмечаем русский язык как предпочтительный. Нажимаем Save.

Инструмент оптимизации ресурсов

Настройка Squid позволяет системным администраторам эффективно распределять ресурсы серверов. То есть в данном случае речь не идет о запретах доступа на какой-либо сайт, однако интенсивность задействования канала тем или иным пользователем или их группой может требовать контроля. Рассматриваемая программа позволяет решить данную задачу несколькими способами. Во-первых, это задействование механизмов кэширования: за счет этого повторная загрузка файлов из Интернета не потребуется, так как снизится нагрузка на трафик. Во-вторых, это ограничение доступа к сети по времени. В-третьих, это установление предельных значений для скорости обмена данными в сети в отношении действий тех или иных пользователей или конкретных типов загружаемых файлов. Рассмотрим указанные механизмы подробнее.

Оптимизация сетевых ресурсов посредством кэширования

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

Достаточно полезная опция исследуемого нами прокси-сервера — проверка возраста файла, находящегося в кэше. Объекты, слишком долго располагающиеся в соответствующей области памяти, следует обновлять. Задействование этой опции возможно при использовании команды refresh_pattern. Так, полностью выражение может выглядеть как refresh_pattern (минимальная длительность времени — в минутах, максимальная доля «свежих» файлов — в %, максимальный период). Соответственно, если файл находится в кэше дольше установленных критериев, то, возможно, потребуется загрузка его новой версии.

Оптимизация ресурсов посредством ограничений доступа по времени

Другой вариант, который можно задействовать благодаря возможностям Squid-Proxy, — это ограничение доступа пользователей к сетевым ресурсам по времени. Устанавливается оно с помощью очень простой команды: ACL (имя компьютера) time (день, час, минута). Доступ можно ограничивать для любого дня недели, подставив вместо «день» первую букву слова, соответствующую его названию в английском алфавите. Например, если это понедельник — то M, если вторник, то T. Если в команде нет слова «день», то соответствующий запрет будет установлен на всю неделю. Интересно, что можно также регулировать расписание вхождения в сеть, осуществляемого пользователями с помощью тех или иных программ.

Оптимизация ресурсов посредством ограничения скорости

Достаточно распространенный вариант — оптимизация ресурсов с помощью регулирования допустимой скорости обмена данными в рамках компьютерной сети. Изучаемый нами прокси-сервер — удобнейший инструмент для решения данной задачи. Регулирование скорости обмена данными в сети осуществляется с помощью таких параметров, как delay_class, delay_parameters, delay_access, а также посредством элемента delay_pools. Все четыре компонента имеют огромное значение для решения задач, которые стоят перед системными администраторами в аспекте оптимизации ресурсов локальной сети.