lorem

OS-Admin

"Системное администрирование – это культура"


Продакшн-прокси на базе ArchLinux и Squid4 со вкусностями. Ч.1


Опубликовано 24th Jul 2018 15:37:36 в категории Linux

Здравствуй, дорогой друг. Итак, ты уже созрел для сабжа, но не можешь собрать в кучу то, что начитал в Интернетах? Ну так это неудивительно, ведь Интернет так и кишит либо древними статьями на тему, либо статьями, которые написаны мамкиными админами совсем некомпетентными людьми, которые всё ещё думают, что под Squid надо выделять кучу памяти, и будет "щасье". На самом деле, нет, счастья не будет, но об этом потом. А пока поговорим о том, что вообще это такое - прокси с кешированием и блекджеком со шл**** прочими радостями. Я сам довольно долго со всем этим разбирался, но таки смог (спасибо Юрию Воинову!). Скажу честно, что всего я в статье рассказать не могу, а то, что расскажу, может показаться пугающим, ужасным и вообще многабукафф неподъемным. Однако, кое какие вещи я постарался максимально упростить, создал свои пакеты на AUR с включением нужных опций (и отключением вредных опций компиляции, о которых мамкины админы в интернете умалчивают или вовсе включают их при компиляции, а потом воют, что оно не работает) и включением нужных патчей. Если ты готов получить красноглазие море удовольствия, а самое главное — результат, который будет радовать, то читай дальше.
Я решил разделить весь материал на несколько статей, чтобы было удобно читать и переваривать материал. Это будет вводная статья, чтобы было понятно, какую необходимую базу знаний необходимо будет иметь при построения нашей системы.


Введение

Что такое прокси — ты итак знаешь, да? Если нет, срочно бросай читать эту статью и марш курить матчасть, маны и приму без фильтра. Кеширующий прокси - это, собственно такой прокси, который умеет кешировать контент на основании правил. Мы будем использовать в качестве кешпрокси Squid 4.1. Squid умеет (при включенных соответствующих опциях при компиляции) кроме кеширования еще и такие вещи, как eCAP и ICAP (client). Я уже включил нужные опции компиляции (см.PKGBUILD, если надо). Также включил пару патчей, о которых подробно расскажу позже.

eCAP - это программный интерфейс, который позволяет сетевому приложению, например прокси-серверу передавать пакеты на контентный анализ и адаптировать его к загружаемому модулю адаптации. Модуль адаптации также может обмениваться метаинформацией с хост-приложением для предоставления дополнительных сведений, таких как параметры конфигурации, причины решения игнорировать сообщение или обнаруженное имя вируса. 
ICAP (Internet Content Adaptation Protocol) -это легкий HTTP-подобный протокол адаптации интернет-контента. ICAP используется для расширения прозрачных прокси-серверов, что освобождает ресурсы и стандартизирует реализацию новых функций. Он использует кэш для проксирования всех клиентских транзакций и обработки транзакций с использованием серверов ICAP, которые предназначены для определенных функций, таких как сканирование вирусов, трансляция контента, фильтрация содержимого или вставки кода. ICAP выполняет манипулирование содержимым для соответствующего HTTP-запроса клиента или ответа HTTP. Таким образом, это называется «адаптацией контента».
По существу, что eCAP, что ICAP предназначены для адаптации контента. Только у них есть множество отличий, но на мой взгляд, самое большое - это то, что ICAP-сервер многопоточный. Это очень важно, девочки и мальчики, но об этом позже. ECAP же выполняется ровно так же, как и сам Squid, то есть ничерта не многопоточно, что накладывает кое какие ограничения. Для антивирусной проверки трафика мы будем использовать ICAP модуль squidclamav. Для его работы необходим ICAP сервер. Также, squidclamav должен цепляться к антивирусу, верно? И не просто к антивирусу, а к ClamAV, который также будет установлен. Кстати, для ClamAV мы еще заинсталлим неофициальные базы. Я рекомендую вынести icap сервер с модулем squidclamav и антивирусом ClamAV на отдельный сервер, если сеть твоя состоит из большого числа машин и нужно будет анализировать на вирусы, к примеру, js скрипты. Такие вещи лучше всего выносить на отдельный полигон. Но если машина с прокси достаточно мощная, то можно ставить на ней же. А если трафик не очень большой, клиентов мало, можно попробовать рассмотреть конфигурацию с проверкой на вирусы с помощью eCAP адаптера ecap_clamav-adapter. Тесты, тесты и еще раз тесты.
Итак, немного про адаптацию контента прочитали, переварили (если нет, идем переваривать). Далее следует рассказать, наверное, про компрессию, что это и начерта оно надо. 
В нашем случае, компрессия обеспечивается eCAP адаптером ecap-gzip. Этот адаптер сжимает определенный контент, который передается от прокси к клиенту. Думаю, преимущества здесь очевидные - понижается нагрузка на нисходящий интерфейс, контент более быстро передается к клиенту с пометкой "сжато", а уже браузер в клиенте это дело декомпрессирует. Понятно, что это дает определенную доп.нагрузку на ЦП у клиентов, но эта нагрузка настолько мала, что об этом даже можно не говорить. Я не зря сказал, что сжимает он "определенный контент". Не всё можно сжать, и правила сжатия мы указываем в конфиге, чтобы не сжимать, к примеру, картинки. 
Далее, следует рассказать про кеширование. Многие скажут, мол, "Какое кеширование? 21 век на дворе!!! Анлим каналы". Да, вы правы, возьмите с полки пирожок. Есть разница в том, откуда контент доставляется — с локального сервера или по внешнему каналу? Даже дома кеширующий прокси может пригодиться, ведь не у всех суперпупер 4682376 мегабитные каналы связи, не так ли? А в организации? А в бизнес-центрах, где вообще в большинстве случаев интернет ограничен каким-нибудь 20мбит каналом на кучу организаций. Так что, прежде чем создавать высеры на хабре по поводу «нинууужнооостии» кеширующего прокси-сервера, хорошенько подумайте. Для кеширования мы будем использовать встроенные в Squid возможности. Еще необходим store-id хелпер для того, чтобы кеширование работало должным образом с динамическим контентом, но это тема для отдельного цикла статей, и будем рассмотрена позже, а пока остановимся на обычном классическом кешировании. Ах да, для того, чтобы кешировать, нам HTTP недостаточно (кто бы мог подумать?). Необходимо кешировать HTTPS, так как сейчас его пруд пруди. А чтобы кешировать HTTPS, необходимо трафик дешифровать, в связи с чем будет рассматриваться конфигурация с SSL Bump (подмена сертификата).

Кроме того, для качественного доступа в Интернет нам понадобится tor. Он нужен для того, чтобы получать доступ к тем ресурсам, которые по причине блокировки отказываются работать. Я не призываю заходить на те ресурсы, которые по праву заблокированы (например, пропаганда наркоты или насилия), речь идет о тех ресурсах, которые попадают «под раздачу» (вспомним Телеграм, который работает по сей день, зато куча добропорядочных ресурсов, которые к нему вообще отношения не имеют, оказываются заблокированными). Я про это писал довольно подробно в своей статье. А для полной красоты нам необходимо иметь в своей локалке качественный, быстрый и кеширующий DNS сервер с DNSCrypt, про который я тоже писал в одной из своих статей.

Итак, введение получилось долгим. Пора уже браться за дело! Что нам понадобится для всего хозяйства:

  1. ArchLinux
  2. Squid4.1 (AUR)
  3. GZIP and DEFLATE Compressor (AUR)
  4. C-ICAP server (AUR)
  5. SquidClamav (AUR)
  6. ClamAV
  7. DNSCrypt (dnscrypt-proxy)
  8. Unbound
  9. Tor
  10. Privoxy
  11. Прямые руки
  12. Много кофе, печенек
  13. Бутеры с сосисками.

Продолжение следует...


Поделиться:


Теги
Comments System WIDGET PACK

Поддержите блог!