P2P: битва за контроль

Знаю, это оффтоп, но лучших результатов я добился с другой Linux-машиной и iptables, пропатченными фильтром layer7. Да, это не так просто, как на Mikrotik, и настройка – тот еще геморрой, но я избавился практически от всего p2p-трафика.

Заблокируй это, не трать время, пытаясь это контролировать.

Я уже отправлял кучу заявок по этому вопросу, так что никакой стандартной фразы "Отправьте заявку!". Судя по всему, зашифрованная P2P-ширина канала не видна для очередей Mikrotik. Загляните на интерфейсы, и мы увидим 3 Мбит/с трафика, но если посмотреть на простые очереди, то происходит только 20 Кбит/с. Запуск torch показывает IP-адреса, ответственные за ширину канала, и дальнейшее их ограничение не оказывает никакого эффекта. Так что не только P2P-ширину канала нельзя ограничить, её даже нельзя сформировать! Есть какие-нибудь решения этой проблемы?

Вы когда-нибудь задумывались, какие ресурсы требуются для попыток контроля трафика? Учитывая, что мы находимся на форуме MikriTik, вполне логично предположить, что речь идет о P2P-трафике по беспроводной сети.

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

А теперь посмотрите, что делает P2P-трафик с вами. Чтобы даже попытаться формировать или отбрасывать его, вам нужно включить отслеживание соединений в Router O/S, и это расходует ресурсы. Их P2P-приложение заставляет их выступать в роли сервера, так что у вас теперь поток входящих соединений, пытающихся добраться до этого клиента, что может быть нарушением вашего AUP, если вы не разрешаете клиентам запускать серверы. Эти попытки подключения будут держать радио занятым во время каждого цикла опроса, и чем популярнее материал, который они распространяют, тем хуже становится. Один клиент начинает монополизировать ваш AP, потому что такая большая часть трафика предназначена для него. Это не сделает ваших других клиентов счастливыми. Я брал довольно много звонков о том, что AP «убиваются» одним или двумя P2P-пользователями в ущерб остальным 60 платящим пользователям.

Если вы хотите попытаться контролировать его вместо блокировки, теперь у вас еще и использование ресурсов очередей, и тот факт, что вы вступаете в гонку вооружений, в которой обычно будете проигрывать. Просто чтобы попытаться выровнять ситуацию, вам придется устанавливать каждую новую версию O/S, которая выходит, и молиться, чтобы вас не затронул какой-нибудь баг, который отключает ваш AP. О, да, при сжигании большего количества ресурсов для блокировки/контроля, вы также уменьшаете количество клиентов, которых вы можете поддерживать через этот AP. Если у них CPE112 с ограниченной памятью в качестве клиента, или какое-то CPE с аналогичными проблемами, вы также получите больше звонков в службу поддержки с жалобами на то, что их CPE умирает или они не могут просматривать веб-страницы, все потому, что таблица соединений CPE заполнена P2P-соединениями.

P2P-трафик влияет на все области вашей сети и компании, иногда способами, которые вы не осознаете. Сколько стоит ваше время? Достаточно, чтобы вступить в гонку вооружений с разработчиками P2P-приложений? Достаточно, чтобы пришлось обновлять оборудование или добавлять больше AP, чем вам ожидалось? Это грязный бардак, и он будет только ухудшаться по мере того, как легитимные варианты использования P2P будут становиться все более распространенными.

Ну, правда ли вам нужно отслеживание соединений на CPE? Выключите это и сэкономьте себе кучу ресурсов хотя бы там. Если вы блокируете p2p непосредственно на CPE, то, возможно… Сэм.

У нас тоже проблемы с P2P, используем M$ ISA за нашим Mikrotik, чтобы пытаться блокировать. И даже сейчас некоторые люди где-то тут и там скачивают торренты. Хорошо, что наш провайдер ограничивает скорость трафика (я живу в Южной Африке). Так что шанс, что P2P убьёт линию, довольно небольшой. Общая скорость, в среднем, 10 КБ/с на линии 1 Мбит/с.

Да, я могу формировать трафик и блокировать практически любой P2P. Вот полное руководство: http://gentoo-wiki.com/HOWTO_Packet_Shaping. Если вы хотите формировать трафик, вам придется пропатчить исходный код ядра IMQ-патчем. После этого нужно будет настроить свои правила для QOS. Если вы хотите уметь помечать P2P-трафик, вам придется пропатчить iptables L7-фильтром. Таким образом, вы сможете помечать P2P-трафик, направлять его в IMQ и "замедлять" или просто отбрасывать. В любом случае, все написано в этом FAQ. Если вам просто нужно отбрасывать весь p2p-трафик, IMQ не нужен. В конце концов, все вышеперечисленное — это много работы, чтобы сделать и правильно настроить. Если вам ЭТО ДЕЙСТВИТЕЛЬНО не нужно, не делайте этого, вы потратите массу времени и сил. Это есть в Mikrotik, но, думаю, Mikrotik не "распознает" пакеты так же хорошо, как iptables+L7.

Похоже, зашифрованная P2P-ширина канала не видна для очередей Mikrotik. Верно, отчасти. Зашифрованный биторрент виден MT, но, как и с некоторыми другими P2P-протоколами и их обнаружением, можно просто отбросить его и не ограничивать ширину канала P2P-соединений. Причина проста: у тебя нет способа пометить пакеты как "это зашифрованные пакеты биторрента", поэтому нельзя форматировать их позже.

Заглянем на интерфейсы, и увидим 3 Мбит/с трафика, но в простых очередях происходит только 20 Кбит/с. Это может быть вызвано другими вещами – например, прямой связью между связанными клиентами. Ты делал default-forwarding=no? Если нет, твои радиоклиенты могут общаться напрямую друг с другом без ведома твоего сервера.

Запуск torch показывает IP-адреса, ответственные за ширину канала, и дальнейшее ограничение этих IP-адресов не оказывает никакого эффекта. Так что не только P2P-ширину канала нельзя снижать скорость, ее даже нельзя форматировать! Эти утверждения совершенно неверны. Ты можешь ограничивать / форматировать любой трафик, P2P или не P2P, зашифрованный или не зашифрованный. Если форматирование не работает для тебя, ты точно что-то делаешь не так.

Две вещи: а) если ты пытаешься форматировать некоторый трафик до очень низкой ширины канала, например 30 Кбит/с, формирователь не способен форматировать это очень точно и именно. б) ты не можешь форматировать зашифрованные P2P-протоколы. Это для чего и существует шифрование – чтобы скрыть реальное содержимое от тебя. в) форматирование P2P до очень низких чисел не работает точно и может показаться, что оно вообще не работает. P2P – это, безусловно, самое большое неудобство за последние годы, и мы боремся с ним день и ночь. Есть некоторые частичные решения: ограничивать каждого клиента шириной канала, которую он купил. Если ты продал ему 512 Кбит/с, ограничивай его линию до этих чисел и позволь ему делать, что хочет. Хочет скачать п0рн? Окей, пусть скачивает. Хочет использовать P2P? Ладно, ты должен быть к этому готов.

Конечно, это вносит ещё одну вещь: тебе нужен разумный коэффициент перепродажи. Если ты продал своим клиентам 100-мегабитные соединения, а у тебя всего 10 Мбит/с интернет-соединения, ты ничего хорошего не заслуживаешь. Учитывай трафик каждого клиента с помощью /ip accounting (очень-очень сложно собрать, скачивать с сервера, обрабатывать и находить решение) или /ip traffic-flow. Экспортируй номера traffic-flow на какое-нибудь устройство для сбора NetFlow и анализируй, что ты собрал. Ты можешь затем делать отчеты – ежедневное использование, недельное использование по клиенту и т.д.

Эх, длинный пост. Извини.

Божечки, ну я просто выдохлась, пока читала эту тему! Слишком долго для такой проблемы! Так, САМА ПРОБЛЕМА: опция p2p=all-p2p имеет проблемы с некоторым зашифрованным p2p-трафиком (невозможно найти какой-то "шаблон" в этом трафике, а значит и невозможно их определить как p2p!). МОЁ РЕШЕНИЕ: я разделила трафик для каждого клиента на 3 группы: (a) стандартные_сервисы (HTTP, FTP, DNS, почта, ICMP, VPN, Telnet, ssh, HTTPS, SFTP) (b) стандартный_p2p (без шифрования) © другой трафик (Skype, VOIP, зашифрованный p2p и прочее). Для группы © я создала очередь SFQ (САМОЕ РЕШЕНИЕ) и установила на неё ограничение! ОБЪЯСНЕНИЕ: У некоторых клиентов были проблемы со связью VOIP, потому что зашифрованный трафик создавал слишком много соединений для очереди группы © (SFQ разбивала доступный трафик на слишком много равнозначных кусков). Мне поступали жалобы, и мой ответ был простым: "Пожалуйста, отключите шифрование на вашем p2p и на вашем VOIP. Skype, онлайн-игровой сервер будут работать отлично!"