Не разрешимая задача в iptables/squid/htb.

[triangel]

   Доброго времени суток, дорогие форумчане! Решал недавно задачку, по ограничению просмотра/прослушивания видео/аудио с помощью squid/iptables/htb (и в этом мне очень помог мой любимый ubuntu форум, а также opennet.ru).

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

   Это бы решало сразу кучу задач, и по ограничению аудио/видео потоков и по закачке больших файлов (http/ftp). Перерыл все интернеты, ничего не нашел! Но интуиция подсказывает, что это наверняка уже как то реализовано, идея то довольно банальная. Ведь есть в том же iptables и conntrack трасировщик, и критерии limit/limit-burst и много чего еще с этой темой связанного. В конце-концов есть ведь patch-o-matic, там же наверняка, что-то есть. Попытки чтения инфы по patch-o-matic, даются с трудом и пока результатов не принесли.
   Болею этой темой уже вторую неделю. Совсем отчаялся:-(... Ничего не получается! Люди добрые, наверняка кто-нибудь что-нибудь подобное уже реализовывал. Поделитесь опытом, ПОЖАЛУЙСТА!!!

С надеждой на внимание и помощь, triangel.

[Mam(O)n]

Немного порыл интернеты и набрёл на утилиту conntrack, которая работает с таблицами nf_conntrack. С помощью неё можно отслеживать эвенты и удалять записи в nf_conntrack таблице. Можно написать демона, который будет слушать вывод conntrack -E -o timestamp -e NEW и рубить коннекты, которым больше минуты с помощью conntrack -D

[AnrDaemon]

Закачку больших файлов это не решит совершенно точно.

[triangel]

Спасибо тем, кто откликнулся . Особенно Mam(0)n-у, вы не раз меня выручали, за что вам низкий поклон. А по существу, про трассировщик conntrack я и сам сразу подумал, но вот в его таблице /proc/net/ip_conntraсk нужных для себя параметров (time) не нашел. А вот про отдельную утилиту conntrack я не слышал, сейчас загуглю и буду изучать (если несложно киньте пару толковых ссылок, может я на них не напорюсь). Затем планирую сделать скриптик и запускать его как демона. Опыт у меня в этом деле небольшой, но если получиться и не стыдно будет выложить, то выложу в этом посте. Не знаю, правда, сколько времени у меня это все займет .

p.s.: откровенно сказать я ведь расчитывал, что кто-нибудь уже это делал и может поделиться (если не жалко), своими наработками...

p.p.s.: AnrDaemon-у отвечу. Долгие закачки файлов по http/ftp, по моему этот способ должен решать,если не пользоваться какими-нибудь менеджерами, с докачкой и зеркалами, да и в этом случае тоже если рубить соеденение с данным ip, положим на часик. А на счет торрентов, то придется, наверное оставить стандартный способ, который уже работает.

С надежной на дальнейшее внимание и советы, triangel.

[Mam(O)n]

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

Да я сам только что про неё узнал. Из всего, что мне известно это man conntrack и http://conntrack-tools.netfilter.org/

[terrible_user]

возможности delay_pools в squid автором уже рассматривались ?

[triangel]

to terrible_user: если вы знаете как реализовать эту идею, при помощи delay_pools, то поделитесь пожалуйста. Я например не смог этого сделать. Все что у меня получилось это резать аудио/видео потоки и другой контент. Опыт показал, что это не всегда помогает. Встречаются аудио потоки, которые приходят на сквид не как аудио...

Идея которую я озвучил в первом посте - контенто-независимая! В этом ее привлекательность, если конечно получиться реализовать...

[terrible_user]

to terrible_user: если вы знаете как реализовать эту идею, при помощи delay_pools, то поделитесь пожалуйста. Я например не смог этого сделать. Все что у меня получилось это резать аудио/видео потоки и другой контент. Опыт показал, что это не всегда помогает. Встречаются аудио потоки, которые приходят на сквид не как аудио...

Идея которую я озвучил в первом посте - контенто-независимая! В этом ее привлекательность, если конечно получиться реализовать...

Идею: обрывать любое соединение через минуту - нет.
Но при помощи squid'a можно ограничивать скорость, например,  кто-то решил скачать файл, посмотреть видео  - качает, качает - скачал 5Мб и ему скорость обрежет до 10кб\с.
аудио/видео/файлы - лишь бы это проходило через squid.

Подходит вариант или нет - сами решайте.

[AnrDaemon]

Не подходит... сквид, и вообще работа через прокси - это прошлый век. Совершенно не переносимо и не прозрачно без ручного вмешательства в обработку пакетов.

[Unreg]

Я вот не придумал более простого способа учёта посещенных URL, кроме прозрачного HTTP прокси

[triangel]

   Провозился кучу времени, читая доступную документацию по conntrack (из conntrack-tools) и пытаясь хоть что-то сделать на практике. В результате ничего не получилось. Во первых (наверное самое главное) не получается ни какими способами (ни с какими ключами), получить время жизни соеденения! Например, упоминавшейся conntrack -E -o timestamp -e NEW - ничего  о времени жизни соеденения не показывает и вообще не понятно для чего служит этот timestamp. Но если бы конечно в выводимой информации были данные о времени жизни соеденения, то поймать его лучше было бы conntrack -G. Однако увы и ах, время жизни соеденения узнать не получается. А без этого ключевого параметра вся идея теряет смысл.

p.s.: можно было бы модифицировать идею, на трафик. Но как его собирать. Парсить в реалтайме логи сквида - помоему это не вариант!

Вообщем пока ничего - процесс застопорился.

[Mam(O)n]

Ты идею не понял. Демон должен собирать от conntrack инфу о коннектах и заносить их в массив. Раз в секунду по массиву должен проходить сборщик, который будет равть коннекты, у которых timestamp старее текущего предположим на 60 cекунд.

[triangel]

to Mam(0)n: Да возможно и так, действительно не понял вашей идеи, но то что вы сейчас (в последнем посте) предложили пока еще для меня слишком сложно. (с вырезанием из строк всяких кусочков и регулярными выражениями - это просто труба!)

А по существу еще хочу сказать вот что: Есть такой критерий connbytes, так вот он позволяет реализовать идею с обрезанием потока (соеденения) по критерию, количества скаченного (а не по времени) буквально в одно правило (просто и элегантно). Пример:

#  Соединения, по которым передано более 1 Мб, дропаем
iptables -t filter -A INPUT -m connbytes --connbytes 1024000: --connbytes-dir both --connbytes-mode bytes -j DROP
iptables -t filter -A FORWARD -m connbytes --connbytes 1024000: --connbytes-dir both --connbytes-mode bytes -j DROP
iptables -t filter -A OUTPUT -m connbytes --connbytes 1024000: --connbytes-dir both --connbytes-mode bytes -j DROP

Более, того в этой же статье я нашел частичное описание критерия recent, который, судя по описанию может запоминать в том числе и время поступления пакета. Как он работает я еще не разобрался (несмотря на примеры), штука довольно тонкая и хитрая. НО МНОГООБЕЩАЮЩАЯ!

P.S.: Очень важное замечание, все это я прочел в статье на википедии http://ru.wikipedia.org/wiki/Iptables. Давно очень знал об этой статье, но всегда избегал, так-как читал о ней много нелестных отзывов. А сейчас читаю и не могу оторваться . Наверное это лучшее, что я читал по iptables (уж покрайней мере лучше руководства 1.1.19). Может быть это правда лишь только эмоции, но все-же ...

[triangel]

Сам спрашивал, сам и отвечаю , может кому еще и пригодиться... Ответ на изначальный вопрос:

iptables -A FORWARD -p tcp -m state --state ESTABLISHED -m recent --update --seconds 60 -j DROP

К сожалению у меня сейчас нет возможности это проверить(не поверите, но это целая история ). Если кто сможет, проверьте, если нет то сам сделаю, когда доберусь до моего тестового шлюзика.

А пока все. Пользуйтесь проблема РЕШЕНА.

(может еще будут правки по синтаксису, но в общем - РЕШЕНА)

[terrible_user]

Код: [Выделить]

iptables -A FORWARD -p tcp -m state --state ESTABLISHED -m recent --update --seconds 60 -j DROPПри таком правиле, как мне кажется, он должен пропускать только 1 пакет установленного соединения раз в 60 сек,  при условии полного отсутствия дальнейшей сетевой активности - иначе время ожидания может продлиться до бесконечности.