[Ivan_83]

Нашли кому рассказывать, у меня там кучка аккаунтов, которые или железки используют или самописный скрипт на перле на фряхах.

 

Клиентам это покажите :)

Мало того что по русски не все хорошо читают и воспринимают, так ту ни одного знакомого слова нет и буквы не все знакомые.

Это нужно сидеть со англо-русским словарём и толковым словарём содержащем IT слова.

 

А потом объясняйте им что это такое и зачем оно им надо.

 

 

Есть несколько вариантов обзавестись почтовым ящиком:

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

- зарегаться на платном мыльнике

- купить домен+хостинг и чуть чуть поработать в админке

- поставить свой сервер дома, зарегать домен, купить канал, настроить там ОС, почтовый сервис(=демон) запустить, бороться со спамом, отбиваться от попыток захватить управление сервером...

[photon]

Скорее, хотят сделать сеть пользователей BitTorrent более прозрачной для владельцев авторских прав путем постепенной деанонимизации. Иначе не понятно, зачем это городить, если для "доступа из любой точки, где есть вход во всемирную паутину", юзеру достаточно иметь белый IP и зарегистрировать имя хоста на каком-то из бесплатных DNS.

Вы там, у себя на работе, совсем зажрались! Сходите в ТП поработайте, хотя бы пару часов чтобы снова понять насколько тупы пользователи в своей массе.

 

Многие даже осознать свои потребности не в состоянии.

Насчет пользователей подмечено чертовски верно (95%, как обычно). Target group этого сервиса скорее те, у кого хватает знаний использовать торренты, но не хватает знаний о сетевом взаимодействии, о том как настроить веб-интерфейс торрент-клиента на домашнем сервере и прочих технических деталях. Если адрес белый и фиксированный, с dyndns можно даже не напрягаться, а работать по IP. Мне кажется, что было бы лучше популяризировать эти знания, чем встраивать в торрент-клиенты неоднозначные возможности. Насчет массового мониторинга пиров, которым сейчас неиллюзорно занимаются RIAA, MPAA и прочая копирастия, замечу, что это вещь довольно скользкая, которую в будущем скорее всего приравняют к незаконному прослушиванию. Незаконно собранные улики, как известно, судом не признаются. А на предлагаемом ресурсе все будет как на ладони, с возможностью централизованного отслеживания и бана "нелегальных" торрентов/magnet links.

Изменено 11 июля, 2010 пользователем photon

[maximt]

подскажите как в dgs 3200 с помощью Packet Content ACL заблокировать

для des пример есть, но на dgs синтаксис отличается

 

 

пробую

create access_profile profile_id 3 packet_content_mask offset_chunk_1 9 0xFFFF offset_chunk_2 13 0xFFFF offset_chunk_3 24 0xFFFFFFFF offset_chunk_4 25 0xFF000000
config access_profile profile_id 3 add access_id 1 packet_content offset_chunk_1 0x6A5 offset_chunk_2 0x21 offset_chunk_3 0x7FFFFFFF offset_chunk_4 0xAB000000  port 7,10 deny

но получаю

The specified packet content is not supported.

 

Fail!

 

Изменено 12 июля, 2010 пользователем maximt

[Гость nuclight]

@Ivan_83:

Чего то совсем непреодолимого быть там не должно, по идее базовый функционал ОС.

 

Это фича FreeBSD, на линуксе divert-сокетов нет. Есть только в виде сторонних патчей, afaik.

 

Теперь у провайдеров есть способ блокировать/сильно шейпить почти весь торрент траффик!

Те это гарантированно его почти весь (минус DTH и не добавленные трекеры) выделяет (TCP и UDP) и без особых усилий/затрат.

 

Ну, для блокирования DHT (он работает по UDP) можно адаптировать правила из моего ЖЖ в посте про PPTP GRE. А что касается недобавленных трекеров - ну можно в ядре искать в HTTP-трафике сигнатуры ответа трекера. Усилит нагрузку, но не столь сильно, как если бы весь трафик в приложение в divert передавать.

 

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

 

Так а разве от прокси идет не такой же самый HTTP-ответ, в котором можно вычленить сигнатуру и далее всё точно так же? Кроме того, насколько я знаю, трекеры могут брать адрес клиента из того конца соединения - чтоб клиенту за NAT сообщать его реальный адрес. В этом случае получится адрес прокси, и у клиента перестанет работать.

 

--

@photon:

 

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

 

Да ну, не будет. Админ, который в состоянии написать код на Си для ядра - в состоянии и освоить netgraph. Более того, он именно так и поступит, потому что для netgraph модуль ядра написать проще, чем просто модуль. В конце конков, netgraph и есть фреймворк для программистов. А все остальнные, кто не может - те и так используют нетграф только через более простые и понятные утилиты-обертки. Например, mpd.

 

Возникает другой вопрос: зачем использовать и подстраивать костыли под устаревший и неподдерживаемый серьезным оборудованием протокол PPTP? Сейчас все переходят на IPoE и умный доступ, чтобы было проще.

 

Ну, это у вас внутри МКАДа переходят, у вас там хорошо. Москва - отдельная от России страна, хехе. Однака, возникает этот вопрос у Вас абсолютно не по теме: иллюстрации утверждения он вполне удовлетворяет, задача фильтрования нешифрованного внутритуннельного трафика действительно проста, но на u32 её не решить. QED.

 

Гранты на исследования оплачиваются, кстати говоря, гуманитариями от экономики. Поэтому от них зависит, какое исследование будет проведено, а какое -- нет. И экономическая выгода, которой руководствуются грантодатели, довольно часто идет вразрез с научным и технологическим развитием. Вспомните, для примера, что стало с архитектурами PDP и Alpha, и что стало с x86. Кроме того, вы так говорите, как будто не слышите отовсюду пессимистические прогнозы насчет нехватки ресурсов, об экологических проблемах и прочих нехороших вещах, вроде проблемы утилизации ядерных отходов и использованных гаджетов. Это совершенно не тот энтузиазм по поводу прогресса, который был в XIX веке, а скорее жизнь в постоянном ожидании катастроф.

 

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

[dmn]

Подскажите в чем может быть проблема:

Днем загрузка канала 320M/bit 60kpps загрузка каждого из 8 ядер 10%

Вечером загрузка канала 450M/bit 75kpps загрузка каждого из 8 ядер 95%

 

ipfw только NAT. Фильтров на udp не стоит никаких. Может быть проблема в этом?

 

Подскажите - в какую сторону копать?

Изменено 15 июля, 2010 пользователем dmn

[XeonVs]

Подскажите в чем может быть проблема:

Днем загрузка канала 320M/bit 60kpps загрузка каждого из 8 ядер 10%

Вечером загрузка канала 450M/bit 75kpps загрузка каждого из 8 ядер 95%

 

ipfw только NAT. Фильтров на udp не стоит никаких. Может быть проблема в этом?

 

Подскажите - в какую сторону копать?

в сторону избавления от ната, или вырезания торрентов тем или иным способом описаным в теме.

[dmn]

в сторону избавления от ната, или вырезания торрентов тем или иным способом описаным в теме.

Я попробую, конечно, но мне не понятно почему столь резкое увеличение загрузки проца при относительно небольшом увеличении всего остального...

[Ivan_83]

прибивайте потоки к ядрам

[marikoda]

А нет ли у кого свежей сигнатуры для iptables ?

А то похоже, что пролезать опять стало :(

[LostSoul]

Кому-то удалось нормально запустить скрипт из ссылки выше на линукс?

 

Я нашел модуль ipt_DIVERT только для ядра 2.6.12

 

И наблюдается ли у кого-то на сети "колбаса" последнюю неделю?

 

[marikoda]

Есть желание попробовать uTPControl .

Что думаете про такую схему: на свиче трафик абонентов сливается в mirror, далее попадает в divert, далее в uTPControl.

Не совсем только понятно, как сделать, чтобы пакеты из promisc попадали в divert.

Кто-нибудь может подсказать?

 

[Ivan_83]

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

Думаю ещё бОльшая будет проблема как сгенерированные пакеты обратно возвращать, тк в них IP сервера с uTPControl не фигурирует.

[marikoda]

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

перефразирую.

можно ли взять из promisc интерфейса, на котором еще и нет ip адреса, пакеты и передать в divert, лучше предварительно прогнав через фильтр, который оставит только udp ?

 

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

 

Думаю ещё бОльшая будет проблема как сгенерированные пакеты обратно возвращать, тк в них IP сервера с uTPControl не фигурирует.

Как раз с этим проблемы быть не должно. Можно поставить второй интерфейс, на нем поднять IP адрес и default gw в сторону роутера, пакеты будут уходить и попадать к адресатам.

 

UPD. Подумалось, может с помощью netgraph такое реально организовать? NGM_ETHER_SET_PROMISC(setpromisc)

UPD2. Или даже с libpcap

Изменено 2 сентября, 2010 пользователем marikoda

[Ivan_83]

UPD. Подумалось, может с помощью netgraph такое реально организовать? NGM_ETHER_SET_PROMISC(setpromisc)

Тут были ссылки на переделанный с divert~а в ng модуль код блокировки, пробуйте тогда уж с ним.

[LostSoul]

Не бейте валенками, ввиду отсутствия на узле FreeBSD сделал вот так.

 

tcpdump -nnpt -s 72 udp[8] = 0x41 and udp[24:2] = 1 and udp[26:2] = 0 and \( \(udp[9] = 0 and udp[4:2] = 8+20\) or \(udp[9] != 0 and udp[4:2] = 8+20+2+udp[29]\)\) | cut -d " " -f 2,4 | sed 's/\./ /4; s/\./ /7;s/://' |perl -e 'while (<>){split(" "); system("conntrack -I --protonum udp --timeout 60 --src $_[0] --sport $_[1] --dst $_[2] --dport $_[3] --status UNSET -n 127.0.0.1 -g 127.0.0.1");};'

 

Логическая схема такая - выявляем пакеты открытия сесии uTP по примеру, указанному в этой ветке, комбинацию ip:port -- ip:port засовываем как поддельную запись в conntrack, обьявив будто бы это nat-сессия с localhost.

( Механизм conntrack по прямому назначению на данной машине не используется и запилен через -j NOTRACK ). Соответственно блокирующие записи в conntrack живут в течении 30 секунд после последнего совпадающего пакета.

 

 

Проблемы:

1) Так же как в ветке Ivan83 тут же полезли жалобы на CounterStrike и сбербанк. И еще какую-то игрушку.

2) Скрипт добавляет в conntrack около 14 тысяч записей ( количество постоянно плавает где-то около ) , однако общий PPS на интерфейсе провайдера не снижается совсем. Видимо с какой скоростью запиливаем, с такой неугомонный uTorrent ищет новые порты по которым пролезет.

 

Что-же делать с этим торрентом?

Я кроме как ручного обзвона клиентов с разъяснительной работой "кто не выключит uTP тому отключим газ", уже ничего и придумать не могу. Вносить в список исключений всё что может работать по UDP не хочу.

 

[NiTr0]

Я нашел модуль ipt_DIVERT только для ядра 2.6.12

xt_TEE, xt_TPROXY - имеются в ванильном 2.6.35...

[marikoda]

В общем. по опыту, немного помогает, если клиенту, с которого валит много UDP нарисовать шейпер на BRAS, в котором udp задавлен на 1/2-1/3 тарифной полосы в обе стороны. Клиентов, которые не флудят, соответственно, не трогать. Причем, шейпер включить только в часы наибольшей нагрузки.

[starina]

Ребята, а не пробовали в хендшейках менять флаг? Насколько мне известно, именно в хендшейке идет указание на то какой протокол использовать (UDP или ТСР) для файлообмена.

 

Правда проблема с шифрованными хендшейками. Но таких не думаю что больше 10%.

[dbask]

могут ли такие симптомы быть следствием поведения uTP и торрент клиента:

 

через один из наших нато-шейперов(linux (ipt, tc htb)), в течении 2-3 часов, через каждые 30 минут, или 15 минут,

проскакивал UDP флуд, который почти мгновенно цпу в 100% кладет, активность идет гдето минуту, потом изчезает, так что отловить оч трудно.. данная активность спонтанна (за последний год была 2-3 раза).

 

первый раз хомячка отловили, вирусов у него не было, был только торрент клиент (на порту во время флуда pps подскакивал под 100к, и unicast traffic control'om длинка флуд почему то не срезался)

последний раз отловить не успели...

 

привожу скрин кол-ва pps на NAT в час пик (провалы - когда CPU-100%):

Изменено 17 сентября, 2010 пользователем dbask

[Tosha]

Я думаю, что это все-таки какая-то бот сеть или вирус.

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

[marikoda]

А кто-нибудь уже пытался шейпить PPS, а не полосу ?

[Ainy]

шейпить PPS - это как?

Delay packet by M if packet rate from same source is greater then N?

Если так как описано, то я пробовал на ipfw2. года 4 тому или около того.

Только вот на загруженном роутере такой шейп врядле снизит нагрузку на проц.

 

[vIv]

Задача о броне и снаряде: успеет ли роутер провайдера принимать, пересчитывать и дропать пакеты быстрее, чем клиентские компьютеры смогут их генерировать?

[Ivan_83]

Вы их в ядро не пущайте, дропайте на излёте, до fastforward/ip_input, например на lower хуке ng_ether.

Тогда и нагрузка будет ощутимо меньше.

Как дропать - по рандому*назрузку, например цпу или сетевого канала, самое быстрое и простое %)

Можно как то городить счётчики и по их данным.

[marikoda]

Вы их в ядро не пущайте, дропайте на излёте, до fastforward/ip_input, например на lower хуке ng_ether.

Тогда и нагрузка будет ощутимо меньше.

Как дропать - по рандому*назрузку, например цпу или сетевого канала, самое быстрое и простое %)

Можно как то городить счётчики и по их данным.

а можно ли вообще дропать на свичах, например, еще на этапе pppoe ?

или это чревато "разрывами" ?