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

Меня зовут Саша Скоков, я блогер, инженер группы сопровождения системной инфраструктуры в ОККО и в этой статье разберу, как работает Squid в проде.

Что такое Squid и зачем нужен прокси

Представьте, есть серверы, сервисы и внутренние контуры, которым нужен доступ к внешнему миру. Это может быть документация, публичные API, чаты, репозитории пакетов, внешние SaaS-сервисы или обновления. Давать всем прямой выход в интернет неудобно и небезопасно. Проще поставить между внутренней сетью и внешними ресурсами управляемый прокси.

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

Squid получает запрос от клиента, применяет правила и передаёт запрос дальше. Сила Squid в том, что правила можно описывать довольно гибко: по IP-адресам, доменам, портам, методам, URL, внешним ACL-проверкам и другим признакам. Для инфраструктурных задач этого часто достаточно: например, разрешить серверам ходить только к нужным доменам, закрыть всё лишнее и оставить журнал действий.

Стартовая конфигурация

Стартовая конфигурация выглядит просто:

Минимальный squid.conf тоже помещается в несколько строк:

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

Файл /etc/squid/allowed_domains.txt может содержать домены по одному на строку:

.example.com

.docs.example.org

api.vendor.com

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

Правила доступа

В обычном режиме прокси не читает содержимое защищенного соединения. Клиент просит установить туннель к внешнему серверу через CONNECT, а Squid передает трафик дальше как TCP-посредник. Это уже полезно: можно контролировать факт обращения к домену и порту, но нельзя видеть содержимое HTTP-запросов внутри TLS.

Для расшифровки есть SSL Bump. В этом режиме Squid фактически работает как контролируемый посредник между клиентом и внешним сайтом: принимает соединение от клиента, устанавливает соединение к целевому серверу, выпускает для клиента подменный сертификат и получает возможность анализировать HTTPS-запросы. Клиенты должны доверять корпоративному корневому сертификату. Без этого браузеры, CLI-утилиты и SDK будут ругаться на сертификаты.

В свежей документации Squid есть еще один нюанс: директива ssl_bump указана для версий 5–7, а для будущей ветки v8 отмечено отсутствие этой директивы. Это нужно учитывать при выборе версии и образа. 

Журналирование событий

Логи — второй обязательный слой после правил доступа. Squid пишет access.log, где фиксируются HTTP- и ICP-транзакции. Для команды эксплуатации это база: время запроса, клиент, результат, размер ответа, метод, URL или домен. По этим данным можно искать несанкционированные обращения, отлаживать сетевые проблемы, считать нагрузку и понимать, какие внешние зависимости реально используются сервисами.

Формат логов в Squid достаточно гибкий и его можно привести, как в примере выше, в JSON формат.

Без логов прокси быстро превращается в «черный ящик». С логами он становится точкой наблюдаемости. Минимальный продакшн-набор: access.log для запросов, cache.log для состояния самого Squid, метрики по количеству запросов, кодам ответов, задержкам, ошибкам DNS, отказам ACL и состоянию родительских прокси.

Для оперативного контроля есть Cache Manager. В новых версиях часть старых инструментов изменилась: например, squidclient больше не распространяется вместе с Squid 7, а отчёты Cache Manager можно получать по HTTP через браузер или curl. 

Мониторинг

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

Наиболее интересные для нас метрики — это коды ответов promhttp_metric_handler_requests_total. В идеале все ответы должны идти со значением 200. Если же у нас увеличивается поток ответов с кодами 500 или 503, то нужно обратить на это внимание и проводить диагностику. Аналогично нужно проводить диагностику в случае большого спада ответов со значением 200.

Масштабирование и каскадирование

Масштабирование Squid обычно начинается не с Kubernetes, а с архитектуры потока. Один прокси можно поставить как шлюз для контура. Несколько прокси можно разнести по зонам, проектам или дата-центрам. Для каскада используется cache_peer: Squid может ходить к родительскому прокси, а правила cache_peer_access позволяют точечно выбирать те типы запросов, которые нужно обрабатывать через нестандартные для окружения прокси-сервера.

Это удобно, когда нужно разделить трафик. Например, общие обновления пакетов идут через один родительский прокси, обращения к внешним API — через другой, а внутренние домены всегда отправляются напрямую. Для этого в Squid есть директивы прямой и непрямой маршрутизации, ACL и ограничения на использование peer-прокси.

Балансировка

Балансировка решается несколькими способами. Иногда хватает внешнего балансировщика перед одинаковыми Squid-инстансами. Иногда лучше явно настроить несколько родительских прокси и правила выбора. Главная идея простая: прокси-слой не должен становиться единой точкой отказа, если через него проходит критичный исходящий трафик.

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

Хорошая конфигурация прокси начинается с инвентаризации. Нужно понять, какие сервисы действительно должны ходить наружу, какие домены им нужны, какие порты используются, нужен ли перехват HTTPS, какие данные можно логировать и как долго хранить журналы. После этого Squid становится не «ещё одним сетевым сервисом», а контролируемым шлюзом.

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

Выводы

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