Настройка шлюза и прокси сервера на базе clearos

Open Source в Татарстане. Linux

Третий пост про Debian. Наверное, самый важный и объемный. Здесь постараюсь повторить последовательность действий по обустройству интернет-шлюза под управлением Debian 5.0.2 Lenny для нужд небольшой офисной сети. Уже можно прочитать:

1. Зачем оно нам нужно?

2. Как установить?
В третьей части пропустим лирику и перейдем к делу =)

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

После установки заходим в систему под root. Сразу же установим sudo и pppoeconf:

Установка будет произведена с того же диска, с которого инсталлировали саму систему. Соответственно CD нужно снова вставить в дисковод.

Теперь можно выйти из режима суперпользователя и всю дальнейшую настройку производить, войдя в систему под своей учетной записью, созданной при установке, используя sudo для административных команд:

Примечание 2. Выход из учетной записи root не является обязательным, но очень рекомендуется. Тем не менее, все последующие действия нужно производить с полномочиями суперпользователя, используя sudo или su. Дабы обратить на это внимание ставлю символ # в начал почти каждой команды.

Диск с системой теперь уже можно извлечь, больше он не потребуется.

Установим PPPoE подключение к Интернет, используя pppoeconf:

pppoeconf спросит имя пользователя и пароль, выданные провайдером, а также уточнит некоторые дополнительные параметры, в частности – необходимость устанавливать соединение автоматически при включении компьютера. Я как-то уже писал про настройку PPPoE в Ubuntu, никакой разницы тут нет.

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

Здесь необходимо закомментировать (поставить # в начале строки) строку, указывающую на CD-диск с Debian'ом и добавить еще хотя бы один (там уже прописаны несколько) источник в конец списка:

Примечание 3. Для редактирования конфигурационных файлов мне удобнее использовать редактор nano, поэтому везде указываю именно его. Для выхода из nano нужно нажать ctrl-x, а затем y, чтобы сохранить изменения, или n, чтобы отменить их. Можно использовать ctrl-w для поиска нужной фразы.

Обновляем списки репозиториев:

Если все прошло успешно, можно обновить и саму систему:

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

Примечание 4. В данном и подобных случаях будем иметь 4 сетевых интерфейса:
lo – loopback-интерфейс;
eth0 – смотрит в сторону ADSL-модема и настраивается по DHCP, имеет динамический адрес вида 192.168.0.

x
eth1 – смотрит в сторону локальной сети, настраивается вручную, имеет статичный адрес вида 192.168.1.

x
ppp0 – PPPoE-интерфейс, настраивается при помощи pppoeconf, имеет динамический адрес, выделяемый провайдером
Здесь и далее все настройки для данной конфигурации сети.

Сейчас нас интересует интерфейс eth1. настроим его, добавив в файл /etc/network/interfaces строки:

Сохраняем изменения и перезапускаем сеть:

Если все сделано правильно, то можно проверить доступность будущего шлюза из локальной сети, выполнив на любом другом компьютере:

Примечание 5. При настройке подключения с помощью pppoeconf указали, что требуется автоподключение при загрузке системы, однако где-то на просторах Интернета мне попалась следующая рекомендация:
– создать файл с любым названием (например, autopppoe) в директории /etc/network/if-up.d/:

– вписать в него следующее

-установить права на доступ:

Это, вроде как должно гарантировать автоматическое подключение PPPoE при загрузке компьютера.

На этом с настройкой сети пока закончим и перейдем к установке нужных пакетов.
Для начала поставим ssh и ddclent, чтобы получить доступ к серверу извне:

ddlient – клиентский модуль для использования DynDNS. Упоминал его тут. При установке потребуется указать свой логин и пароль в службе динамического DNS, а также имя зарегистрированного там хоста. Немного поправим его конфигурационный файл, “включив” его демон:

Найдем строку

и заменим ее на

Остается только перезапустить клиент:

Теперь можно подключиться к компьютеру при помощи ssh из любого места, где есть доступ в Интернет.

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

и копировать в нее исходные конфигурационные файлы, например так:

Просто совет =)

Установим DHCP-сервер, который также позволит переадресовывать DNS-запросы с компьютеров локальной сети:

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

Конфигурационный файл dnsmasq очень прост, поэтому пример конфигурации не привожу. Сохраняем изменения и перезапускаем DHCP-сервер:

Установим прокси-сервер squid:

Так как будем “строить” именно шлюз, а не просто прокси-сервер, то добавим squid'у прозрачности. Для этого отредактируем его конфигурационный файл:

Находим строку

и добавим к ней опцию transparent, которая и означает прозрачный прокси:

Далее можно (и даже нужно) внести еще несколько изменений в конфигурацию squid'а, но делать лучше, используя более подробные руководства или хотя просто внимательно читая комментарии в конфигурационном файле. Укажу лишь некоторые наиболее важные параметры (цифры случайны):

Управление авторизацей пользователей и слежение за трафиком доверим SAMS'у – Squid Account Management System. О его установке чуть ниже. А пока отредактируем то, что считаем нужным, не обращая внимания на параметры доступа пользователей, сохраним изменения в конфиге и перезапустим squid:

Примечание 7. Можно применять новую конфигурацию squid без его перезапуска:

Теперь перейдем к настройке фаервола iptables. Создадим файл, содержащий в себе правила iptables:

В него впишем:

Установим права доступа:

Создадим еще один файл, описывающий процесс сброса правил:

В нем пропишем:

Установим права:

Теперь добавим в файл /etc/network/interfaces сразу после описания интерфейса ppp0 строки:

Таким образом, правила iptables будут вступать в силу сразу после “поднятия” интерфейса ppp0 и сбрасываться после его “падения”. Теперь можно перезагрузиться

или перезапустить сеть:

Если все было сделано правильно, то настройки фаервола должны вступить в силу после того, как будет установлено PPPoE-соединение с Интернет. При этом весь http-трафик, идущий через порты 80 и 8080 должен проходить через кэширующий прокси squid, а все остальное – идти “напрямую”.

В зависимости от конфигурации доступа пользователей в squid.conf на компьютерах локальной сети можно уже проверять возможность выхода в Интернет. Для этого в качестве шлюза по умолчанию и одного из DNS-серверов должен быть указан ip-адрес компьютера с Debian.

Прокси-сервер указывать не надо.

Примечание 8. Вообще, моя дружба с iptables никак не сложится, поэтому данную конфигурацию фаервола ни в коем случае не следует считать наиболее оптимальной. Однако, могу уверенно сказать, что она работает и в данный момент меня устраивает. Внизу постараюсь привести ссылку на более “продвинутый” конфиг.

Примечание 9. В самом простейшем случае для настройки шлюза достаточно установить всего два пакета:

После чего надо немного поправить конфиг dnsmasq, как было сказано выше. После перезапуска шлюз должен начать раздавать интернет в локальную сеть. Проверено под Ubuntu Server 8.10.

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

При установке mysql-server потребуется указать пароль пользователя root. Остальное должно пройти “автоматом”.
Когда все требуемые пакеты будут установлены, можно загрузить SAMS:

Установим его:

Скачаем и установим web-интерфейс для SAMS и документацию:

Примечание 10. Описание установки SAMS полностью повторяет оригинальную инструкцию, доступную на официальном сайте (ссылки ниже). Однако, вместо рекомендуемой там версии sams-web_1.0.3-2 используется sams-web_1.0.4-2, так в 3-й версии наблюдаются проблемы и конфликты при установке. В 4-й таких проблем замечено не было.

Создаем пользователя SAMS всвежеустановленной БД mysql:

Конечно, “password” меняем на свой пароль.
Далее редактируем /etc/sams.conf:

Отыскиваем там строку, содержащую MYSQLPASSWORD и вписываем свой пароль, указанный выше:

Создаем базы SAMS в mysql:

Редактируем конфигурационный файл php:

В нем необходимо указать:

Редактируем /etc/init.d/sams:

Меняем значение параметра SAMS_ENABLE с FALSE на TRUE.
На этом настройку SAMS можно считать завершенной. web-интерфейс для управления пользовательскими записями будет доступен по адресу http://server/sams, где server – имя или ip-адрес шлюза на Debian'е. По умолчанию: пользователь – admin, пароль – qwerty.

Теперь добавим к шлюзу возможность проверки http-трафика антивирусом “на лету”, используя связку squid+havp+clamav. squid уже установлен, осталось установить havp – HTTP Anti Virus Proxy, и ClamAV – собственно антивирус. HAVP будем устанавливать в качестве Parent proxy для Squid, что позвоил обеспечить цепочку

Приступим:

Снова редактируем конфиг squid'а:

Ищем/правим/добавляем и приводим к следующему виду строки:

После перезапуска/переконфигурирования squid'а все должно работать. Линк для теста антивируса будет ниже.

На этом не останавливаемся и переходим к установке “баннерорезалки” – adzapper, которая должна избавить пользователей нашей сети от навязчивой рекламы в интернете:

После установки редактируем его конфиг /etc/adzapper.conf:

Меняем значение параметра

Теперь вместо рекламы на сайтах будет отображаться белый фон. По умолчанию – заставка adzapper'a. Возможен еще вариант с использованием собственного логотипа (см. линки ниже).
Снова правим конфигурационный файл squid'а:

Нужно добавить в него одну строку:

Перезапускаем/реконфигурируем squid и смотрим на результат.

Последнее, что требуется сделать, – это добавить пару строк-заданий в планировщик cron:

Допишем в конце файла:

Таким образом, черные списки adzapper и вирусные базы ClamAV будут автоматически обновляться.

Ссылки по теме, источники:
Настройка роутера на базе Debian (+пример настройки фаервола)
Установка и настройка SAMS в Debian Lenny
Установка и настройка adzapper
Установка и настройка HAVP+ClamAV+Squid
Проверка антивируса, тестовый зараженный файл (Будьте осторожны!)

Вроде все. Надеюсь, ничего не забыл/не перепутал. Как обычно на профессионализм не претендую, Debian вижу впервые. Просто хотелось сохранить небольшой “мануал” для себя. Не думаю, что он поможет тем, кто с Linux'ом давно дружит, а вот “любопытным юзерам” может и пригодится.

В итоге мы должны получить шлюз с прозрачным кэширующим прокси-сервером, проверкой трафика “на лету” антивирусом и “баннерорезалкой”, а также с удобным управлением через web-интерфейс. При этом на клиентских машинах никакой особой настройки не требуется, главное указать шлюз по умолчанию и DNS, а также не забыть добавить пользователя через SAMS.

В случае использования DHCP-сервера клиенты вообще получают все настройки автоматически.

P.S. По мере выявления проблем/добавления новых возможностей/etc, надеюсь, буду обновлять пост.

Источник: http://www.openkazan.info/node/3456

Настройка прокси-сервера – Файловый шлюз НРД (старая версия) – IT Global products documentation

Файловый шлюз поддерживает только HTTP прокси серверы. Прочие виды прокси серверов не поддерживаются.

Для настройки прокси-сервера необходимо перейти в раздел Настройки→Настройки proxy (рис. 1) и установить требуемые параметры. В таблице 1 приведено описание полей, необходимых для заполнения, в зависимости от режима прокси-сервера.

Рисунок 1 – настройка прокси сервера

Таблица 1 – Описание полей

Название поляОписание поля

Режим прокси сервера	Прокси сервер не используется System – используется прокси сервер, заданный в настройках Internet Explorer Http – используется HTTP-прокси сервер с аутентификацией по логину и паролю, указанный в файле конфигурации svc.config HttpNtlm – используется http-прокси
Адрес прокси-сервера	IP-адрес прокси-сервера. Используется только для режима Http и HttpNtlm
Порт прокси сервера	Номер порта прокси-сервера. Используется только для режима Http и HttpNtlm
Имя пользователя для прокси сервера	Имя пользователя. Используется только для режима System и Http
Пароль пользователя для прокси сервера	Пароль пользователя. Используется только для режима System и Http

Для сохранения указанных параметров необходимо нажать кнопку Сохранить (рис. 1,4) и перезапустить службу (см. Запуск Файлового шлюза).

Для перехода к файлу svc.config необходимо вставить %LOCALAPPDATA% в проводник OC Windows и нажать клавишу Enter на клавиатуре, затем перейти в папку установки NSD.FileGateway.

Прокси сервер не используется

Необходимо проставить параметр в файле конфигурации svc.config:

… …

HTTP прокси сервер, указанный в настройках Internet Explorer

Необходимо проставить параметр в файле конфигурации svc.config:

… …

Если требуется указать логин и пароль для аутентификации на прокси сервере, дополнительно указываются параметры:

HTTP прокси сервер с аутентификацией по логину и паролю

Необходимо проставить параметр в файле конфигурации svc.config:

… …

HTTP прокси сервер с аутентификацией через пользователя домена

Необходимо проставить параметр в файле конфигурации svc.config:

… …

Режим HttpNtlm не позволяет указать пользователя, от имени которого будет осуществляться аутентификация. Будет использован пользователь, от имени которого запущен Файловый шлюз.

Источник: http://docs.itglobal.ru/x/OgAt

Установка и настройка SQUID3 прокси сервера, на базе Ubuntu Server 14.04.1

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

С помощью прокси сервера, можно не только предоставить централизованный доступ к интернету, но и лимитировать его, закрывать доступ к определенным сайтам, открывать доступ только к разрешенным сайтам, кэшировать статичные данные (css, картинки, баннеры…) и многое другое.

Для установки прокси сервера я буду использовать уже готовый сервер с ubuntu 14.04.1 и настроенными службами DHCP и DNS. И так, приступим.

Открываем доступ к интернету для компьютеров в локальной сети

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

Создадим файл с настройками

Внесем в этот фал следующее:

#!/bin/sh
#Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward
#Разрешаем траффик на lo
iptables -A INPUT -i lo -j ACCEPT
#Разрешаем доступ из внутренней сети наружу
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
#Включаем NAT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j MASQUERADE
#Разрешаем ответы из внешней сети
iptables -A FORWARD -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT
#Запрещаем доступ снаружи во внутреннюю сеть
iptables -A FORWARD -i eth0 -o eth1 -j REJECT

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

Добавим запуск NATа (строку post-up /etc/nat) в файл с сетевыми настройками:

sudo nano /etc/network/interfaces

ваш файл должен выглядеть так:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.104
netmask 255.255.255.0
gateway 192.168.1.1
auto eth1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0
post-up /etc/nat

Сохраняем, закрываем и перезагружаем сервер:

В таком виде, все готово для раздачи интернета компьютерам в сети. Если сейчас включить клиентский компьютер, он получит IP адрес от DHCP сервера, а также получит настройки шлюза (192.168.0.1), соответственно должен появится интернет. Если интернет появился, двигаемся дальше, если нет, проверяем что сделали не так.

Установка и настройка Squid3

Теперь нам нужно установить Squid3 – сам прокси сервер. В статье описаны базовые настройки, для более углубленной настройки, советую почитать документацию по squid.

Устанавливаем пакет squid3

sudo aptitude install squid3

После установки откроем файл /etc/squid3/squid.conf

sudo nano /etc/squid3/squid.conf

В первую очередь найдем строку http_port 3128 и добавим к ней значение intercept и IP адрес сервера, чтобы получилось вот так:

http_port 192.168.0.1:3128 intercept

Это делается для того, чтобы в последующем нам не приходилось настраивать прокси сервер на всех клиентских машинах (прокси будет прозрачным).

Теперь, нужно указать сеть в которой будет работать наш прокси сервер, для этого раскомментируем строку acl localnet src 192.168.0.0/16 # RFC1918 possible internal network и укажем префикс маски сети 24 вместо 16 (так как у нас маска 255.255.255.0). В итоге срока должна выглядеть так:

acl localnet src 192.168.0.0/24 # RFC1918 possible internal network

разрешаем доступ к прокси из внутренней сети, расскомментировав строку

http_access allow localnet

Теперь настроим кэширование. Нужно найти строку cache_dir ufs /var/spool/squid3 100 16 256, раскомментировать её и поменять значения на такие:

cache_dir ufs /var/spool/squid3 2048 16 256

Далее расскомментируем строку maximum_object_size 4 MB, тем самым укажем максимальный размер кэшируемого объекта.

Раскомментируем строку maximum_object_size_in_memory 512 KB, тем самым указываем максимальный объем кэшированного объекта в памяти.

Раскомментируем строку cache_mem 256 MB и заменим занчение с 256 на 1024, тем самым указываем допустимый объем памяти.

Вот мы и настроили кэширование, кэширование должно снизить нагрузку на канал и увеличить скорость открытия страниц. Кэш очищается при перезагрузке сервера.

Теперь включим ведение логов, для этого раскомментируем строку access_log daemon:/var/log/squid3/access.log squid и добавим ниже logfile_rotate 31(файлы логов будут храниться 31 день, после будут перезаписываться самые старые).

На этом базовую настройку squid3 можно завершить. Перезапустим squid3

sudo service squid3 restart

Теперь прокси сервер настроен и запущен, но для того чтобы трафик пользователей шел именно через него, нужно завернуть весь http трафик на squid. Для этого добавляем в /etc/nat строку:

# Заворачиваем http на прокси
iptables -t nat -A PREROUTING -i eth1 ! -d 192.168.0.0/24 -p tcp -m multiport –dport 80,8080 -j DNAT –to 192.168.0.1:3128

Собствеенно теперь мой файл /etc/nat имеет такой вид:

Если вы сделали все как написано в статье, значит у вас будет полностью рабочий прокси сервер. В следующих статьях я напишу как установить контент – фильтр Dansguardian и как сделать black list для добавления запрещенных сайтов.

Если остались вопросы, добро пожаловать в комментарии.

via

Ещё на сайте:

Помогла статья? Помоги сайту, поделись ссылкой!

Интересные статьи по теме:

Источник: https://faqpc.ru/nastrojka-squid3-na-ubuntu-server-14-04-1/

Прозрачный Squid

Сервер в кармане, или просто о сложном!

главная –<\p>

Теги: Настройка прокси

Зачем нужен прозрачный Squid

Для начала представим, что у нас есть обычная сеть, выходящая в интернет через один шлюз (прокси-сервер Squid установлен здесь же). Предположим, IP-адрес шлюза 192.168.1.1. Все остальные компьютеры в сети получают настройки IP по DHCP. Компьютеры в сети разные, Windows XP/7, Ubuntu, да моло ли еще какие. За всеми не углядишь.

Но мы должны считать трафик, ускоряя при этом доступ в интерент, должны контролировать (хотя бы от “дурака”) доступ в интернет и пр. Squid обладает широкими возможностями по логированию, ограничению доступа и пр. Поэтому нам нужно, чтобы все компьютеры в сети не могли миновать нашего прокси-сервера Squid.

Поэтому нам надо в любом случае направить (завернуть, пробросить) запрос клиентских компьютеров только через прокси-сервер Squid.

Настройка переадресации портов

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

Наша задача – сделать так, чтобы на самом клиенте не надо было бы делать никаких настроек броузеров. Клиент просто подключился к локальной сети и уже работает через наш прокси-сервер и НИКАК иначе. Т.е. даже если кто-либо захочет обойти наш прокси, без хитростей ему уже не обойтись.

Переадресация портов в FreeBSD

Если на нашем шлюзе установлена FreeBSD и брандмауэр по-умолчанию – IPFW, то для выполнения этой задачи мы должны на шлюзе установить переадресацию (проброс) портов:

# Redirect to local proxy
/sbin/ipfw add 0170 fwd 127.0.0.1,3128 tcp from 192.168.1.0/24 to any 80

где:

0170 – номер правила (в вашем случае может быть любой).
fwd 127.0.0.1,3128 – куда будем направлять пакеты, – в нашем случае нашему любимому Squid, запущенному на порту 3128 на шлюзе, – …
from 192.168.1.0/24 – … отправленные компьютерами локальной сети…
to any 80 – … на какой-либо сайт в интернете

Теперь внимание! Это правило нужно добавить ДО того, как правила NAT (Network Address Translation) получат этот запрос.

Объясню немного неакадемично: что делает NAT? В нашем случае NAT изменяет адрес источника (заменяет локальный IP клиента на внешний IP шлюза и запоминает, от какого внутреннего клиента был запрос.

Для того, чтобы Squid обработал запрос от клиента, ему не нужно ничего преобразовывать – он и сам с этим справится. Поэтому Squid должен получить пакет в первозданном виде и сам решить, что делать дальше.

К тому же NAT и Squid – все-таки разные вещи, и пакет, адресованный, скажем к 2.3.4.5:80, не содержит информации, как попасть в Squid (на порт 3128 шлюза). И пакет будет обрабатываться только средствами NAT. Squid пакет так и не увидит. Поэтому наша задача – просто отдать Squid-у тот пакет, который отправил броузер пользователя. Объясню на примере части конфига ipfw:

cmd=”ipfw -q add” $skip=”skipto 5000″ pif=”xl1″ #внешний интерфейс … # Redirect to local proxy $cmd 0170 fwd 127.0.0.1,3128 tcp from 192.168.1.0/24 to any 80 # NAT $cmd 0200 divert natd ip from any to any in via $pif # Allow keep-state statement. $cmd 0201 check-state # POP3/POP3S $cmd 0325 $skip tcp from any to any 110 out via $pif setup keep-state $cmd 0326 $skip tcp from any to any 995 out via $pif setup keep-state # WWW (HTTP/HTTPS/..) $cmd 0350 $skip tcp from any to any 80 out via $pif setup keep-state $cmd 0352 $skip tcp from any to any 443 out via $pif setup keep-state # This is skipto location for outbound stateful rules $cmd 5000 divert natd ip from any to any out via $pif …

В конфиге выше запрос открыть сайт сначала обрабатывается правилом 0170, которое заворачивает запрос в Squid.

Squid (как и любая другая программа) также выполняет требования брандмауэра – только для него правило 0170 не действует, а вот правило 0350 разрешает Squid отправить запрос в интернет.

Для того, чтобы выходить в интернет без Squid, необходимо закоментировать правило 0170. В этом случае Squid не получит ничего, а все запросы броузеров из локальной сети будут обрабатываться правилом 0350.

Переадресация портов в Linux

Если на нашем шлюзе установлена Linux и iptables, то вышеуказанная команда будет выглядеть так:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 3128

где eth0 – внутренний интерфейс.

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

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

Прозрачный Squid в squid.conf

Теперь дело осталось за малым – настроить Squid в режим невидимки, т.е. принимать автоматически перенаправленные пакеты и обрабатывать их. В разных версиях Squid за это отвечали разные команды. Настройка Squid версии 2.6.* выглядит так:

http_port 127.0.0.1:3128 transparent # Squid работает в прозрачном режиме

Внимательно просмотрите конфигурационный файл squid.conf на предмет дубликатов директив – я потратил два часа времени, обратился на форум за помощью с “нестандартной проблемой”, в то время как просто не обратил внимание на то, что первой строкой у меня включался обычный режим работы Squid:

http_port 3128 # Squid работает в обычном режиме

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

А теперь попробуйте настроить прокси на каком-нибудь компьютере – компьютер не должен получить выход в интернет. Вроде все.

Если есть вопросы или советы – комментарии приветствуются, особенно учитывая, что настройка прозрачного Squid и проброс портов вообще “больная” тема на форумах.

Плюсы и минусы

Из плюсов можно отметить абсолютную уверенность, что все запросы на 80 порт (стандартный для веб) будут обработаны Squid-ом. Соответственно, будут логи, статистика для шефа и отсутствие необходимости бегать и руками все настраивать.

Из минусов можно отметить:

невозможность (по-крайней мере, простым способом) авторизовать пользователей для доступа в интернет;
если вдруг “упадет” Squid, то доступ к сайтам прекратится. Поэтому админу нужно или быть уверенным, что все будет ОК, или иметь возможность удаленно изменить конфиг брандмауэра, или написать скрипт, автоматом проверяющего, висит ли Squid на порту 3128, и если нет, то запускающего его.

Настройка Squid в прозрачном режиме завершена. Вот теперь – все.

Авторизуйтесь для добавления комментариев!

Источник: https://bozza.ru/art-162.html

Настройка параметров прокси-сервера для локального шлюза данных – Power BI

11/21/2017
Время чтения: 6 мин
Соавторы

Рабочие среды могут требовать, чтобы доступ в Интернет осуществлялся через прокси-сервер.

Your work environment may require that you go through a proxy to access the internet. Это может помешать локальному шлюзу данных подключаться к службе.

This could prevent the On-premises data gateway from connecting to the service.

Используется ли прокси-сервер в вашей сети?Does your network use a proxy?

В приведенной ниже публикации на сайте superuser.com описано, как попытаться определить наличие прокси-сервера в сети.The following post on superuser.com discusses how you can try to determine if you have a proxy on your network.

Как узнать, какой прокси-сервер используется? (SuperUser.com)How do I know what proxy server I'm using? (SuperUser.com)

Расположение файла конфигурации и конфигурация по умолчаниюConfiguration file location and default configuration

Сведения о прокси-сервере настраиваются в файле конфигурации платформы .NET.Proxy information is configured within a .NET configuration file. Расположение и имена файлов зависят от используемого шлюза.The location, and file names, will be different depending on the gateway you are using.

Локальный шлюз данныхOn-premises data gateway

Локальный шлюз данных использует два основных файла конфигурации.There are two main configuration files that are involved with the On-premises data gateway.

КонфигурацияConfiguration

Первый предназначен для экранов конфигурации, используемых непосредственно для настройки шлюза.The first is for the configuration screens that actually configure the gateway. Если возникают проблемы при настройке шлюза, обратитесь именно к этому файлу.If you are having issues configuring the gateway, this is the file you will want to look at.

C:Program FilesOn-premises data gatewayenterprisegatewayconfigurator.exe.config

Служба WindowsWindows Service

Второй служит для фактической службы Windows, которая взаимодействует со службой Power BI и обрабатывает запросы.The second is for the actual windows service that interacts with the Power BI service, and handles the requests.

C:Program FilesOn-premises data gatewayMicrosoft.PowerBI.EnterpriseGateway.exe.config

Настройка параметров прокси-сервераConfiguring proxy settings

По умолчанию для прокси-сервера используется следующая конфигурация:The default proxy configuration is the following.

В конфигурации по умолчанию применяется аутентификация Windows.The default configuration works with Windows authentication. Если прокси-сервер использует другую форму проверки подлинности, необходимо изменить параметры.If your proxy uses another form of authentication, you will need to change the settings.

Если вы не уверены, что именно следует сделать, обратитесь к администратору сети.If you are not sure, you should contact your network administrator. Не рекомендуем использовать обычную проверку подлинности прокси. При попытке ее выполнения могут возникнуть ошибки, которые приведут к неправильной настройке шлюза.

Basic proxy authentication is not recommended, and attempting to use basic proxy authentication may cause proxy authentication errors that result in the gateway not being properly configured. Чтобы устранить ошибку, выберите более надежный механизм проверки подлинности прокси.

Use a stronger proxy authentication mechanism to resolve.

Помимо использования учетных данных по умолчанию, можно добавить элемент In addition to using default credentials, you can add a Например, можно указать, что локальный шлюз данных всегда должен использовать прокси-сервер даже для локальных ресурсов, присвоив параметру bypassonlocal значение false.

For example, you can specify that your On-premises data gateway should always use the proxy even for local resources by setting the bypassonlocal parameter to false. Это может помочь при устранении неполадок, если нужно отслеживать все запросы по протоколу HTTPS от локального шлюза данных в файлах журнала прокси-сервера.

This can help in troubleshooting situations if you want to track all https requests originating from an On-premises data gateway in the proxy log files. В соответствии с приведенным ниже образцом конфигурации все запросы должны передаваться через определенный прокси-сервер с IP-адресом 192.168.1.10.

The following sample configuration specifies that all requests must go through a specific proxy with the IP address 192.168.1.10.

Дополнительные сведения о настройке элементов прокси-сервера в файлах конфигурации .NET см. в статье об элементе defaultProxy (параметры сети).To learn more about the configuration of the proxy elements for .NET configuration files, see defaultProxy Element (Network Settings).

Смена учетной записи службы шлюза на пользователя доменаChanging the gateway service account to a domain user

Если при настройке параметров прокси-сервера вы указали учетные данные по умолчанию, как описано выше, могут возникнуть проблемы с проверкой подлинности.When configuring the proxy settings to use default credentials, as explained above, you may encounter authentication issues with your proxy.

Это связано с тем, что учетная запись службы по умолчанию представляет собой идентификатор безопасности службы, а не прошедшего проверку подлинности пользователя домена.This is because the default service account is the Service SID and not an authenticated domain user. Чтобы настроить правильную проверку подлинности на прокси-сервере, вы можете сменить учетную запись службы шлюза.

You can change the service account of the gateway to allow proper authentication with your proxy.

Примечание

Чтобы избежать необходимости сбрасывать пароли, рекомендуется использовать управляемую учетную запись службы.It is recommended that you use a managed service account to avoid having to reset passwords. Узнайте, как создать управляемую учетную запись службы в Active Directory.Learn how to create a managed service account within Active Directory.

Изменение учетной записи службы локального шлюза данныхChange the On-premises data gateway service account

Сведения о том, как изменить учетную запись службы Windows для локального шлюза данных.Change the Windows service account for the On-premises data gateway service.

По умолчанию в качестве учетной записи для этой службы используется NT SERVICEPBIEgwService.The default account for this service is NT SERVICEPBIEgwService. Ее рекомендуется заменить учетной записью пользователя домена Active Directory.

You will want to change this to a domain user account within your Active Directory domain. Кроме того, чтобы избежать необходимости менять пароль, можно воспользоваться управляемой учетной записью службы.

Or, you will want to use a managed service account to avoid having to change the password.

Учетная запись меняется на вкладке Вход в свойствах службы Windows.You will want to change the account on the Log On tab within the properties of the Windows service.
Перезапустите службу локального шлюза данных.Restart the On-premises data gateway service.

Выполните следующую команду в окне командной строки администратора.From an admin command prompt, issue the following commands.

net stop PBIEgwService net start PBIEgwService
Запустите средство настройки локального шлюза данных.Start the On-premises data gateway configurator. Вы можете нажать кнопку пуска Windows и выполнить поиск по запросу локальный шлюз данных.You can select the windows start button and search for On-premises data gateway.
Войдите в Power BI.Sign in to Power BI.
Восстановите шлюз с помощью ключа восстановления.Restore the gateway using your recovery key.

В результате новая учетная запись службы сможет расшифровать учетные данные, сохраненные для источников данных.This will allow the new service account to be able to decrypt stored credentials for data sources.

Примечание

Если вы изменяете учетную запись службы непосредственно на панели управления службами, записи ACL не обновляются автоматически.When you change the service account directly using Services Control panel, it does not update ACLs automatically.

Необходимо убедиться, что новая учетная запись службы предоставляет доступ к файлам и папке установки.You need to ensure that new service account has access to the installation files and folder. Папка установки локального шлюза данных находится здесь: C:Program FilesOn-premises data gateway.

You can find Gateway Installation folder under C:Program FilesOn-premises data gateway.

Дальнейшие действияNext steps

Локальный шлюз данных (персональный режим) Сведения о брандмауэреOn-premises data gateway (personal mode) Firewall information
Появились дополнительные вопросы?More questions? Ответы на них см. в сообществе Power BI.Try the Power BI Community

Источник: https://docs.microsoft.com/ru-ru/power-bi/service-gateway-proxy

Прозрачный прокси сервер squid3 squidguard iptables sarg – Блог системного администратора, для IT Специалистов

В данной статье приводится пример быстрой настройки кэширующего прокси сервера Squid в Linux Debian 6. Результатом настройки станет возможность выхода в Интернет через данный сервер по протоколам: http, https и ftp.Сразу оговорюсь, что полученный сервер не является сетевым фильтром и потенциально уязвим для сетевых атак.

Настройка сервера осуществляется на базе ОС Linux Debian 6. Все приводимые ниже команды должны выполняться с правами суперпользователя (root).Сразу важное предупреждение: авторизация и прозрачный прокси несовместимы! Придется выбирать что-то одно.

Второе предупреждение: авторизация через прокси позволит ограничить доступ в Интернет только по HTTP протоколу. Остальные протоколы: FTP, SMTP, POP3 и другие будут спокойно продолжать работать через NAT.

Хотя в небольших организациях это не столь критично, наиболее употребляемым (и злоупотребляемым) является именно протокол HTTP, и одной из задач администратора является ограничение доступа сотрудников в интернет именно через браузер.

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

# apt-get update

Запускаем установку Squid:

# apt-get install squid3

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

cp /etc/squid/squid.conf /etc/squid/squid.conf.original

и выжмем из оригинальной конфигурации всё, не закоментированное:

cat /etc/squid/squid.conf.original | grep -v '^(#|$)' > /etc/squid/squid.conf

В итоге заимеем дефолтный конфигчик без ничего нишнего. Но всё же очень советую кинуть взор в оригинальный конфиг и почитать его на досуге — там очень много интересного!

Ну, наконец, приступим к редактированию:

nano /etc/squid/squid.conf

После установки, требуется небольшая настройка. Открываем в редакторе конфигурационный файл Squid, который должен располагаться в /etc/squid/squid.conf. В этом файле находим строки:

acl localnet src 10.0.0.0/8acl localnet src 172.16.0.0/12

acl localnet src 192.168.0.0/16

Эти строки необходимо закоментировать. И добавить свою строку с параметрами собственной локальной сети. Должно получиться так:

# acl localnet src 10.0.0.0/8# acl localnet src 172.16.0.0/12# acl localnet src 192.168.0.0/16

acl localnet src 192.168.1.0/24 # Собственная локальная сеть

В последней строке вместо 192.168.1.0/24 нужно подставить параметры Вашей сети.

Чуть ниже комментария # TAG: http_access необходимо найти строку:

http_access allow localhostили

http_access allow manager localhost

Сразу после этой строки добавляем строку:

http_access allow localnetcache_dir ufs /var/cache/squid 2048 16 256mkdir -p /var/cache/squid

chmod 755 -R /var/cache/squid

Разрешая тем самым доступ в сеть всем компьютерам из локальной сети. После этого сохраняем файл squid.conf и перезапускаем Squid сервер:

# /etc/init.d/squid restart

Если после рестарта squidа у вас вылезет ошибка (WARNING cache_mem is larger than total disk cache space!) просто уменьшите значение параметра cache_mem 8 MB я поставил 32Если Вы с конфигурационный файл внесли изменения из ошибок, то Squid должен успешно перезагрузиться.

При возникновении ошибки можно узнать из-за чего она произошла в Log-файле: /var/log/squid/cache.logНастройка обозревателя на работу через Proxy-серверВ данном варианте настройки наш сервер не может автоматически маршрутизировать сетевые запросы на порт прокси сервера.

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

В открывшемся окне поставить галочку в поле Использовать прокси-сервер для локальных подключений. Поставить галочку на Не использовать прокси-сервер для локальных адресов. В поле Адрес ввести IP-адрес нашего прокси сервера: 192.168.1.1. В поле Порт ввести порт, применяемый Squid по-умолчанию: 3128.

После этих настроек Ваш обозреватель будет выходить в сеть через наш новый прокси-сервер. В других обозревателях настройка аналогичная приведенной выше для Microsoft Internet Explorer.

Порт прокси-сервера можно поменять по своему усмотрению в файле /etc/squid/squid.conf. Он задан в строке:

http_port 3128 transparent

ЗаключениеУстановка и настройка кэширующего прокси сервера на базе Squid это всего лишь первый этап в создании производительного шлюза в Интернет.

Чуть позже я расскажу как настроить «Прозрачный прокси сервер», Firewall и как можно вести статистику посещений пользователями сайтов пользователями локальной сети.

Очень важно правильно настроить iptables. Второй вариант чуть ниже, мне он больше по душе

На этом шаге я предлагаю Вам создать скрипт настройки, так как он пригодится как универсальное средство.1 # vim ./setiptables.sh

#!/bin/bashLAN=$1WAN=$2IP=$3GW=$4iptables -t nat -A PREROUTING -i $LAN -p tcp –dport 80 -j DNAT –to $IP:3128iptables -t nat -A PREROUTING -i $WAN -p tcp –dport 80 -j REDIRECT –to-port 3128iptables -t nat -A POSTROUTING -j MASQUERADEiptables -A FORWARD -i $WAN -o $LAN -s $GW/24 -p tcp -m multiport –dport 443,21,22 -j ACCEPTecho 'net.ipv4.ip_forward = 1' > /etc/sysctl.conf

sysctl -w net.ipv4.ip_forward=1

Мы обозначили переменные (для удобства), 3 правила для таблицы NAT и 1 для FORWARD.Порты 443,21,22 пускаем в обход прокси сервера.Помимо настроек iptables, в этом скрипте, мы включаем форвардинг пакетов.

Запускаем так:1

# sh ./setiptables.sh eth0 eth1 192.168.100.1 192.168.100.0

6) Настроим автозагрузку натсроек iptables.

Сохраням настройки iptables.

# mkdir -p /usr/local/iptables && iptables-save > /usr/local/iptables/session.ipt

Добавляем команду авотзапуска в /etc/rc.local (мне нравится Perl но тут кому как).

# perl -i -pe 'print “iptables-restore < /usr/local/iptables/session.ipt " if $. == 2' /etc/rc.local

Также не забываем про форвардинг пакетов

# perl -i -pe 'print “sysctl -w net.ipv4.ip_forward=1
” if $. == 3' /etc/rc.local

Второй вариант настройки firewall iptables

Для ознакомления и изучения, рекомендую почитать здесь.

Включим в системе форвардинг. В файле /etc/sysctl.conf раскомментируем строчку

net.ipv4.ip_forward=1

Итак, на текущий момент мы имеем полностью сброшенные настройки файрвола (iptables).

Сбрасываем цепочки:

$ sudo iptables -F$ sudo iptables -F -t natЗапрещаем все входящие и разрешаем все исходящие и форвардинг:sudo iptables -P INPUT DROPsudo iptables -P OUTPUT ACCEPTsudo iptables -P FORWARD ACCEPTРазрешаем принимать ответ на УЖЕ установленный соединени:sudo iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPTРазрешаем loopback-трафик:sudo iptables -A INPUT -i lo -j ACCEPTРазрешаем весь трафик с нашей внутренней сети (возьмем подсеть 222):sudo iptables -A INPUT -s 192.168.222.0/24 -i eth1 -j ACCEPTИ, залог прозрачности! Перенапрявляем весь исходящий http-трафик (на порт 80) на порт сквида 3128:iptables -t nat -A PREROUTING -s 192.168.222.0/24 -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 3128

iptables -t nat -A POSTROUTING -s 192.168.222.0/24 -o eth0 -j SNAT –to-source 192.168.56.39

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

Итак, сохраним всё то, чем мы тут занимались:

iptables-save > /etc/firewall.conf

У меня с судо этот финт не получился (хотя в теории вроде должен…), потому можно сделать влогинившись в рута полностью (su) и запустив команду, но без sudo.

А теперь создадим скрипт, заставляющий ifupdown воскрешать наш файрвол:

nano /etc/network/if-up.d/00-iptables

Впишем в него следующее:

#!/bin/sh
iptables-restore < /etc/firewall.conf

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

chmod +x /etc/network/if-up.d/00-iptables

В целом настройка прозрачного прокси сервера закончена, но чтобы логи были читаемы, нам наобходимо отключить поддержку ipv6 (из за того что ipv6 у нас не настроен на адаптере будет много warnings).Отключаем IPv6 если кто не используетПредлагаю опять же сделать скрипт чтобы не запутаться.

nano ./ipv6disable.sh

#!/bin/bashperl -i -pe 'print “alias net-pf-10 ipv6 off
” if $. == 17' /etc/modprobe.d/aliases.confperl -i -pe 'print “alias net-pf-10 off
” if $. == 18' /etc/modprobe.d/aliases.confperl -i -pe 'print “alias ipv6 off
” if $. == 19' /etc/modprobe.d/aliases.confecho 1 | tee /proc/sys/net/ipv6/conf/all/disable_ipv6echo “blacklist ipv6″ | tee -a /etc/modprobe.d/blacklist.confSTR=$(cat /boot/grub/grub.cfg | sed -n '67p')STR=${STR}” ipv6.disable=1″sed '67d' /boot/grub/grub.cfg > /boot/grub/grub.cfg.backupcp /boot/grub/grub.cfg.backup /boot/grub/grub.cfg

sed -i 67i “$STR” /boot/grub/grub.cfg

В общих чертах что в этом скриптике происходит:Сперва отключаем пожжержку ipv6 в модулях ядра.Далее указываем маркер в /proc на не использование ipv6.И в 67 строке /boot/grub/grub.cfg дописываем параметр ipv6.disable=1.Такая канитель с tee и sed нужна для того чтобы сохранить настройки /boot/grub/grub.

cfg, так как там устройства обозначаются не по /dev/sd* и по UUID.Хотя все всегда можно дописать ручками.Теперь нам надо прикрутить squidguardИтак, половина работы уже сделана, теперь осталось установить пакет SquidGuard и настроить его.

Для установки пишем в терминале из под пользователя root (права root в Debian GNU/Linux можно получить командой su, в Ubuntu перед командами пишем sudo):

apt-get install squidguard

После установки скачаем черные списки blacklists комадной wget из терминала (внимание, размер файла 24 Мб!):

wget -c my_blacklists.tar.gz

И распакуем его в каталог, где должны распологаться базы SquidGuard (необходимы права администратора):

tar zxvf my_blacklists.tar.gz -C /var/lib/squidguard/db

В результате распаковки появится каталог /var/lib/squidguard/db/my, содержащий множество подкаталогов разных категорий со списками доменов и адресов нежелательных сайтов.

Этот список был составлен нами на основе трёх чёрных списков, загруженных с сайтов http://www.squidguard.org, http://www.shallalist.de и http://www.urlblacklist.com.

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

Теперь необходимо настроить связку Squid и SquidGuard и подключить к ним чёрные списки. Для этого в файл squid.conf дописываем следующие строки, открыв файл в редакторе nano с правами администратора:

nano /etc/squid/squid.conf

Добавляем строки в конец файла:

redirector_bypass onredirect_program /usr/bin/squidGuard

redirect_children 1

Далее переименовываем конфигурационный файл squidGuard.conf, который установился по-умолчанию, командой в терминале от администратора:

mv /etc/squid/squidGuard.conf /etc/squid/squidGuard.conf_original

Скачиваем файл конфигурации squidGuard.conf с нашего сайта командой wget в терминале:

wget -c squidGuard.conf

Копируем его на место старого файла (с правами администратора):

cp squidGuard.conf /etc/squid/squidGuard.conf

После копирования файла конфигурации инициируем конвертирование текстовых чёрных списков, которые вы скачали и распаковали, в формат баз данных Berkeley DB (команда будет выполняться некоторое время – нужно дождаться полного окончания), выполнив команду от администратора:

squidGuard -d -C all

Если всё сделано правильно, то после команды в терминале будет выдаваться множество сообщений о создании новых файлов баз, и в конце их череды вы увидите что-то подобное:

2012-03-16 12:51:53 [1990] squidGuard 1.4 started (1331887787.768)2012-03-16 12:51:53 [1990] db update done

2012-03-16 12:51:53 [1990] squidGuard stopped (1331887913.657)

Что скажет об успешном завершении создании баз черных списков. Далее задаём права сервера Squid на файлы баз, выполнив команду с правами администратора:

chown -R proxy:proxy /var/lib/squidguard/db/

И рестартуем сервер Squid выполнив в Debian от root:

/etc/init.d/squid3 restart

После рестарта в результате совместной работы Squid и SquidGuard будет работать перенаправление с нежелательных сайтов на сайт http://www.sysadmin-komi.ru. Вместо неё вы можете поставить любую другую страничку, изменив адрес последней строки файла конфигурации /etc/squid/squidGuard.conf.

Изменение записей в списках доменов и URL

Пример. Рядом с файлом domains.db в папке /var/lib/squiguard/db/направление создаём файл domains.diff. В него заносим строку или несколько строк, по одной на каждую запись:

-sysadmin-komi.ru (что означает вычеркнуть этот домен из базы)
или +sysadmin-komi.ru (что означает добавить этот домен в базу)

Даём команды:

$ squidGuard -u

(обновить базы db из файлов diff. В логах squidguard'а можно посмотреть сколько добавилось/убылось.)

$ squid3 -k reconfigure

(перечитать настройки без перезапуска.)Файл domains.diff удалять, или стирать из него записи, не надо. При глобальном обновлении баз этот файл ещё пригодится. И при многократном обновлении не происходит дублирования записей в БД.Вы можете создавать свои правила редиректов, добавляя или исключая категории нежелательных сайтов.

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

Если вам требуется сильная защита, то SquidGuard можно настроить на работу с белым списком разрешенных сайтов, запретив всё остальное – но тогда будет совсем ограниченный набор сайтов.

И остался один момент! Поставим статистику кто что куда и почему, по имени sarg

apt-get install sarg

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

Подгоняем конфигурацию (/etc/squid/sarg.conf) под себя. Вот главные строчки, на которые следует обратить внимание:

access_log /var/log/squid/access.log…output_dir /var/www/squid-reports…charset UTF-8

Создаем последний каталог, ежели его нет.

Запускаем сарж (неплохо б было его запуск пихануть в крон, здесь я не буду это описывать… пока что)

$ sarg

Ура! Заходим изнутри сети на наш сервер, любуемся отчетами по адресу http://IP_SERVER/squid-reports/

Все ребята готово. Будут вопросы спрашивайте, помогу чем смогу.

Источник: https://www.sysadmin-komi.ru/linux/squid/prozrachnyj-proksi-server-squid3-squidguard-iptables-sarg.html