Введение
Существует проверенная временем связка для прокси сервера – 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: domainuser@DOMAIN.LOCAL
Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 22.05.2018 10:08:30
Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:
kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL
* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.
И снова:
klist
Картина, примерно, следующая:
Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL
Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
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-адресом вашего сервера.
Исходящий сетевой интерфейс
На нашем сервере может быть несколько внешний 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.
Настройка авторизации по логину и паролю
Важно настроить доступ к прокси-серверу только по логину и паролю. Важно это из-за того, что при свободном доступе злоумышленники могут использовать Ваш прокси-сервер для незаконных действий, тем самым подменяя свой реальный 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. Придется пока с ним дружить и находить общий язык. Надеюсь, что кто-нибудь возьмется за его развитие и поддержку.
