Как установить и настроить прокси-сервер squid на centos 7

Введение

Существует проверенная временем связка для прокси сервера – squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

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

Приступим к настройке. В своей работе я буду подразумевать, что вы установили и настроили centos по моим рекомендациям. Советую ознакомиться с материалом. Это позволит здесь не тратить время на второстепенные настройки, которые не имеют прямого отношения к теме статьи.

Исходящий сетевой интерфейс

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

vi /etc/squid/squid.conf

acl 217_66_157_33 localip 217.66.157.33
tcp_outgoing_address 217.66.157.33 217_66_157_33
acl 217_66_157_34 localip 217.66.157.34
tcp_outgoing_address 217.66.157.34 217_66_157_34

* в данном примере, при подключении к прокси через IP 217.66.157.33, исходящие пакеты будут от IP 217.66.157.33; аналогично для IP 217.66.157.34.

Предварительная настройка сервера

Любую настройку сервера я рекомендую начинать с обновления:

# yum -y update

После этого я устанавливаю mc, так как привык к нему и постоянно пользуюсь:

# yum -y install mc

Дальше отключаем selinux. Находим файл /etc/sysconfig/selinux и редактируем его:

# mcedit /etc/sysconfig/selinux

Приводим строку с соответствующим параметром к следующему виду:

SELINUX=disabled

Чтобы применить изменения, перезагружаем сервер:

# reboot

Более подробно о базовой настройке сервера CentOS 7 читайте отдельно. Мы же двигаемся дальше.

Теперь настроим сеть. Я очень подробно рассмотрел вопрос настройки сети в CentOS 7 в своем отдельном материале. Рекомендую с ним ознакомиться. Здесь же я кратко выполню необходимые команды, без пояснений.

Сначала удаляем NetworkManager. Он нам не понадобится, выполним все настройки вручную. Иногда он может вызывать непонятные ошибки, я предпочитаю им не пользоваться:

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service

Теперь включаем классическую службу сети в CentOS 7:

# systemctl enable network.service

Настраиваем сетевые интерфейсы:

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

HWADDR=00:15:5D:01:0F:06
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
NAME="eth0"
UUID="4e65030c-da90-4fb8-bde4-028424fe3710"
ONBOOT="yes"

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
HWADDR=00:15:5d:01:0f:12
TYPE=Ethernet
ONBOOT=yes
IPADDR=192.168.10.1
NETMASK=255.255.255.0

Перезапускаем службу сети:

# systemctl restart network.service

Смотрим, что получилось:

# ip a

Вы настраивайте сеть в зависимости от своих условий. Если внешний адаптер получает настройки не по dhcp, как у меня, а в статике, то не забудьте настроить шлюз по-умолчанию и dns сервер. Как это сделать написано в моей статье о сетевых параметрах, ссылку на которую я приводил выше.

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

Авторизация по логину и паролю

Открываем конфигурационный файл:

auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/auth_users auth_param basic children 25 auth_param basic realm SQUID PROXY auth_param basic credentialsttl 3 hours acl auth_users proxy_auth REQUIRED

* где /usr/lib64/squid/basic_ncsa_auth — расположение ncsa_auth (в зависимости от системы может находиться в другом каталоге); /etc/squid/auth_users — файл с логинами и паролями; children 25 разрешает 25 одновременных подключений; SQUID PROXY — произвольная фраза для приветствия; credentialsttl 3 hours будет держать сессию 3 часа, после потребуется повторный ввод логина и пароля.

http_access deny !Safe_ports

http_access allow auth_users

Создаем файл с пользователями и создаем первую пару логина и пароля:

htpasswd -c /etc/squid/auth_users user1

* если система вернет ошибку «bash: htpasswd: command not found» установим htpasswd командой yum install httpd-tools

Создаем второго пользователя:

htpasswd /etc/squid/auth_users user2

Установка и настройка dnsmasq в CentOS 7

С большой долей вероятности dnsmasq у вас уже установлен. Проверить это можно следующей командой:

# rpm -qa | grep dnsmasq
dnsmasq-2.66-14.el7_1.x86_64

Если вывод такой же, значит пакет уже стоит. Если нет, то устанавливаем dnsmasq командой:

# yum -y install dnsmasq

Редактируем файл конфигурации /etc/dnsmasq.conf и приводим его к очень простому виду:

# mcedit /etc/dnsmasq.conf

domain-needed
bogus-priv
interface=eth1
dhcp-range=192.168.10.50,192.168.10.150,24h

Запускаем dnsmasq:

# systemctl start dnsmasq

Либо перезапускаем, если он был у вас запущен:

# systemctl restart dnsmasq

Добавляем dnsmasq в автозагрузку:

# systemctl enable dnsmasq

Я редактировал конфиг, когда у меня уже был установлен и запущен dnsmasq. И он то ли завис, то ли просто затупил, но я не мог его перезагрузить или остановить с помощью systemctl. Пришлось перезагрузить сервер. После этого все нормально заработало. Клиент на windows получил сетевые настройки. Информация об этом появилась в логе /var/log/messages. Я проверил на клиенте интернет, все было в порядке, он работал.

На этом настройка завершена, шлюзом под CentOS 7 можно пользоваться.

Настройка CentOS

Kerberos

Устанавливаем следующие пакеты:

yum install cyrus-sasl-gssapi krb5-workstation krb5-devel

Открываем конфигурационный файл Kerberos:

vi /etc/krb5.conf

Редактируем следующие строки:

…
default_realm = DOMAIN.LOCAL
..

DOMAIN.LOCAL = {
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
}

* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).

Проверяем настройки krb, запросив тикет:

kinit domainuser

klist

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

Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]

Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/[email protected]
renew until 22.05.2018 10:08:30

Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:

kinit -V -k -t /etc/squid/proxy.keytab HTTP/[email protected]

* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/[email protected] — принципал, который был задан при создании файла.

И снова:

klist

Картина, примерно, следующая:

Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/[email protected]

Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/[email protected]
renew until 23.05.2018 09:35:20

Зададим файлу следующие права:

chown squid:squid /etc/squid/proxy.keytab

chmod u+rwx,g+rx /etc/squid/proxy.keytab

NTLM

Устанавливаем следующие пакеты:

yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation

Конфигурируем

authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update

* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.
* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.

Добавляем сервер в домен:

net ads join -U administrator

* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.

Разрешаем автозапуск winbind и запускаем его:

systemctl enable winbind

systemctl start winbind

Проверяем, что наш сервер умеет обращаться к службе каталогов:

wbinfo -t

wbinfo -g

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.

Настройка вашего браузера для использования прокси

Теперь, когда у вас настроен Squid, последний шаг — настроить предпочитаемый вами браузер для его использования.

Fire Fox

Приведенные ниже шаги одинаковы для Windows, macOS и Linux.

В верхнем правом углу щелкните значок гамбургера чтобы открыть меню Firefox:
Щелкните ссылку .
Прокрутите вниз до раздела « » и нажмите кнопку « .
Откроется новое окно.
- Установите переключатель « ».
- Введите IP-адрес вашего сервера Squid в поле и в поле .
- Установите флажок .
- Нажмите кнопку , чтобы сохранить настройки.

На этом этапе ваш Firefox настроен, и вы можете просматривать Интернет через прокси-сервер Squid. Чтобы проверить это, откройте , введите «what is my ip», и вы должны увидеть IP-адрес своего сервера Squid.

Чтобы вернуться к настройкам по умолчанию, перейдите в « , выберите переключатель « » и сохраните настройки.

Гугл Хром

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

Linux:

macOS:

Windows:

Если профиль не существует, он будет создан автоматически. Таким образом, вы можете запускать несколько экземпляров Chrome одновременно.

Чтобы убедиться, что прокси-сервер работает правильно, откройте и введите «какой у меня IP». IP-адрес, отображаемый в вашем браузере, должен быть IP-адресом вашего сервера.

Исходящий сетевой интерфейс

vi /etc/squid/squid.conf

acl 217_66_157_33 localip 217.66.157.33
tcp_outgoing_address 217.66.157.33 217_66_157_33
acl 217_66_157_34 localip 217.66.157.34
tcp_outgoing_address 217.66.157.34 217_66_157_34

Настройка авторизации по логину и паролю

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

Для настройки доступа нужно сначала установить пакет, позволяющий создавать файлы с паролями:

Теперь создадим файл с паролем:

Теперь нужно поместить в файл связку логина и пароля (в данном случае squiduser будет логином):

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

По умолчанию htpasswd использует шифрование паролей методом MD5, поэтому нам нужно разрешить такое шифрование в файле конфигурации Squid.

Откроем файл конфигурации:

Далее добавим следующие строки в файл конфигурации:

Далее сохраните изменения в файле и вновь перезапустите Squid:

Включаем маршрутизацию, firewall и nat

Чтобы сервер мог маршрутизировать пакеты между сетевыми адаптерами, необходимо выполнить следующую настройку. Находим файл /etc/sysctl.conf и вставляем туда строку:

# mcedit /etc/sysctl.conf
net.ipv4.ip_forward = 1

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

# sysctl -p

Теперь приступаем к самому главному — настройке фаерволла. Опять же отсылаю вас к своему материалу, где я очень подробно рассмотрел вопрос настройки iptables в CentOS 7. Там же приведен готовый скрипт для iptables. Так что выполняем все необходимые действия без пояснений.

Отключаем firewalld:

# systemctl stop firewalld
# systemctl disable firewalld

Устанавливаем службы iptables:

# yum -y install iptables-services

Скачиваем скрипт с правилами iptables.sh. Данные правила включают NAT, закрывают доступ к серверу снаружи, разрешают пинги, разрешают всем пользователям локальной сети доступ в интернет. Дополнительный функционал отключен. В скрипте подробно описаны все правила. Вам необходимо только заменить в начале переменные на свои. В моем случае это будет выглядеть так:

# Внешний интерфейс
export WAN=eth0
export WAN_IP=192.168.1.25
# Локальная сеть
export LAN1=eth1
export LAN1_IP_RANGE=192.168.10.1/24

Помещаем отредактированный скрипт в /etc/iptables.sh и делаем его исполняемым:

# chmod 0740 /etc/iptables.sh

Запускаем iptables:

# systemctl start iptables.service

Добавляем их в автозагрузку:

# systemctl enable iptables.service

Выполняем скрипт с правилами:

# /etc/iptables.sh

Проверяем установленные правила:

# iptables -L -v -n

Если у вас то же самое, значит вы все сделали правильно.

По сути наш шлюз уже готов и может обслуживать клиентов. Но не работает одна важна служба, без которой нормальной работы с интернетом не получится. Нам нужно настроить кэширущий dns сервер для клиентов локальной сети. Можно пойти по простому и очень простому пути. Простой путь это выполнить простейшую настройку dns сервера bind. Как это сделать у меня опять же подробно написано отдельно — настройка Bind 9 в CentOS 7. Рекомендую ознакомиться, там рассмотрены интересные нюансы настройки.

Очень простой путь это установить dnsmasq, который помимо dns сервера включает в себя еще и dhcp сервер, который нам может пригодиться.

Настройка SQUID с ntlm авторизацией через домен

Дальше будет попроще. Если на предыдущем этапе вы все сделали правильно, то squid заработает без проблем. Устанавливаем его:

# yum -y install squid

Открываем файл конфигурации /etc/squid/squid.conf и добавляем в самое начала следующие параметры:

auth_param ntlm program /usr/bin/ntlm_auth --diagnostics --helper-protocol=squid-2.5-ntlmssp --domain=XS
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

Не забудьте указать свой домен

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

Без них у меня ntlm авторизация не хотела работать, я очень долго ее мучал.

Дальше находим в конфиге строку:

http_access allow localnet

Комментируем ее, она позволяет получить доступ всем компьютерам из локальной сети. После этой строки добавляем новую:

http_access allow auth

Разрешаем доступ только тем, кто прошел авторизацию. Запускаем squid и добавляем в автозагрузку:

# systemctl start squid
# systemctl enable squid

Все, можно идти проверять. Открываем браузер у какого-нибудь компьютера и указываем в качестве прокси ip адрес сервера, порт 3128. Пробуйте выйти в интернет.

Как понять, что все работает правильно:

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

# cat /var/log/squid/access.log | grep control

1449261311.346 9 10.1.4.189 TCP_MISS/304 438 GET http://yastatic.net/islands/_/S1-qWWyv85yFAtoHVvuxJXpOKA4.svg control HIER_DIRECT/178.154.131.217 -
 1449261311.351 11 10.1.4.189 TCP_MISS/200 622 GET http://yastatic.net/www/_/_/y/ljN5poHcx67T3HSZuHbvf2NNk.png control HIER_DIRECT/178.154.131.217 image/png
 1449261311.404 9 10.1.4.189 TCP_MISS/304 440 GET http://yastatic.net/morda-logo/i/disaster/metro11072015.png control HIER_DIRECT/178.154.131.217 -
 1449261311.488 97 10.1.4.189 TCP_MISS/302 355 GET http://kiks.yandex.ru/fu control HIER_DIRECT/213.180.204.143 -
 1449261311.507 9 10.1.4.189 TCP_MISS/304 341 GET http://kiks.yandex.ru/system/fc07.swf control HIER_DIRECT/213.180.204.143 -

В данном случае control — доменная учетная запись.

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

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

Установка phpMyAdmin

Для установки phpMyAdmin вводим следующую команду:

yum install phpmyadmin

Теперь создадим для него отдельный виртуальный домен в NGINX:

vi /etc/nginx/conf.d/phpMyAdmin.conf

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

server {
listen 80;
server_name phpmyadmin.dmosk.local;
set $root_path /usr/share/phpMyAdmin;
location / {
root $root_path;
index index.php;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
fastcgi_read_timeout 300;
}
}

* где phpmyadmin.dmosk.local — адрес для виртуального домена, именно этот адрес должен быть введен в адресную строку браузера, чтобы открылся нужный сайт. Поэтому есть нет возможность зарегистрировать домен и имя узла в DNS, можно воспользоваться локальным файлом hosts. /usr/share/phpMyAdmin — это каталог, в который по умолчанию устанавливается phpMyAdmin.

После перезапускаем NGINX:

systemctl reload nginx

Также нужно перезапустить php-fpm, так как в процессе установки был добавлен модуль mbstring:

systemctl restart php-fpm

И открываем в браузере наш домен, в данном примере, http://phpmyadmin.dmosk.local. Откроется форма для авторизации — вводим логин root и пароль, который мы указали после установки и запуска mariadb.

Apache (httpd)

Несмотря на то, что мы установили и настроили PHP-FPM, Apache нам понадобится, как минимум, по двум причинам. Во-первых, многие сайты используют файл .htaccess, который читает только Apache. Во-вторых, последний включает большое число модулей, которые может использовать портал.

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

И так, устанавливаем httpd:

yum install httpd

Заходим в настройки:

vi /etc/httpd/conf/httpd.conf

И редактируем следующее:

Listen 8080

* наш веб-сервер будет слушать на порту 8080, так как на 80 уже работает NGINX.

<IfModule dir_module>
DirectoryIndex index.php index.html
</IfModule>

* если не указан конкретный скрипт, сначала веб-сервер пытается найти и запустить index.php, затем index.html

Добавляем:

<Directory /var/www/*/www>
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
</Directory>

* где Directory — разрешенные каталоги для запуска из apache; Options — разрешенные опции; Require — с каких IP-адресов можно открывать сайты, определенные в данном каталоге. Итого, мы разрешаем все каталоги в /var/www, но только если следующий каталог будет www; разрешаем опции Indexes (возвращает список файлов, если нет индексного файла, например, index.php), ExecCGI (разрешены сценарии CGI), FollowSymLinks (включены символические ссылки в этом каталоге); доступ для данных каталого разрешен со всех адресов (all granted).

Проверяем синтаксис конфигурационного файла httpd:

apachectl configtest

Разрешаем автозапуск и запускаем службу:

systemctl enable httpd

systemctl start httpd

Создаем php-файл со следующим содержимым:

vi /var/www/html/index.php

<?php phpinfo(); ?>

Открываем браузер и вводим в адресную строку IP-адрес нашего сервера и добавляем :8080. Мы должны увидеть привычную страницу:

NGINX + Apache

Ранее нами была настроена связка nginx + php-fpm. Теперь проверяем совместную работу первого с apache.

Открываем конфигурационный файл nginx:

vi /etc/nginx/conf.d/default.conf

* если при настройке nginx мы редактировали файл /etc/nginx/nginx.conf, то необходимо открыть его.

Находим наш настроенный location для php-fpm:

…
location ~ \.php$ {
fastcgi_pass unix:/run/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
…

и меняем на:

…
location ~ \.php$ {
       proxy_pass http://127.0.0.1:8080;
       proxy_redirect off;
       proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
…

Проверяем и перезапускаем nginx:

nginx -t

systemctl restart nginx

Пробуем открыть в браузере IP-адрес нашего сервера — должна открыться та же страница, что при проверке Apache (с добавлением 8080):

Apache Real IP

Так как все запросы на httpd приходят от NGINX, они воспринимаются как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей.

Для решения проблемы будем использовать модуль mod_rpaf. Устанавливаем набор разработчика для apache:

yum install httpd-devel gcc unzip

Переходим в каталог /usr/local/src:

cd /usr/local/src

Скачиваем модуль:

wget https://github.com/gnif/mod_rpaf/archive/stable.zip

Распаковываем его:

unzip stable.zip

Переходим в распакованный каталог:

cd mod_rpaf-stable/

Собираем модуль и устанавливаем его:

make

make install

* при возникновении ошибки ./apxs.sh: line 15: -c: command not found, необходимо поставить which командой yum install which.

Создаем конфигурационный файл со следующим содержимым:

vi /etc/httpd/conf.d/mod_rpaf.conf

LoadModule              rpaf_module modules/mod_rpaf.so
RPAF_Enable             On
RPAF_ProxyIPs           127.0.0.1
RPAF_SetHostName        On
RPAF_SetHTTPS           On
RPAF_SetPort            On
RPAF_ForbidIfNotProxy   Off

Перезапускаем httpd:

systemctl restart httpd

Для проверки настройки открываем на редактирование созданный index-файл для httpd:

vi /var/www/html/index.php

И редактируем содержимое на:

<?php echo $_SERVER ?>

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

SOCKS

Для прозрачного прохождения пакетов через прокси можно настроить SOCKS5. В конфигурационном файле добавляем:

vi /etc/3proxy.cfg

socks -p8083

* запускаем socks на порту 8083.

Или:

socks -p8083 -i192.168.1.23 -e111.111.111.111

* запускаем socks на порту 8083; внутренний интерфейс — 192.168.1.23, внешний — 111.111.111.111.

Пример настройки:

auth none
# We want to protect internal interface
deny * * 127.0.0.1,192.168.1.1
# and llow HTTP and HTTPS traffic.
allow * * * 80-88,8080-8088 HTTP
allow * * * 443,8443 HTTPS
proxy -n
socks

* в данном примере мы настроили 3proxy, который не будет требовать аутентификации, и будет работать в режиме прокси на порту 3128 (порт прокси по умолчанию) и по SOCKS на порту 1080 (порт socks по умолчанию).

Веб-сервер

Как говорилось ранее, для просмотра отчетов в графическом интерфейсе нам нужен веб-сервер. Для его развертывания, сначала ставим репозиторий EPEL:

yum install epel-release

После ставим nginx:

yum install nginx

Разрешаем автозапуск nginx и стартуем сервис:

systemctl enable nginx

systemctl start nginx

Открываем 80 порт в брандмауэре:

firewall-cmd —permanent —add-port=80/tcp

При необходимости просмотра статистики по https также добавим правило:

firewall-cmd —permanent —add-port=443/tcp

Применяем правила:

firewall-cmd —reload

Открываем браузер и переходим по адресу http://<IP-адрес сервера>/squid-reports/ — должна открыться стартовая страница со списком дат:

Чтобы просмотреть список посещенных сайтов и израсходованного трафика, переходим к нужной нам дате и выберем пользователя, для которого нужно получить статистику. Идентификация пользователей в sarg зависит от идентификации в squid — если проверка не выполняется, то в качестве идентификаторов будут фигурировать IP-адреса.

Заключение

Пришло время подвести итог того, что мы сделали. Проведена большая работа по настройке прокси сервера на базе CentOS 7. Были выполнены следующие шаги:

Сервер был введен в домен Windows для настройки авторизации доменных пользователей на прокси сервере.
Настроен прокси сервер squid для работы с доменными учетными записями.
Собран из исходников многофункциональный web интерфейс для управления squid – sams2 самой последней на текущий момент версии.

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

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

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом “Administrator Linux. Professional” в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

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

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Заключение

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

Dec 27 01:20:08 freebsd samsdaemon: ***ERROR: squidlogparser.cpp:445 Unknown cache result
Dec 27 01:20:08 freebsd samsdaemon: +++WARNING: Unknown cache result TCP_TUNNEL

Хотя на работу это вроде как не влияет. В инет пускает, статистику считает. Я еще не настраивал редиректор и списки запрета доступа, но по отзывам, там тоже есть проблемы и работает все нестабильно. Начиная с версии 3.4 поменялся формат ответа редиректора и он стал несовместим с самсовским. Нужно править исходники и собирать с исправлениями. На CentOS я обошелся просто более старой версией squid, чтобы не разбираться с этой проблемой. Думаю, можно вообще без запретов обойтись, это сейчас не актуально из-за большого развития мобильных гаджетов и хорошего доступа в интернет с них

Но если вам это важно, имейте в виду

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