Такой вопрос задал один из читателей в комментариях под статьей про базовую установку ОС для сервера.
У нас есть статьи на эту тему, они хоть и довольно старые, но будут работать и сегодня, хотя в современных системах некоторые вещи можно сделать и более изящно.
Но есть одно но, большинство из них предусматривает также настройку кеширующего прокси-сервера SQUID.
На наш взгляд сегодня это абсолютно избыточно, во всяком случае для рядовых коммерческих организаций.
Большинству будет достаточно включить форвардинг пакетов в ядре и настроить SNAT или маскарадинг.
Для этого в /etc/sysctl.conf добавьте:
net.ipv4.ip_forward = 1
А в таблицу nat добавить правило:iptables -t nat -A POSTROUTING -o ens33 -s 192.168.100.0/24 -j MASQUERADE
Где ens33 - интерфейс выхода, а 192.168.100.0/24 - диапазон локальной сети.Подробнее про все это можно прочитать в нашей статье: Основы iptables для начинающих. Часть 4. Таблица nat - типовые сценарии использования
А теперь о том, что же не так со SQUID и почему он сегодня вам, скорее всего, не нужен.
Когда-то давно, когда деревья были большими, а интернет дорогим и медленным SQUID позволят решать эту проблему средством кеширования. Т.е. если у вас один пользователь посетил условный сайт, то все следующие пользователи могут не скачивать с него заново статическое содержимое, а получить его из кеша-прокси сервера.
Это позволило значительно ускорить загрузку сайтов у пользователей и снизить нагрузку на канал.
Вторая задача, которую эффективно решал SQUID - это был контроль доступа: черные и белые списки, контентный фильтр, фильтр по MIME и т.д.
Третья - контроль и отчетность, анализируя логи можно всегда было сказать кто выкачал весь трафик или на какие сайты он ушел.
Но все течет, все меняется. На смену HTTP поголовно пришел HTTPS и выяснилось, что SQUID стал практически бесполезен.
Так как каждый пользователь теперь имеет индивидуальный зашифрованный уникальным одноразовым ключом канал браузер-сайт, то кешировать стало нечего.
Да и в эпоху широкополосного интернета бывает быстрее скачать статику заново, чем искать ее в кеше, особенно если он на тарахтящем HDD.
Фильтровать тоже стало нечего. Трафик закрыт. Да мы можем вскрыть его через SSL-Bump - но это фактическая атака человек посередине и резко снижает безопасность сети.
Если просто вскрывать заголовки и фильтровать по домену назначения, то это становится чудовищно неэффективно по вычислительным затратам. И зачем заниматься расшифровкой, если все тоже самое можно сделать на уровне DNS?
Есть даже специализированные решения, мы подробно рассматривали одно из них в статье: Создаем собственный фильтрующий DNS-сервер на базе Pi-hole
Статистика потребленного трафика? А кого она сейчас волнует, сегодня может стать вопрос - кто грузит канал, но не вопрос - кто скачал сколько гигабайт.
Ну а при желании понять кто-куда лазил всегда можно снять статистику с лога DNS.
Таким образом мы не видим сегодня причин использовать прокси, все прекрасно решается и без него.
Но просто так сдавать свои позиции SQUID пока не намерен, но это уже нишевые применения. А это уже совсем другая история.
