YouTube съедал весь канал: настраиваем Squid-прокси для рекламного агентства

Задача клиента: рекламное агентство без контроля над трафиком

Летом 2025 года к нам в АйТи Фреш обратилось рекламное агентство BrightMedia из Санкт-Петербурга. 70 человек в штате: дизайнеры, копирайтеры, менеджеры, бухгалтерия. Оптика на 200 Мбит/с — канал, которого должно было хватать с запасом.

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

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

  • 42% трафика — YouTube (фоновые видео, music mix на рабочих местах)
  • 18% — социальные сети (Instagram, TikTok, VK видео)
  • 12% — Telegram-каналы (стикерпаки, видео в чатах)
  • 28% — рабочий трафик (CRM, почта, облачные хранилища, видеосвязь)

Итого: 72% канала уходило мимо работы. Причём просто заблокировать YouTube и соцсети не получалось — дизайнеры и SMM-специалисты работали с ними напрямую, по задачам клиентов. Рубить сплеча нельзя.

«Мне не нужна тюрьма. Мне нужна прозрачность и разумные ограничения» — директор BrightMedia.

Требования к решению

Вместе с клиентом сели и сформулировали, что конкретно нужно:

  1. Ограничить скорость видеостриминга для всех, кроме отдела SMM и дизайна
  2. Блокировать заведомо нерабочие ресурсы (онлайн-казино, торренты, adult-контент)
  3. Аутентификация через существующий Active Directory — без отдельных паролей
  4. Отчёты по использованию интернета — по отделам и сотрудникам
  5. Приоритизация бизнес-трафика (CRM, видеоконференции, облачные сервисы)
  6. Решение не должно стоить как корпоративный UTM-файрвол

Мы предложили связку Squid + SquidGuard + SARG на отдельном сервере под Ubuntu 22.04 LTS. Железо — один сервер за 45 000 ₽. Весь софт — бесплатный. Для задач агентства этого оказалось более чем достаточно.

Установка и базовая настройка Squid

Squid развернули на выделенном сервере с двумя сетевыми интерфейсами: один смотрит в локальную сеть офиса (192.168.10.0/24), второй — в WAN. Классическая схема, работающая без сюрпризов.

Установка из пакетов Ubuntu

# Обновляем систему
sudo apt update && sudo apt upgrade -y

# Устанавливаем Squid и вспомогательные пакеты
sudo apt install -y squid squid-openssl squidguard \
  apache2-utils sarg lightsquid

# Проверяем версию
squid -v | head -3
# Squid Cache: Version 5.7
# Service Name: squid
# configure options: '--with-openssl' ...

# Делаем бэкап оригинального конфига
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak

Основная конфигурация squid.conf

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

# /etc/squid/squid.conf
# === СЕТЕВЫЕ НАСТРОЙКИ ===
http_port 3128
http_port 3129 intercept        # для прозрачного проксирования
https_port 3130 intercept ssl-bump \
  cert=/etc/squid/ssl/squid-ca.pem \
  generate-host-certificates=on \
  dynamic_cert_mem_cache_size=16MB

# === КЭШИРОВАНИЕ ===
cache_mem 512 MB
maximum_object_size_in_memory 2 MB
maximum_object_size 256 MB
cache_dir ufs /var/spool/squid 10000 16 256
cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF

# === DNS ===
dns_nameservers 192.168.10.1 8.8.8.8
positive_dns_ttl 6 hours
negative_dns_ttl 1 minute

# === ЛОГИРОВАНИЕ ===
access_log daemon:/var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
logfile_rotate 30

# === АУТЕНТИФИКАЦИЯ (LDAP через AD) ===
auth_param basic program /usr/lib/squid/basic_ldap_auth \
  -v 3 -R -b "DC=brightmedia,DC=local" \
  -D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
  -w "${LDAP_BIND_PASSWORD}" \
  -f "(&(sAMAccountName=%s)(objectClass=person))" \
  -h dc01.brightmedia.local
auth_param basic children 10 startup=3 idle=3
auth_param basic realm BrightMedia Proxy
auth_param basic credentialsttl 2 hours

# Внешний хелпер для получения LDAP-групп
external_acl_type ldap_group ttl=300 %LOGIN \
  /usr/lib/squid/ext_ldap_group_acl \
  -v 3 -R -b "DC=brightmedia,DC=local" \
  -D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
  -w "${LDAP_BIND_PASSWORD}" \
  -f "(&(sAMAccountName=%u)(memberOf=CN=%g,OU=Groups,DC=brightmedia,DC=local))" \
  -h dc01.brightmedia.local

# === ACL ОПРЕДЕЛЕНИЯ ===
acl authenticated proxy_auth REQUIRED

# Группы из AD
acl group_smm external ldap_group SMM-Department
acl group_design external ldap_group Design-Department
acl group_management external ldap_group Management
acl group_accounting external ldap_group Accounting

# Сети
acl localnet src 192.168.10.0/24
acl SSL_ports port 443
acl Safe_ports port 80 443 21 70 210 280 488 591 777 1025-65535

# Рабочее время
acl work_hours time MTWHF 09:00-18:00
acl lunch_time time MTWHF 12:00-13:00

# Категории сайтов (подробнее — в секции SquidGuard)
acl streaming_sites dstdomain .youtube.com .googlevideo.com .ytimg.com
acl streaming_sites dstdomain .tiktok.com .musical.ly .tiktokcdn.com
acl social_media dstdomain .instagram.com .cdninstagram.com
acl social_media dstdomain .vk.com .vk.me .userapi.com
acl social_media dstdomain .facebook.com .fbcdn.net
acl business_critical dstdomain .bitrix24.ru .amocrm.ru .zoom.us
acl business_critical dstdomain .googleapis.com .gstatic.com

# === SSL BUMP ===
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

sslcrtd_program /usr/lib/squid/security_file_certgen \
  -s /var/lib/squid/ssl_db -M 16MB

# === ПРАВИЛА ДОСТУПА ===
# Запрет небезопасных портов
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

# Бизнес-критичные ресурсы — без ограничений для всех
http_access allow localnet business_critical

# SMM и дизайн — полный доступ к стримингу и соцсетям
http_access allow group_smm streaming_sites
http_access allow group_smm social_media
http_access allow group_design streaming_sites
http_access allow group_design social_media

# В обед — стриминг доступен всем
http_access allow authenticated streaming_sites lunch_time
http_access allow authenticated social_media lunch_time

# В рабочее время — стриминг ограничен для остальных
http_access deny streaming_sites work_hours

# Аутентифицированные пользователи — всё остальное
http_access allow authenticated

# Запрет всего остального
http_access deny all

Генерация SSL-сертификата для HTTPS-инспекции

Чтобы фильтровать HTTPS-трафик, Squid делает SSL Bump — перехватывает TLS-соединения и подменяет сертификаты. Без этого вы видите только IP-адреса, а не реальные сайты. Соответственно, корневой CA-сертификат нужно разложить на все рабочие станции:

# Создаём директорию для сертификатов
sudo mkdir -p /etc/squid/ssl
cd /etc/squid/ssl

# Генерируем корневой CA-сертификат (срок 10 лет)
sudo openssl req -new -newkey rsa:4096 -sha256 -days 3650 \
  -nodes -x509 \
  -keyout squid-ca.pem \
  -out squid-ca.pem \
  -subj "/C=RU/ST=SPb/L=Saint-Petersburg/O=BrightMedia/CN=BrightMedia Proxy CA"

# Экспортируем сертификат в формате DER для Windows-клиентов
sudo openssl x509 -in squid-ca.pem -outform DER -out squid-ca.der

# Инициализируем базу SSL-сертификатов
sudo /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 16MB
sudo chown -R proxy:proxy /var/lib/squid/ssl_db

# Распространяем сертификат через GPO Active Directory
# Файл squid-ca.der загружается в:
# Computer Configuration → Policies → Windows Settings →
# Security Settings → Public Key Policies → Trusted Root CAs

Для Linux-клиентов (у дизайнеров были рабочие станции на Ubuntu):

sudo cp squid-ca.pem /usr/local/share/ca-certificates/squid-ca.crt
sudo update-ca-certificates

LDAP-аутентификация через Active Directory

В BrightMedia весь офис работал в доменной среде Windows. Мы подключили аутентификацию Squid через Active Directory — люди заходили под своими доменными учётками, никаких дополнительных паролей вводить не нужно.

Создание сервисной учётной записи

В Active Directory завели отдельную учётку с минимальными правами — только для чтения, ничего лишнего:

# PowerShell на контроллере домена DC01
New-ADUser -Name "squid-bind" `
  -SamAccountName "squid-bind" `
  -UserPrincipalName "squid-bind@brightmedia.local" `
  -Path "OU=Service Accounts,DC=brightmedia,DC=local" `
  -AccountPassword (ConvertTo-SecureString "S3cure!Pr0xy#2025" -AsPlainText -Force) `
  -Enabled $true `
  -PasswordNeverExpires $true `
  -CannotChangePassword $true `
  -Description "Service account for Squid proxy LDAP authentication"

Создание групп для политик доступа

# Создаём группы в AD для управления доступом
$groups = @(
  "SMM-Department",
  "Design-Department",
  "Management",
  "Accounting",
  "Proxy-FullAccess",
  "Proxy-Restricted"
)

foreach ($group in $groups) {
  New-ADGroup -Name $group `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Groups,DC=brightmedia,DC=local" `
    -Description "Squid proxy access group: $group"
}

# Добавляем пользователей в группы
# (пример для SMM-отдела)
Get-ADUser -Filter {Department -eq "SMM"} | ForEach-Object {
  Add-ADGroupMember -Identity "SMM-Department" -Members $_
}

Тестирование LDAP-аутентификации

# Тестируем basic_ldap_auth вручную
# Формат ввода: username password
echo "ivanov.a P@ssw0rd" | /usr/lib/squid/basic_ldap_auth \
  -v 3 -R -b "DC=brightmedia,DC=local" \
  -D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
  -w "S3cure!Pr0xy#2025" \
  -f "(&(sAMAccountName=%s)(objectClass=person))" \
  -h dc01.brightmedia.local
# Ожидаемый ответ: OK

# Тестируем проверку группы
echo "ivanov.a SMM-Department" | /usr/lib/squid/ext_ldap_group_acl \
  -v 3 -R -b "DC=brightmedia,DC=local" \
  -D "CN=squid-bind,OU=Service Accounts,DC=brightmedia,DC=local" \
  -w "S3cure!Pr0xy#2025" \
  -f "(&(sAMAccountName=%u)(memberOf=CN=%g,OU=Groups,DC=brightmedia,DC=local))" \
  -h dc01.brightmedia.local
# Ожидаемый ответ: OK (если пользователь в группе)

Ограничение полосы пропускания: delay pools

Полная блокировка стриминга в рекламном агентстве — это нереально. Поэтому мы пошли другим путём: delay pools в Squid дают «мягкое» ограничение скорости именно для потокового видео, не трогая всё остальное.

Конфигурация delay pools

# Добавляем в squid.conf

# === DELAY POOLS (ограничение скорости) ===

# Pool 1: стриминговый трафик для обычных сотрудников
# Class 2: общий лимит + per-host лимит
delay_pools 2

# Pool 1: YouTube/TikTok для не-SMM/не-дизайнеров
delay_class 1 2
# Aggregate: 10 Мбит/с на весь пул, per-host: 2 Мбит/с
delay_parameters 1 1250000/2500000 250000/500000
delay_access 1 deny group_smm
delay_access 1 deny group_design
delay_access 1 allow streaming_sites
delay_access 1 deny all

# Pool 2: общий лимит для соцсетей (кроме SMM)
delay_class 2 2
# Aggregate: 20 Мбит/с, per-host: 5 Мбит/с
delay_parameters 2 2500000/5000000 625000/1250000
delay_access 2 deny group_smm
delay_access 2 deny group_design
delay_access 2 allow social_media
delay_access 2 deny all

Параметры delay_parameters задаются в байтах/сек в формате restore/maximum. Расшифровываю:

  • Пул 1: общий лимит стриминга — 10 Мбит/с (1 250 000 байт/с), на одного пользователя — 2 Мбит/с. Хватает на YouTube 480p, но о 4K можно забыть
  • Пул 2: общий лимит соцсетей — 20 Мбит/с, на пользователя — 5 Мбит/с. Фото открываются нормально, массовая загрузка видео — тормозится

QoS и приоритизация бизнес-трафика на уровне iptables

Параллельно настроили приоритизацию трафика на уровне ОС — через tc и iptables:

#!/bin/bash
# /etc/squid/scripts/traffic-shaping.sh

# Интерфейс в WAN
WAN_IF="ens192"
TOTAL_BW="200mbit"

# Удаляем старые правила
tc qdisc del dev $WAN_IF root 2>/dev/null

# Создаём корневой HTB
tc qdisc add dev $WAN_IF root handle 1: htb default 30
tc class add dev $WAN_IF parent 1: classid 1:1 htb rate $TOTAL_BW

# Класс 1:10 — бизнес-критичный трафик (гарантия 100 Мбит)
tc class add dev $WAN_IF parent 1:1 classid 1:10 htb \
  rate 100mbit ceil 200mbit prio 1

# Класс 1:20 — обычный веб (гарантия 60 Мбит)
tc class add dev $WAN_IF parent 1:1 classid 1:20 htb \
  rate 60mbit ceil 180mbit prio 2

# Класс 1:30 — стриминг и соцсети (гарантия 40 Мбит, потолок 80)
tc class add dev $WAN_IF parent 1:1 classid 1:30 htb \
  rate 40mbit ceil 80mbit prio 3

# Маркировка через iptables (Squid помечает пакеты через MARK)
iptables -t mangle -A OUTPUT -m mark --mark 10 -j CLASSIFY --set-class 1:10
iptables -t mangle -A OUTPUT -m mark --mark 20 -j CLASSIFY --set-class 1:20
iptables -t mangle -A OUTPUT -m mark --mark 30 -j CLASSIFY --set-class 1:30

В конфигурацию Squid добавили маркировку пакетов:

# В squid.conf — маркировка TCP-пакетов
tcp_outgoing_mark 0x0a business_critical
tcp_outgoing_mark 0x1e streaming_sites
tcp_outgoing_mark 0x14 all

SquidGuard: контентная фильтрация по категориям

Для блокировки нежелательных категорий сайтов взяли SquidGuard с бесплатными базами от Shalla и Université Toulouse. Обновляются регулярно, покрывают большинство проблемных категорий.

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

# Скачиваем списки категорий
cd /var/lib/squidguard/db
sudo wget http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz
sudo tar xzf blacklists.tar.gz
sudo mv blacklists/* .
sudo rm -rf blacklists blacklists.tar.gz

# Структура:
# /var/lib/squidguard/db/
# ├── adult/
# │   ├── domains
# │   └── urls
# ├── gambling/
# ├── malware/
# ├── phishing/
# ├── warez/
# └── ...

# Конфигурация SquidGuard
sudo tee /etc/squidguard/squidGuard.conf > /dev/null << 'SQEOF'
dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

# Источники
src smm_team {
  # IP-адреса SMM-отдела (DHCP-резервации)
  ip 192.168.10.50-192.168.10.59
}

src design_team {
  ip 192.168.10.60-192.168.10.74
}

src all_users {
  ip 192.168.10.0/24
}

# Категории для блокировки
dest adult {
  domainlist adult/domains
  urllist adult/urls
  log adult.log
}

dest gambling {
  domainlist gambling/domains
  urllist gambling/urls
  log gambling.log
}

dest malware {
  domainlist malware/domains
  urllist malware/urls
  log malware.log
}

dest phishing {
  domainlist phishing/domains
  urllist phishing/urls
  log phishing.log
}

dest warez {
  domainlist warez/domains
  urllist warez/urls
  log warez.log
}

# Правила
acl {
  smm_team {
    pass !adult !malware !phishing all
  }
  design_team {
    pass !adult !malware !phishing all
  }
  all_users {
    pass !adult !gambling !malware !phishing !warez all
  }
  default {
    pass none
    redirect http://proxy.brightmedia.local/blocked.html?url=%u&category=%t
  }
}
SQEOF

# Компилируем базы данных
sudo squidGuard -C all
sudo chown -R proxy:proxy /var/lib/squidguard/db

Интеграция SquidGuard в Squid

# Добавляем в squid.conf
url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 10 startup=3 idle=3 concurrency=0

# Автоматическое обновление списков (cron)
sudo tee /etc/cron.weekly/update-squidguard << 'EOF'
#!/bin/bash
cd /var/lib/squidguard/db
wget -q http://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz
tar xzf blacklists.tar.gz
mv blacklists/* . && rm -rf blacklists blacklists.tar.gz
squidGuard -C all
chown -R proxy:proxy /var/lib/squidguard/db
squid -k reconfigure
logger "SquidGuard blacklists updated"
EOF
sudo chmod +x /etc/cron.weekly/update-squidguard

Страница блокировки

Страницу блокировки сделали нормальной — не пустой экран с ошибкой, а внятное объяснение, почему сайт недоступен. Хостится на внутреннем веб-сервере:

# /var/www/proxy/blocked.html (на Apache локальном)
<!DOCTYPE html>
<html lang="ru">
<head>
  <meta charset="UTF-8">
  <title>Доступ ограничен — BrightMedia</title>
  <style>
    body { font-family: Arial, sans-serif; text-align: center; padding: 50px; }
    .block-box { max-width: 600px; margin: 0 auto; padding: 30px;
                 border: 2px solid #e74c3c; border-radius: 10px; }
    h1 { color: #e74c3c; }
    .category { color: #666; font-style: italic; }
    .contact { margin-top: 20px; color: #333; }
  </style>
</head>
<body>
  <div class="block-box">
    <h1>Доступ к ресурсу ограничен</h1>
    <p>Запрошенный URL заблокирован корпоративной политикой.</p>
    <p class="category">Категория: <span id="cat"></span></p>
    <p class="contact">Если вы считаете, что ресурс заблокирован ошибочно,
       обратитесь в IT-отдел: it@brightmedia.ru</p>
  </div>
  <script>
    const params = new URLSearchParams(window.location.search);
    document.getElementById('cat').textContent = params.get('category') || 'неизвестна';
  </script>
</body>
</html>

Отчётность: SARG и LightSquid

Контроль без отчётности — это иллюзия контроля. Настроили две системы: одну для руководства, другую для технического мониторинга.

SARG: детальные HTML-отчёты

# Конфигурация SARG
sudo tee /etc/sarg/sarg.conf > /dev/null << 'SQEOF'
access_log /var/log/squid/access.log
output_dir /var/www/sarg-reports
resolve_ip yes
user_ip no
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
date_format e
overwrite_report yes
charset UTF-8
show_successful_message no
topuser_num 20
exclude_hosts 192.168.10.1
lastlog 30
SQEOF

# Генерация отчёта за сегодня
sudo sarg -x

# Ежедневный cron
sudo tee /etc/cron.daily/sarg-reports << 'EOF'
#!/bin/bash
/usr/bin/sarg -x > /dev/null 2>&1
EOF
sudo chmod +x /etc/cron.daily/sarg-reports

SARG строил детальные отчёты: топ пользователей по трафику, конкретные сайты, время онлайн, заблокированные запросы. Всё это открывалось у руководства по адресу http://proxy.brightmedia.local/sarg-reports/ — без звонков в IT.

LightSquid: быстрая интерактивная аналитика

# Конфигурация LightSquid
sudo tee /etc/lightsquid/lightsquid.cfg > /dev/null << 'SQEOF'
$cfgdir  = "/etc/lightsquid";
$logpath = "/var/log/squid";
$reportpath = "/var/www/lightsquid/report";
$lang = "ru";
$ip2name = "dns";
$petefresh = 15;
$topnum = 25;
SQEOF

# Генерация отчётов
sudo /usr/share/lightsquid/lightparser.pl

# Apache виртуальный хост для отчётов
sudo tee /etc/apache2/sites-available/proxy-reports.conf > /dev/null << 'EOF'

  ServerName proxy.brightmedia.local
  DocumentRoot /var/www/proxy

  Alias /sarg-reports /var/www/sarg-reports
  Alias /lightsquid /var/www/lightsquid/report

  
    Require ip 192.168.10.0/24
    AuthType Basic
    AuthName "Proxy Reports"
    AuthUserFile /etc/apache2/.htpasswd-proxy
    Require user admin director
  

  
    Require ip 192.168.10.0/24
    Options +ExecCGI
    AddHandler cgi-script .cgi .pl
  

EOF

sudo a2ensite proxy-reports.conf
sudo a2enmod cgi
sudo systemctl reload apache2

Прозрачное проксирование и автонастройка клиентов

Чтобы не бегать по рабочим станциям с настройками, реализовали два подхода: WPAD/PAC для доменных машин и прозрачный прокси для гостевых устройств.

WPAD через DHCP и DNS

# Файл автонастройки прокси
sudo tee /var/www/proxy/wpad.dat > /dev/null << 'EOF'
function FindProxyForURL(url, host) {
  // Прямой доступ к локальным ресурсам
  if (isPlainHostName(host) ||
      shExpMatch(host, "*.brightmedia.local") ||
      isInNet(host, "192.168.0.0", "255.255.0.0") ||
      isInNet(host, "10.0.0.0", "255.0.0.0")) {
    return "DIRECT";
  }
  // Всё остальное — через прокси
  return "PROXY proxy.brightmedia.local:3128; DIRECT";
}
EOF

# DNS-запись для автообнаружения
# На DNS-сервере (DC01) добавляем A-запись:
# wpad.brightmedia.local → 192.168.10.5 (IP прокси-сервера)

# DHCP-опция 252 (на DHCP-сервере Windows):
# Set-DhcpServerv4OptionValue -OptionId 252 \
#   -Value "http://wpad.brightmedia.local/wpad.dat"

iptables redirect для прозрачного режима

# На шлюзе/маршрутизаторе или на самом прокси-сервере
# Перенаправляем HTTP/HTTPS трафик на Squid

# Включаем IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

# Redirect HTTP → Squid intercept port
iptables -t nat -A PREROUTING -i ens224 \
  -p tcp --dport 80 \
  -j REDIRECT --to-port 3129

# Redirect HTTPS → Squid SSL bump port
iptables -t nat -A PREROUTING -i ens224 \
  -p tcp --dport 443 \
  -j REDIRECT --to-port 3130

# Исключаем трафик от самого прокси-сервера
iptables -t nat -A OUTPUT -m owner --uid-owner proxy \
  -p tcp --dport 80 -j RETURN
iptables -t nat -A OUTPUT -m owner --uid-owner proxy \
  -p tcp --dport 443 -j RETURN

# Сохраняем правила
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

Результаты внедрения

Уложились в 5 рабочих дней. Через месяц эксплуатации посмотрели на цифры — результат оказался лучше, чем рассчитывали:

  • Рабочий трафик вырос с 28% до 71% от общего объёма — канал наконец освободился для бизнес-задач
  • Видеоконференции перестали обрываться — jitter упал с 45 мс до 8 мс после настройки QoS. Переговоры с клиентами наконец-то шли без «квадратиков» на экране
  • Загрузка макетов ускорилась втрое. CRM и облачные хранилища получили приоритет по полосе — дизайнеры перестали жаловаться на «вечно крутящийся спиннер»
  • Ноль жалоб от SMM и дизайнеров — мы намеренно не трогали их рабочий трафик, и это решение себя оправдало
  • Экономия вышла существенная — сервер обошёлся в 45 000 ₽ против 350 000 ₽ за железный UTM типа FortiGate или Check Point. Функционал при этом закрыл все задачи клиента
  • 3 инцидента ИБ предотвращены — SquidGuard заблокировал переходы на фишинговые сайты ещё до того, как пользователи успели что-то ввести

Руководство получило еженедельные отчёты по интернет-активности и смогло принимать реальные кадровые решения, опираясь на цифры, а не на ощущения. Сотрудники, кстати, восприняли систему спокойно — особенно когда узнали про «обеденный час свободы»: с 13:00 до 14:00 YouTube и соцсети открывались без ограничений.

«Наконец-то Zoom не лагает, а я вижу, куда уходит трафик. И главное — никто не жалуется!» — директор BrightMedia.

После запуска мы не бросили проект. Специалисты АйТи Фреш ведут систему на абонентском обслуживании: еженедельно обновляем списки блокировки, добавляем новые правила под изменившиеся задачи бизнеса, отслеживаем аномалии в трафике — иногда именно там первыми всплывают проблемы.

Часто задаваемые вопросы

Да, но с оговорками. Без SSL Bump Squid видит только доменное имя через SNI — конкретный URL внутри HTTPS-сессии остаётся закрытым. Заблокировать youtube.com целиком — легко. Разрешить только конкретный канал, запретив остальные — уже нет. Для большинства офисных задач блокировки по домену вполне хватает, и мы чаще всего идём именно этим путём.

При грамотной настройке влияние на скорость минимально — Squid добавляет 1–3 мс задержки на запрос, это незаметно. Более того, кэширование статики (CSS, JS, картинки) ускоряет повторные загрузки на 20–40%. В нашем кейсе пользователи субъективно почувствовали, что интернет стал быстрее — просто потому что стриминг перестал съедать канал.

Только если включён SSL Bump для инспекции HTTPS-трафика. В доменной среде Windows сертификат разъезжается по машинам через GPO автоматически — руками ничего устанавливать не надо. Если SSL Bump не используется, никакого сертификата не нужно, но фильтрация HTTPS будет работать исключительно по домену через SNI.

Мы настроили автообновление через cron — раз в неделю, в нерабочее время. Списки Université Toulouse бесплатные, регулярно пополняются и содержат миллионы доменов, разбитых по категориям. Плюс администратор в любой момент может вручную дописать нужный домен в локальный whitelist или blacklist — это буквально одна строка в файле.

Да, Squid 5.x нормально работает с современным трафиком: TLS 1.2/1.3, HTTP/2, SNI-фильтрация, SSL Bump — всё поддерживается. Единственный нюанс: приложения с certificate pinning (банковский софт и некоторые корпоративные клиенты) через SSL Bump не ходят. Для них настраиваем исключения через ssl_bump splice — и проблема снята.

Нужна помощь с настройкой?

Если хотите разобраться с настройкой Squid под свою инфраструктуру — обращайтесь. Специалисты АйТи Фреш занимаются этим больше 15 лет, знаем типовые грабли и нетипичные случаи. Абонентское обслуживание от 15 000 ₽/мес.

📞 Связаться с нами
#Squid прокси-сервер#настройка Squid#контроль интернета в офисе#фильтрация трафика Squid#HTTPS прокси Squid#ACL Squid настройка#Squid LDAP аутентификация#ограничение скорости интернета