Jump to content

Recommended Posts

Posted

layer7

cat /etc/l7-protocols/protocols/bittorent

# Bittorrent - P2P filesharing / publishing tool - http://www.bittorrent.com
# Pattern attributes: good veryfast undermatch
# Protocol groups: p2p
# Wiki: http://www.protocolinfo.org/wiki/Bittorrent
#
# This pattern has been tested and is believed to work well.
# It will, however, not work on bittorrent streams that are encrypted, since
# it's impossible to match encrypted data (unless the encryption is extremely.
# weak, like rot13 or something...).

bittorrent

# Does not attempt to match the HTTP download of the tracker
# 0x13 is the length of "bittorrent protocol"
# Second two bits match UDP wierdness
# Next bit matches something Azureus does
# Ditto on the next bit.  Could also match on "user-agent: azureus", but that's in the next
# packet and perhaps this will match multiple clients.
\x13bittorrent protocol|d1:ad2:id20:|\x08'7P\)[RP]|^azver\x01$|^get /scrape?info_hash=

Posted

На кошке мне это не удалось, ибо трафик идет по динамическим портам, часто используется шифрация и т.п.

Как ни обидно, но видимо меньшее зло - расширить канал, чем бороться с торрентами.

Posted

А вот американские журналисты библию хотели скачать , и не смогли , и стали жаловаться на провайдера , и государство сказало: ISP , ты не прав ! Дело провайдера передать пакет из точки А в точку Б , а не заглядывать внутрь конверта . Клиент платит ? - дай услугу ! Не можеш - не берись . А ценовая политика и конкуренция вообще то личные трудности компании .

 

это про нейтралитет сетей кстати

должен ли поставщик контента доплачивать за доставку ,

а клиент просматривать только сайт новостей и читать почту .

 

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

но не есть ли это мошенничество в чистом виде ?

 

 

 

Posted

Как вариант - давать не симметричный безлимитный канал (512К / 512К), а для download давать 512К, а для upload - например 128К. В торрентовых сетях ведь немаловажно сколько ты отдаешь. А потому, если ограничить полосу upload-а, то это автоматически приведет к снижению рейтинга твоих любителей торрентов в торрент-сети и, как следствие, торрент-сеть сама будет ограничивать возможности (в т.ч. и скорость скачивания) для этих пользователей. При этом "нормальным" юзерам для Web-серфинга, работы с почтой, аськой, чатами и т.п. это ограничение upload-а не создаст неудобств - скорее всего они этого просто не заметят.

Posted

Как вариант - давать не симметричный безлимитный канал (512К / 512К)

а если мне нужен именно исходящий канал? FTP-upload допустим? предлагаете доплачивать за симметричность?

Posted (edited)
На кошке мне это не удалось, ибо трафик идет по динамическим портам, часто используется шифрация и т.п.
Увы, способов пока нету. Так же тыкаемся как и многие тут присутствующие.
На цисковских роутерах в иосах нормальной свежести есть такая фича, как NBAR. По большому счету, это некий волшебный ящик, который магическим образом определит, к какому протоколу относится даный пакет. Иногда решение принимается только на основании значений портов, но в основном этими даными не ограничивается, и роутер копает еще глубже, аж до седьмого уровня, где пытается найти некую сигнатуру. В том числе опознать bittorrent или даже skype, несмотря на то, что они могут висеть на 80 порту. Задача в принципе далеко нетривиальная и неплохо пригружает процесор, но если у вас канал в пару мегабит, такая задача должна быть под силу даже чему-то на уровне 2801. Хотя скажу честно, сам я об технологии узнал достаточно недавно и в продакшене еще не использовал. О более конкретных цифрах можно узнать на оф. сайте.

Примерный конфиг для ограничения исходящего P2P трафика на интерфейсе в около 100000 б/с:

class-map match-any P2P
match protocol bittorrent

policy-map RESTRICT_TORRENTS
class P2P
  police cir 100000
    conform-action set-dscp-transmit af11
    exceed-action set-dscp-transmit af13
    violate-action drop

interface FastEthernet0/0
service-policy output RESTRICT_TORRENTS

Вместо полиси можно делать шейп, не маркировать пакеты и т д, но общая картина приблизительно такая.

Edited by troyand
Posted
Это для SCE 1000 Series. А для железок по-слабее, типа 36хх ?

 

 

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

Ниже - копия моего поста вот отсюда: http://www.hub.ru/forum/index.php?showtopi...st&p=189179

 

Пробовал ограничить полосу для торрентов на cisco, которая терминирует pptp от пользователей и роутит их.

Залил ей на флэшку файлики: bittorrent.pdlm, eDonkey.pdlm, directconnect.pdlm

 

В конфиге:

 

ip nbar pdlm flash:bittorrent.pdlm

ip nbar pdlm flash:eDonkey.pdlm

ip nbar pdlm flash:directconnect.pdlm

 

class-map match-any torrents

match protocol bittorrent

match protocol edonkey

match protocol directconnect

match protocol napster

match protocol fasttrack

!

!

policy-map limit-torrents

class torrents

police 512000 32000 64000 conform-action transmit exceed-action drop violate-action drop

 

Т.е. выделено 512 Кбит на торренты. Ну и потом на интерфейсе:

 

interface FastEthernet1/0

service-policy input limit-torrents

service-policy output limit-torrents

 

Даная конструкция показала свою неэффективность:

 

sh policy-map interface FastEthernet 1/0

FastEthernet1/0

 

Service-policy input: limit-torrents

 

Class-map: torrents (match-any)

7618086 packets, 4793051821 bytes

5 minute offered rate 2000 bps, drop rate 0 bps

Match: protocol bittorrent

2711263 packets, 2280010888 bytes

5 minute rate 2000 bps

Match: protocol edonkey

548221 packets, 329136031 bytes

5 minute rate 0 bps

Match: protocol directconnect

97 packets, 51991 bytes

5 minute rate 0 bps

Match: protocol napster

3544404 packets, 1504256497 bytes

5 minute rate 0 bps

Match: protocol fasttrack

814097 packets, 679595336 bytes

5 minute rate 0 bps

police:

512000 bps, 32000 limit, 64000 extended limit

conformed 7617083 packets, 4792162634 bytes; action: transmit

exceeded 849 packets, 754111 bytes; action: drop

violated 154 packets, 136244 bytes; action: drop

conformed 2000 bps, exceed 0 bps, violate 0 bps

 

Class-map: class-default (match-any)

3551537445 packets, 1672205826170 bytes

5 minute offered rate 3353000 bps, drop rate 0 bps

Match: any

 

Service-policy output: limit-torrents

 

Class-map: torrents (match-any)

6607839 packets, 1270837551 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: protocol bittorrent

2269799 packets, 580391006 bytes

5 minute rate 0 bps

Match: protocol edonkey

514067 packets, 293911248 bytes

5 minute rate 0 bps

Match: protocol directconnect

169 packets, 9452 bytes

5 minute rate 0 bps

Match: protocol napster

3194565 packets, 301246741 bytes

5 minute rate 0 bps

Match: protocol fasttrack

629238 packets, 95279023 bytes

5 minute rate 0 bps

police:

512000 bps, 32000 limit, 64000 extended limit

conformed 6607843 packets, 1270837791 bytes; action: transmit

exceeded 0 packets, 0 bytes; action: drop

violated 0 packets, 0 bytes; action: drop

conformed 0 bps, exceed 0 bps, violate 0 bps

 

Class-map: class-default (match-any)

3251786970 packets, 1460929373592 bytes

5 minute offered rate 3053000 bps, drop rate 0 bps

Match: any

 

 

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

Posted (edited)

Хочу высказать пару мыслей по теме.

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

У всех любителей P2P сетей есть одна общая черта - большой трафик. Мне кажется, что отталкиваться стоит именно от этого. Можно спрятать тип трафика, но нельзя спрятать его объем. Также заслуживает внимания подход от противного - если мы не может выделить p2p сеть, то это не значит, что мы не можем выделить http или ftp. И тогда можно действовать по старому доброму принципу "все, что не разрешено - запрещено", который в нашем случае из запрещено превратится в зашэйплено. Тоесть схема борьбы получается двухуровневая: сначала на основе статистики мы отделяем потребителей большого объема трафика, и ставим им ограничения, потом пытаемся выделить из их трафика обычный HTTP и FTP и созаем для них более выгодные условия.

Edited by user_anonymous
Posted
сначала на основе статистики мы отделяем потребителей большого объема трафика, и ставим им ограничения, потом пытаемся выделить из их трафика обычный HTTP и FTP и созаем для них более выгодные условия.
Тоже самое было предложено по указанной мной ссылке. Но конкретной реализации я так и не нашел. Вернее оно есть для старших цисок, у которых IOS поддерживает isg. Т.е. вариант не для меня, потому он и не был опробован. Для старых цисок серий 25хх, 36хх я решения не нашел.

 

 

Posted

Господа , а вы клиентов предупреждаете ? что: у нас торрент и емуль запрещены !

Прямо на сайте пишете ? и в договор включаете ?

А если клиенту только это и надо было ?

Posted

Я упорно не вступаю в философские дискуссии, т.к. топик находится в разделе "Технические вопросы ..."

Поэтому давайте не будем тут решать юридические вопросы и отстаивать общечеловеческие ценности. ОК? :)

 

Еще вариант - загнать весь трафик КРОМЕ торрента в классмап:

 

class-map match-any not_torrents

match not protocol bittorrent

match not protocol edonkey

match not protocol directconnect

match not protocol napster

match not protocol fasttrack

 

и ему выделить QoS-ом полосу (в этом примере 1Мбит):

 

policy-map not-torrents

class not_torrents

police 1024000 192000 384000 conform-action transmit exceed-action drop violate-action drop

 

interface FastEthernet1/0

service-policy input not-torrents

service-policy output not-torrents

 

Но тогда получится, что:

1. циска все равно не поймает весь торрентовский трафик (см. посты выше)

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

Posted

Не совсем, там предлагают выделить "нормальный" трафик и "весь остальной" трафик. Нормальному дать полосу (или приоритет) больше (выше).

Posted
Еще вариант - загнать весь трафик КРОМЕ торрента в классмап:
Если говорите, что NBAR не работает так, как хотелось бы, то это тупиковая ситуация.

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

Posted
Не совсем, там предлагают выделить "нормальный" трафик и "весь остальной" трафик. Нормальному дать полосу (или приоритет) больше (выше).
Что-то про приоритеты не встретил там - http://www.hub.ru/forum/index.php?showtopic=27565&st=30 - вариантов с приоритетами...

 

Если говорите, что NBAR не работает так, как хотелось бы, то это тупиковая ситуация.
Что-то не верится, что у затаившихся в засаде цисководов нет решения. :)
Posted

А если я предложу тупое решение "с поверхности" заблокировать штук 30 адресов самых популярных трекеров ?

Не дав получить список пиров и трафик блокировать не надо .

 

Знаю что вы знаете , но почему так не хотите ? никакого ПО и железок :-)

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.