Прозрачный прокси-сервер OOPS

  Коротенький рассказ на тему : "Прозрачный прокси за 15 минут".

Описываеться самый минимум которого достаточно чтобы создать прозрачный прокси-сервер на базе OOPS



Ставим это чудо


cd /usr/ports/www/oops
make install clean

При установке я выбирал следующие параметры


GIGABASE
PCRE

Собираем ядро с опциями


options         IPFIREWALL
options         IPFIREWALL_FORWARD
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=100
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPDIVERT

В фаервол(IPFW) добавляем правило до диверта


fwd 127.0.0.1,3128 tcp from 192.168.25.0/24 to any dst-port 80 via rl1

выкладывать не буду, опишу лишь то что нужно раскоментировать ,поправить,

кому будет интересно покапаетесь в конфах сами там на мой взгляд ясности

больше чем в сквиде -) но спорить не буду -) ...

правим oops.cfg

Для работы OOPS в прозрачном режиме необходимо иметь такие строки


group mynet {
              ...
redir_mods transparent ;
             ....
}

module transparent {
	myport 3128
	}

storage {
        path /usr/local/oops/storages/oops_storage ;
#       Задаём путь где находиться файл-хранилище
#       кэша, и его размер, в данном случае 900Мб
        size 900m ;
}

Также можно добавить модуль redir (перенаправление, блокирование сайтов)

тоесть

redir_mods transparent redir;

Правим файл /usr/local/etc/oops/redir_rules

в формате

#какой сайт   -> куда перенаправить
http://porno.ru   http://google.com
#Вместо porno.ru открывать Гугл
#Если просто вводить список сайтов то будет выводиться сообщение 
#о запрете на доступ к ресурсу из файла 
#/usr/local/etc/oops/redir_template.html
gumno.com
kal.com

Последние лёгкие штрихи


echo oops_enable="YES" >> /etc/rc.conf

Перед первым запуском необходимо создать 

"хранилище"

oops -z -c /usr/local/etc/oops/oops.cfg

Будет создан файл-хранилище, где будет весь кэш

размер которого указан в файле-конфиге

Запускаем

 
/usr/local/etc/rc.d/oops.sh start

Смотрим, проверяем


ps -ax | grep oops
17393  p0  S      0:10,38 /usr/local/sbin/oops -c /usr/local/etc/oops/oops.cfg
sockstat -4 | grep oops
oops     oops       17393 28 tcp4   *:3128                *:*
oops     oops       17393 29 udp4   *:3130                *:*
oops     oops       17393 30 tcp4   195.190.105.242:80    192.168.25.13:16667
oops     oops       17393 31 tcp4   211.111.111.11:55827  195.190.105.240:80

ну и конечно же смотрим в логи, пошел ли траф через OOPS


/var/log/oops/access.log

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

Офф. сайт программы: http://oops-cache.org/

размещено: 2008-02-14,

				последнее обновление: 2008-02-16,

				автор: Morty

artem, 2008-02-14 в 18:06:04

быстрый и неприхотливый прокси. как и сквид режет трафик и контент. спасибо давно хотел его перевести в прозрачный режим

Alexander Sheiko, 2008-02-14 в 19:32:39

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

lisergey, 2008-02-14 в 20:59:14

что-то я сомневаюсь, что у оопса с производительностью вытягивания объектов из кеша, который организован боольшим файлом в неск гигов, будет сильно лучше по сравнению со сквидом, даже с учетом тредов. у нашего прова стоял оопс, который часто создавал проблемы, выдавая старый контент динамических страниц, изза чего мне с провом приходилось периодически бодаться. забавно было видеть экранчик с текстом "ооps не могу отобразить страницу www...." а значение английского "oops!" переводили на русский матерный разъяренные пользователи. :(

Alexander Sheiko, 2008-02-14 в 21:31:02

Я как то общался с админами tank.kiev.sovam.com = proxy.svitonline.com. Там стоит P-III 800 и тянет до ~100 запросов / сек. Squid тянет до ~30-40 на том же железе, потом - дохнет. Хранилище там организовано в виже raw и работает оно куда быстрее файловой системы. В сквиде есть нечто подобное - COSS, но с ограничением на размер файла в 1 Мб. Проблема в другом - OOPS несколько глючный, а разработчик давно на отладку забил :(.

lisergey, 2008-02-14 в 22:58:15

у нас в сети Ростовского Гос Университета (сеть 195.208.240.0/20) как раз стоял сквид на пень-3 и он вполне тянул нагрузку порядка сотни запросов в секунду а то и больше. имхо у ребят боттлнек был в чемто другом, например вываливание памяти сквида в своп, или неоптимизированные параметры сквидового кеша. так, если под кеш отводится много места, счет на десятки-сотни ГБ, то можно стандартные настройки сквида (рассчитанные на 100 мегабайт кеша) cache_dir ufs /usr/local/squid/cache 100 16 256 оптимизировать например так cache_dir ufs /usr/local/squid/cache 64000 64 1024 еще хорошо в ядре включать опцию options UFS_DIRHASH # Improve performance on big directories и конечно же, лучше размешать кеш сквида в отдельном разделе с опцией noatime если планируется серьзная на него нагрузка, чем в /usr Фликры, например, пользуют Сквида (Архитектура Flickr/) а сколько там одновременных запросов в секунду у Фликра?? ;)

lisergey, 2008-02-15 в 10:37:00

так как по сквиду статьи разрозненные, и нету посвященной ему самому (а надо бы уже), а не в связках с чемнить, то пишу сюда (да простят меня любители OOPSa): В релизе Сквида 3.0 (http://www.squid-cache.org/Versions/v3/3.0/RELEASENOTES.html) появилась опция accept_filter The name of an accept(2) filter to install on Squid's listen socket(s). This feature is perhaps specific to FreeBSD and requires support in the kernel. The 'httpready' filter delays delivering new connections to Squid until a full HTTP request has been received. See the accf_http(9) man page. то есть на машинах, через сетевую подсистему которых проходит большое количество HTTP-запросов, к сайту или теперь к сквиду, ядро берет на себя часть работы по получению всех необходимых данных из HTTP-сессии и только получив в сокет полноценный HTTP-запрос, передает его залпом приложению. это должно существенно экономить ресурсы системы и повышать производительность, а также повышать устойчивость к DoS-атакам. насчет же самого accf_http модуля - он появился неск лет назад и за это время его уже протестили и "вылизали", так что доверять ему можно.

anon, 2008-07-02 в 19:17:53

gumno.com kal.com зачёт )))