понедельник, 19 ноября 2012 г.

Squid: Как не допустить превращения прокси в публичный


Дело в следующем. Катастрофическое снижение входной планки в IT приводит к тому, что ламаки заполонили все доступное пространство и не знают даже таких очевидных вещей.

Побуду и я Капитаном Очевидность. :) Как говорится, покапитаню. :)

 Задача ограничения доступа извне к локальному сквиду средствами сквида 2 не решается, к сожалению. Дело в том, что прозрачный прокси (в особенности в отсутствие аутентификации) в простых инфраструктурах действительно доступен извне при малейших огрехах в конфигурации роутера.

Итак, проблема в том, что Squid 2 слушает адрес 0.0.0.0 и в большинстве случаев его собственными средствами ограничить доступ к порту 3128 не получится.

Что ж, мы в любом случае имеем дело с транспарентным прокси и у нас в распоряжении имеется файрвол (Solaris 10, Ipfilter). 

Сделаем это:

root @ ktulhu / # cat /etc/ipf/ipnat.conf 
rdr bge0 0.0.0.0/0 port 80 -> 0/32 port 3128 

root @ ktulhu / # cat /etc/ipf/ipf.conf
# Transparent proxy host 
# Host with one interface: 
# bge0 - internal (ktulhu) 
# Rules by Y.Voinov (C) 2007,2012 

# Block rules for RPC (open firewall) 

block return-rst in quick from any to any port=111 
block return-rst in quick from any to any port=6112 

# Restrict access to proxy only from localnet 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=3128 flags S keep state keep frag 
# Restrict access to local Apache ports from LAN only 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=8080 flags S keep state keep frag 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=8088 flags S keep state keep frag

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

Вот и все. Конфигурация проста и эффективна. Сервисы со стороны открытых портов не запущены либо минимизированы.

пятница, 16 ноября 2012 г.

Бардак автоматизировать нельзя

... потому что получается автоматизированный бардак.

Не знаю, как вы - а меня дико забавляют биллборды "Бегай по клавиатуре, а не по кабинетам".

Да-да, я о всевозможных попытках устроить коммунизмэлектронное правительство в одной, отдельно взятой, стране.

Хорошо известной профессионалам от IT фразе, вынесенной в заголовок, на моей памяти лет этак 20 как исполнилось. И за это время ничего не изменилось.

Вы знаете, мальчики и девочки, слово "автоматизация" не является синонимом к слову "оптимизация". Никогда.

Судите сами.

Во-первых, для беготни по клавиатуре вам-таки придется оторвать задницу от кресла, и с документом, удостоверяющим личность, стаскать свою задницу за получением ЭЦП. Заплатив за это, разумеется, энную сумму.

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

Во-вторых, наши удостоверяющие центры, кроме того, что они являются дебилоидами и, вместо тупого следования мировому стандарту (коей называется X.509v3) изобрели свою собственную плохо совместимую поделку на основе криптографии ГОСТ, еще и могут в любой момент тупо отозвать CA - что вообще является нонсенсом - и инвалидировать разом все дерево подписанных им ЭЦП. Что уже имело место быть в нашей практике.

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

Но это все еще семечки.

Отдельная голубая печаль - сами бюрократические процессы, которые подобным образом пытаются облегчить.

Ситуация лично мне глубоко непонятна. Вместо того, чтобы сейчас, да-да, в XXI веке, тупо УПРАЗДНИТЬ многие архаизмы, бюрократизмы и кретинизмы времен развитого социализма - благо, автоматизация это вполне позволяет технически, вы же, болваны, нас всех заставили получить ИНН! - эти самые бюрократизмы просто автоматизировали (причем еще и не лучшим и непрофессиональным образом).

Скажите мне, глупому - кому нужна в XXI веке прописка? Кому нужна регистрация по месту жительства? Разве Столыпин не отменил крепостное право сто с лишним лет назад?

Характерный пример - ЦОНы. Да, вы собрали в одном флаконе большинство бюрократических процедур. И даже где-то что-то автоматизировали. Однако сами низовые процедуры и процессы ТАК И ОСТАЛИСЬ НЕИЗМЕННЫМИ.

А фактически все потуги соорудить некий eGovernment весьма напоминают интернет-магазины-а-ля-рюс: вы, конечно, заказ сделаете по интернету, но притащит вам товар все тот же курьер и расчет будет наликом на месте.

Ну и какой в этом практический смысл?

Я вижу (теоретически и утопически) eGovernment как систему, имеющую в основе МИНИМУМ бюрократии, и, к тому же, позволяющую мне В ПРИНЦИПЕ ИЗБЕЖАТЬ ЛЮБОГО ЛИЧНОГО ОБЩЕНИЯ с ненавистными мне государственными структурами на всю мою жизнь. Исключая два случая, когда я лично не могу взаимодействовать с ними - при рождении и при смерти. И ВСЕ!

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

И мы как-бы верим.

PS. А все сделанные попытки сильно напоминают те самые попытки автоматизировать бардак, и, мало того, весьма смахивают на очень сомнительные подачки с барского плеча, которые непонятно для кого и зачем делаются. Вот как примерно сейчас в России - да, мы отменяем доверенности на управление автомобилем - якобы отменяем! - но для самых ключевых моментов она ВСЕ РАВНО НУЖНА. Шаг вперед - три шага назад. XXI век. Нет, ребята. "Отменяем" - это означает - раз! - и больше нигде и никогда не требуется и не применяется! Электронное правительство - это значит - раз! - и я больше никогда не узнаю, как выглядит государственный чиновник! Смекаете?

четверг, 15 ноября 2012 г.

Блокируем Хамачи

UPDATED
Когда имеете дело с продвинутыми пользователями, то и дело норовящими попробовать ваш контроль доступа на прочность, не следует забывать о Хамачи. Почему-то продвинутые порнографынекоторые пользователи считают, что они умнее системных и сетевых администраторов. Что ж, самое время их в этом разубедить.

Маленькое лирическое отступление. Я бы, возможно, даже не вспомнил о Хамачи, если бы мне не напомнил один мой закоренелый пользователь. В его логах сверкнула скачка клиента Хамачи. Ну и привлекла внимание, разумеется. Так как он не раз уже попадался на CPзапрещенном в нашем шалмане контенте, он, разумеется, просматривается чаще остальных.

Что ж, он сам напросился. Небольшое исследование вопроса привело к тому, что можно перекрыть адресный диапазон Хамачи средствами роутера, а также закрыть основные сервера сервиса. Разумеется, можно было бы средствами прокси просто по регулярному выражению запереть все урлы, содержащие ключевое слово, однако это недостаточно эффективно и, главное, бесполезно, когда клиент уже проскочил в сеть (разумеется, его можно и на флешке притащить, следовательно блокировать надо на уровне доступа к сервису, как Tor).

Ничего, что мы сетку /8 блокируем? ;) Don't panic. Ничего существенного не задавим.

Итак, вперед (на циске):


ip access-list extended NAT
 deny ip 192.168.0.0 0.0.255.255 host 64.34.106.33 
 deny ip 192.168.0.0 0.0.255.255 host 64.34.106.7 
 deny ip 192.168.0.0 0.0.255.255 host 69.25.21.195 
 deny ip 192.168.0.0 0.0.255.255 host 74.201.75.195 
 permit ip 192.168.0.0 0.0.255.255 any ip 

access-list extended WAN_IN 
 deny ip 25.0.0.0 0.255.255.255 any 
 deny tcp any any eq telnet
 deny tcp any any eq smtp
 deny tcp any any eq domain
 deny tcp any any eq www
 deny tcp any any eq 443
 permit ip any any
!

Да, можно было, конечно, накидать тривиальных access list, но, поскольку в нашей инфраструктуре используется двойной NAT, так изящней.

В качестве просто подстраховки, дабы неповадно было, добавим acl в прокси от отрежем всякие упоминания о сабже от слишком продвинутых:

# Hamachi 
acl hamachi urlpath_regex -i Hamachi

...

# Deny access to Hamachi 
http_access deny hamachi
 
Вот и все. Спи спокойно, дорогой друг. Всех серверов Хамачи это не закроет, однако большинство точек входа перекрыты.

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

среда, 14 ноября 2012 г.

Ваш Squid может работать быстрее

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

Позволю себе не согласиться с этим доводом. 

Возможно, при соединениях вида "Интернет дома в одно лицо" (хотя это тоже спорно), это и так. Однако изобилие какого-либо ресурса отнюдь не означает, что надо швыряться этим ресурсом направо и налево. Кроме того, всегда предпочтительно и даже желательно иметь запас ресурса, чем не иметь оного.

Поясню свою позицию. Допустим, у вас в наличии локальная сеть. Из 10-100-1000-или более станций. С одной точкой доступа в интернет, скоростью, допустим, 1 Гбит (хотя это канал, скорее, провайдерского уровня. Но допустим). В локальной сети у вас 6я кабельная категория и сетевая активка 1 Гбит. Как вы думаете, какой процент одинаковых интернет-запросов у пользователей подобной сети - это раз, и два - насколько велик сейчас в относительном исчислении интернет-контент по отношению, скажем, к 1996му году?

Считать не надо. Просто прикиньте - ваши 1000 пользователей в 9 утра одновременно, придя на работу, ломятся в социалки. 1000 гигабит вливаются в канал 1 Гбит внешнего доступа. Как вы считаете, они вот так вот, без тормозов, попадут туда? Это помимо того факта, что фактически будут качаться 1000 копий одного и того же контента.

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

Как?

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

Приблизительно шестигодичный опыт поддержки разнообразных прокси на основе Squid позволил выработать некоторые общие и частные подходы к построению и конфигурированию серверов с минимальной возможной латентностью (оставим пока за кадром вопросы фильтрации контента и его антивирусных проверок на лету посредством ClamAV).

Давайте попробуем обобщить эти подходы.

Выбор оборудования

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

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

Второе. Диски важно иметь серверного класса - для надежности (мы говорим об интенсивной круглосуточной работе), и, вне зависимости от используемой платформы, собранными в зеркало - как по соображениям высокой отказоустойчивости, так и по соображениям скорости. 

Важно - про RAID, кроме 10, забудьте.

Третье. Операционная система может быть любой, при условии, что это не Windows.

По моему опыту, сервер 1RU с 4 процессорами/ядрами и 4 Гб памяти, 1-2 сетевыми интерфейсами 1 Гбит, с парой дисков, подключенных к двум контроллерам ввода-вывода (то есть способными работать одновременно) вполне удовлетворителен в качестве кэширующего прокси для сети до 1000 рабочих станций без сколько-нибудь выраженной перегрузки. Если мы говорим о Squid.

Настройки OS

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

Но вернемся к производительности. Минимизация ОС имеет не очевидное следствие - вы освобождаете оперативную память от ненужных сервисов и служб для кэширования. По тем же соображениям нежелательно держать на сервере кэша какие-либо не относящиеся к нему сервисы, особенно тяжеловесные - типа VPN, почты итп. И, тем более, запихивать его в облачные инфраструктуры. Помните? Мы говорим о латентности.

Всегда помните о законах сохранения! - они действуют в IT! Процессы выполняются не на Великом Небесном Сервере, а здесь и сейчас - на ЭТОМ процессоре, размещаются в ЭТОЙ оперативной памяти, обращаются к ЭТОМУ диску.

Из настроек ОС, критичных с точки зрения нашей цели, следует подчеркнуть минимизацию кэширования файловой системы. Мы собираемся использовать кэширующий софт, в данном случае двойное кэширование увеличивает латентность (а не уменьшает ее, как может показаться) и увеличивает накладные расходы на дисковые обмены. Разумеется, мы не говорим о прямом монтировании без кэширования вообще, но необходимо помнить, что, вообще говоря, следует учитывать специфику кэширования выбранной платформы и избегать чрезмерного раздувания кэшей файловой системы ОС.

Следует также позаботиться о достаточном количестве файловых дескрипторов для пользователя, от которого мы намерены исполнять наш прокси-сервер. В противном случае мы получим узкое место, созданное собственными руками. А также об адекватных настройках IPC, если таковые имеются в наличии на выбранной платформе. Конкретно - нас интересует достаточная степень параллелизма процессов на нашем сервере. Если допустимо использовать термин из РСУБД в такой области.

Конкретный пример в случае Solaris 10.

Параметры /etc/system:

set zfs:zfs_arc_max=1073741824 
set zfs:zfs_immediate_write_sz=1000000000 
set zfs:zvol_immediate_write_sz=1000000000 

set maxphys=1048576 

set rlim_fd_max=65536 
set rlim_fd_cur=4096 
set pidmax=65536 set 
max_nprocs=65536 
set maxuprc=32767

Обратите внимание на ограничение размеров ARC (Да, мы используем ZFS). Что касается параметров собственно ZFS для кэша, то они следующие:

root @ ktulhu / # zfs get all data/cache
NAME        PROPERTY              VALUE                  SOURCE
data/cache  type                  filesystem             -
data/cache  creation              Thu Aug 18 14:29 2011  -
data/cache  used                  22.5G                  -
data/cache  available             77.5G                  -
data/cache  referenced            37K                    -
data/cache  compressratio         1.00x                  -
data/cache  mounted               yes                    -
data/cache  quota                 100G                   local
data/cache  reservation           none                   default
data/cache  recordsize            4K                     local
data/cache  mountpoint            /data/cache            default
data/cache  sharenfs              off                    default
data/cache  checksum              on                     default
data/cache  compression           off                    default
data/cache  atime                 off                    inherited from data
data/cache  devices               on                     default
data/cache  exec                  off                    inherited from data
data/cache  setuid                off                    inherited from data
data/cache  readonly              off                    default
data/cache  zoned                 off                    default
data/cache  snapdir               hidden                 default
data/cache  aclinherit            restricted             default
data/cache  canmount              on                     default
data/cache  shareiscsi            off                    default
data/cache  xattr                 on                     default
data/cache  copies                1                      default
data/cache  version               5                      -
data/cache  utf8only              off                    -
data/cache  normalization         none                   -
data/cache  casesensitivity       sensitive              -
data/cache  vscan                 off                    default
data/cache  nbmand                off                    default
data/cache  sharesmb              off                    default
data/cache  refquota              none                   default
data/cache  refreservation        none                   default
data/cache  primarycache          all                    default
data/cache  secondarycache        none                   inherited from data
data/cache  usedbysnapshots       0                      -
data/cache  usedbydataset         37K                    -
data/cache  usedbychildren        22.5G                  -
data/cache  usedbyrefreservation  0                      -
data/cache  logbias               latency                inherited from data
data/cache  sync                  standard               default
data/cache  rstchown              on                     default

Обратите внимание на размер записи и параметры primarycache и secondarycache. Дабы не разжевывать подробно, отсылаю интересующихся к документации, а здесь лишь скажу - так надо.

Настройки Squid

Большинство настроек Squid, которыми ньюфаги обмениваются в интернете, выглядят так, будто их выкопали из криокамеры и взяли с машинки на Pentium-I с 512 мегабайтами оперативной памяти. 

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

Я не буду приводить полный конфиг продуктивного Squid, а выделю лишь ключевые параметры, непосредственно касающиеся производительности.

# -------------------------------------
# Store parameters
# -------------------------------------
# Uncomment and adjust the following to add a disk cache directory.

cache_dir diskd /data/cache/d1 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d2 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d3 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d4 16384 16 256 Q1=72 Q2=64

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

Следующая группа параметров относится к памяти. Поскольку на дворе не каменный век, а времена Web 1.0 с крошечными объектами безвозвратно канули в Лету, с учетом имеющейся в наличии оперативной памяти, установим следующие параметры прокси:

# ------------------------------------- 
# Memory parameters 
# ------------------------------------- 
cache_mem 512 Mb 
#memory_pools off 
memory_pools_limit 100 MB 
maximum_object_size 128 Mb 
maximum_object_size_in_memory 2 Mb 

Давайте не будем жлобиться и учтем вышесказанное.

Следующая группа параметров прямо влияет на производительность:

# ------------------------------------- 
# Tuning parameters 
# ------------------------------------- 
ipcache_size 8192 
ipcache_low 95 
ipcache_high 98 

fqdncache_size 8192 

buffered_logs on 

memory_replacement_policy heap GDSF 
cache_replacement_policy heap LFUDA 


cache_swap_high 98 
cache_swap_low 95 

negative_ttl 15 minutes 
positive_dns_ttl 15 hours 
negative_dns_ttl 15 minutes 

store_avg_object_size 64 KB 

pipeline_prefetch on 

shutdown_lifetime 1 second 

#offline_mode off 

# Turn it on till cache populated 
# Default is off 
ignore_ims_on_miss on 

zero_buffers off 

Прошу обратить внимание, что данные настройки целиком нацелены на  минимизацию накладных расходов, повышение коэффициента кэш-попаданий, устранение ненужных операций (zero_buffers) и задержек (shutdown_lifetime).

Отдельный вопрос - кэширование контента. Как мы говорили выше, вопрос фильтрации нас пока не интересует. Интересует эффективное кэширование любого мало-мальски тяжеловесного контента. К которому, к сожалению, можно уже отнести не только ролики с Ютуба, но и компоненты веб-страниц. В моей практике неоднократно попадались случаи многомегабайтных JS, плюс множество перекрестных ссылок, тянущих за собой гигантские социальные API. Как следствие, полный объем главной страницы какого-либо наугад взятого крупного сайта влегкую потянет на несколько десятков мегабайт.

# Common captcha acl 
acl captcha urlpath_regex -i ^captcha 

# Media and video acls 
acl youtube dstdomain .youtube.com 
acl media rep_mime_type -i video/flv 
acl mediapr urlpath_regex \.flv(\?.*)?$ 
acl media rep_mime_type -i ^application/x-shockwave-flash$ 
acl mediapr urlpath_regex \.swf(\?.*)?$ 
# Real audio acls acl RealAudio_mime 
req_mime_type application/x-pncmd 
# The keyword for all youtube video files are "get_video?", "videodownload?" and "videoplayback" plus the id 
acl store_rewrite_list urlpath_regex \/(get_video\?|videodownload\?|videoplayback.*id) 

....

# Cache directives 
cache allow youtube all 
cache allow media all 
cache allow mediapr all 
cache allow POST RealAudio_mime all 
cache deny localapache all 
cache deny captcha all 

.... 

# ------------------------------------- 
# Content parameters 
# ------------------------------------- 
# Break HTTP standard for flash videos. Keep them in cache even if asked not to. refresh_pattern -i \.flv$ 10080 90% 999999 ignore-no-cache override-expire ignore-private 
# Apparently youtube.com use 'Range' requests 
# - not seen, but presumably when a video is stopped for a long while then resumed, (or fast-forwarded). 
# - convert range requests into a full-file request, so squid can cache it 
# NP: BUT slows down their _first_ load time. 
quick_abort_min -1 KB 

# Youtube's videos 
refresh_pattern (get_video\?|videoplayback\?|videodownload\?) 5259487 99999999% 5259487 override-expire ignore-reload ignore-private negative-ttl=0 

# Add any of your own refresh_pattern entries above these. 
refresh_pattern -i \.js(\?.*)?$ 43200 100% 43200 
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 
refresh_pattern . 43200 100% 43200 override-expire override-lastmod reload-into-ims ignore-no-cache ignore-private ignore-auth 

.... 

# ------------------------------------- 
# Rewriter parameters 
# ------------------------------------- 
# Storeurl settings 
storeurl_access allow store_rewrite_list 
storeurl_access deny all 
storeurl_rewrite_program /usr/local/squid/bin/storeurl.pl storeurl_rewrite_children 16 
storeurl_rewrite_concurrency 10 
# SquidGuard rewriter 
#url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf 
# SquidClamAV rewriter 
url_rewrite_program /usr/local/bin/squidclamav 
url_rewrite_children 96

Мы сознательно нарушаем ряд стандартов HTTP для повышения коэффициента кэш-попаданий. А также используем функциональность storeurl для эффективного кэширования роликов Ютуба по самоочевидной причине (если мы договорились не блокировать их). Большинство вышеприведенных параметров не нуждаются в комментировании. Мы молча кэшируем на 1 месяц большую часть контента, включая JS (в том числе намеренно оформленные для обхода кэширования), переписываем динамические ссылки Ютуба в статические и сохраняем их в кэше.

Подчеркну, что данные параметры относятся к Squid второй ветки, конкретно - 2.9. Ветка 3 имеет сильно измененные параметры с фактическим запретом на использование нарушающих стандарты директив, однако она и устроена иначе и требует немного иной настройки. Однако, в силу того, что ветка 3 все еще не стабилизировалась в достаточной для продуктивного применения степени, мы ее пока не рассматриваем.

Заключение

Рассмотренные в статье подходы позволили добиться весьма эффективной работы кэширующего прокси с минимальной латентностью. Фактически пользователи субъективно не ощущают присутствия кэша. Объективные показатели следующие. Для сети из 50 высокоактивных пользователей, при скорости внешнего канала 2 Мбит, и внутренней сети 1 Гбит и прогретом кэше, максимальная латентность полного соединения не превышает 0,1-0,2 сек. Собственная латентность кэша составляет 0,02-0,05 сек. Коэффициент кэш-попаданий колеблется в диапазоне 48-64%.

суббота, 10 ноября 2012 г.

Squid: Анонимен ли ваш прокси?

Вообще среди примерно половины (по моим оценкам) использующих Squid как-то не принято писать мало-мальски продвинутые конфигурации. Я воздержусь от личных оценок, с чем это связано, и хочу рассмотреть два вопроса.

Вопрос первый. Как скрывать инфраструктуру внутренней сети посредством прокси от большого злобного интернета? (само собой разумеется, все понимают, как необходимость этого, так и проистекающие отсюда же недостатки)

Ну, во-первых, надо собрать сквид определенным образом (привожу свою конфигурацию):

squid @ ktulhu ~ $ squid -v Squid Cache: Version 2.7.STABLE9-20110824 configure options: '--disable-unlinkd' '--enable-default-err-language=Russian-1251' '--enable-err-languages=Russian-1251 English' '--enable-follow-x-forwarded-for' '--enable-ipf-transparent' '--enable-storeio=ufs,diskd' '--enable-delay-pools' '--enable-async-io=4' '--prefix=/usr/local/squid' '--enable-external-acl-helpers=ip_user' '--enable-removal-policies=lru,heap' '--enable-large-cache-files' '--with-large-files' 'CC=gcc' 'CFLAGS=-O2 -march=i686 -L/usr/local/lib -R/usr/local/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/openwin/lib -R/usr/openwin/lib -I/usr/local/rrdtool-1.4.2/include -I/usr/local/BerkeleyDB.4.7/include -I/usr/local/mysql/include' 'LDFLAGS=-L/usr/local/lib -R/usr/local/lib -R/usr/lib -L/usr/lib -R/usr/openwin/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/X11R6/lib -R/usr/X11R6/lib -L/usr/local/BerkeleyDB.4.2/lib -R/usr/local/BerkeleyDB.4.2/lib -L/usr/local/mysql/lib -R/usr/local/mysql/lib' 'CPPFLAGS=-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include/ncurses -I/usr/openwin/include -I/usr/local/rrdtool-1.4.2/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/pcap -I/usr/local/include/freetype2' '--with-build-environment=default' 

Вообще говоря, для нашей цели критичен лишь один параметр - enable-follow-x-forwarded-for. Как видно из конфигурации, это транспарентный прокси, соответственно, когда мы говорим об анонимизации соединений, речь идет исключительно о протоколе HTTP - другие протоколы могут светить инфраструктуру и детали сети.

Во-вторых, надо включить в конфигурации прокси следующие параметры:

# Hide internal networks details outside 
forwarded_for off 
header_access X-Forwarded-For deny all 
header_access Forwarded-For deny all 
header_access Via deny all 

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

Собственно говоря, для достижения нашей цели этого и достаточно, в чем нетрудно убедиться:





Вопрос второй. Для одного моего знакомого хочу сделать пояснение. В данной конфигурации, при наличии локальной сети, работающей с веб-приложением через точку доступа, оснащенную подобным проксированием, все до единого соединения с веб-сервером (и, следовательно, с базой данных) будут фиксироваться как исходящие из одного IP-адреса - внешнего адреса соединения. Что может привести к невозможности привязки конкретных рабочих станций к схемам аутентификации, аудита и прочее.

Ну, и напоследок, К.О. обращает внимание аудитории на тот очевидный факт, что подобный прокси (как и вообще любой другой) не должен быть легко доступен извне - и соответствующим образом защищен и захарденен, в противном случае вы сделаете ценный подарок хакерам.

пятница, 9 ноября 2012 г.

Squid: parseHttpRequest - unsupported method

Всем любителям дефолтных конфигов и ниасиляторам хочу заметить, что эта проблема меня доставала достаточно давно, но, честно говоря, до нее тупо не доходили руки. Однако растущий лог кэша кого угодно доконает (да, у меня настроена ротация логов в системе, спасибо, что напомнили) и пришлось разбираться.

Вот как это выглядит:


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

В качестве ответа на вопрос, как это побороть, даже гуглить не надо. Достаточно открыть дефолтовый конфиг с комментариями и просто внятно почитать его:


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

Вуаля - все ок:


Как видим, все решилось в одну минуту. Пользуйтесь на здоровье.

среда, 7 ноября 2012 г.

YouTube жжот

Намедни я натолкнулся на совершенно занятную выдачу результатов поиска:

*запрос был "не проигрывается видео YouTube" :)

Нет, я понимаю, что пользователи Ютуба никогда не слышали самый короткий анекдот на планете "pkunzip.zip". Я понимаю также, что выросшее Generation "Ы" с рождения страдает дислексией. "Что ты умничаешь, ты рукой покажи!"

Но то, что это примет характер клинической эпизоотии, я даже и вообразить себе не мог. 

(откровенно веселюсь)

Это пять, ребята! :)))))))))))))

Продолжайте в том же духе - и мы придем к наскальной живописи еще в этом столетии! :))))))))


Мне в конце 90х эпизодически попадались такие личности, которые, получив e-mail, немедленно перезванивали, чтобы им устно сказали то, что написано в письме. :)

Выросло поколение, воспитанное кинескопом и только им. Искать текст, читать текст и извлекать из него информацию мы уже не умеем. Только из видеорядов, сопровождаемых пока еще связной речью (хотя с последним я тоже готов уже поспорить, глядя на клипы, которые мой сын смотрит на том же Ютубе). Видеокурсы на любую тему! Пари держу на 5 биткоинов, скоро появится видеокурс по онанизму. ;)

"О, дивный новый мир!" 

Гагарин долетался, а мир докатился. :)))))))))))))))

PS. ЧСХ, цитаты из классиков уже давно никто не узнает - надо обязательно давать пруфлинк на Вики или указывать автора и название произведения. Причем первое предпочтительно - ваша память пруфом не считается. Недавно я был потрясен, случайно наткнувшись на "Снобе", как девушка 30 с чем-то лет, претендующая на интеллигентность и высочайшуюповышенную культуру, не узнала легендарную и известную любому русскоговорящему индивидууму старше 40 лет цитату из "12 стульев" Ильфа и Петрова. Даже глаза протер - не мерещится ли мне. Ей-богу, не вру! Я плакал, я рыдал, я обливался горючими слезами. "... а что касается этих ин...ин...интуальных индексов, то у них этих интуальных индексов отродясь не существовало!"

четверг, 1 ноября 2012 г.

Запрет кэширования reCAPTCHA в Squid

Неожиданно оказалось, что с директивой "кэшировать все в течение месяца" пользователи сквида не могут пройти reCAPTCHA. И, соответственно, попасть на многие уютненькие.

Что ж, запретим сквиду кэшировать соответствующий сервис и его компоненты.

Сделаем просто. Напишем регулярное выражение для acl и соответствующую директиву:

# reCAPTCHA acl 
acl recaptcha urlpath_regex ^/recaptcha 

cache deny recaptcha all

Собственно говоря, это все. Если надо аналогичным образом запретить кэширование других подобных ссылок с капчами, достаточно расширить регулярное выражение стандартным способом, через (|).

Ну и сквид не забыть переконфигурировать. ;)