MaxHero

Я не http-proxy имел ввиду, а т.н. ретрекер-прокси Т.е. локальный ретрекер, получая запрос на определенную раздачу, в свою очередь отправляет такой же запрос (но от своего ip) ретрекерам-соседям, далее объединяем ip-шники сидеров/личеров ретрекеров-соседей плюс ip-шники локальных сидеров/личеров и отдаем ответ.

Я бы все таки поставил локальный ретрекер и настроил прокси на соседей, но если не знаете как организовать подобное, то делайте, как написано на хабре.

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

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

Если дропать все p2p соединения, то вы решаете только пол беды. В настоящее время большинство BitTorrent клиентов поддерживают шифрованные соединения (протокол PHE). Так вот правило drop all p2p их не режет. Единственный метод сделать это: создать регексп в L7 на определение подобных шифрованных соединений. Единственное но: не только BitTorrent использует подобный метод шифрования, поэтому возможна блокировка "нормальных" соединений. Кроме того L7 - фильтр дает очень большую нагрузку на микротик. С другой стороны, резать все исходящие соединения по протоколам UDP и TCP на порты, большие, ч

а L7 ? Даже в L7 не все необходимые соединения определяются, как bit-torrent, т.к. в uTorrent'е, например по-умолчанию разрешено установление/прием шифрованных соединений. Я когда-то смотрел спеки этого шифрованного протокола, так там все гораздо сложнее и обычными регэкспами не обойдешься, кроме того на детектирование подобных соединений система будет тратить значительные ресурсы, т.к. постоянно нужно будет декодировать поток данных с динамически изменяющимся ключем.

В микротике в фаерволе при создании правил есть опция P2P. Указываем там bit-torrent. Только это спасет от нешифрованных соединений. Шифрованные по прежнему будут бегать (в uTorrent вроде включена такая опция по-умолчанию).

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

Не, не, не. Если с ICMP еще такое прокатит, то с UDP такое делать нельзя. Например, торренты юзают UDP протокол. Вот представьте себе ситуацию: пришел первый пакет (аутентификация) с ip-адреса, например 100.100.100.100. Мы отвечаем на этот адрес. Далее приходит пакет (данные) с адреса 200.200.200.200 - такой адрес у нас аутентификацию не проходил, следовательно - это UDP флуд, мы на него не отвечаем. Таким образов, данные, не уложившиеся в один пакет UDP могут быть не обработаны получателем. Кстати, почему подобный метод не стоит делать и с ICMP: мы даже трассировку нормальную не сделаем,

То что так правильно - я не спорю, а как быть с UDP, ICMP трафиком? Ведь для UDP и ICMP понятия установки соединения не существует По поводу проброса 4 каналов в тунеле - сам не пойму как сделать получше - видимо только VLAN тут поможет. Я бы все таки делал балансировку на микротике. Насчет интерфейсов, увы, ничем не помогу, т.к. я работал только с обычными PC, на которые ставился микротик. С аппаратными микротиками дел не имел. Вот тут когда - то читал по поводу балансировки, мне помогло.

Самое сложное - сделать правильную балансировку каналов. У меня не получалось на микротике завести балансировку в зависимости от текущей нагрузки канала Я делал следующим образом: в фаерволе создавал 2 списка ip-адресов. Далее каждый пакет проверялся на адрес назначения, если этот адрес находился в первом списке ip-адресов, то маскарадил на первый канал, если адрес назначения во втором списке ip-адресов, то маскарадил на второй канал. Если же ip-адрес не в первом и не во втором списке, то тогда с вероятностью в 50% помещал адрес в первый список ip-адресов и маскарадил на первый канал, в проти

ИМХО, идея не бред. Надо посмотреть (сетевым снифером) что делает авторизатор (куда какие пакеты шлет, с кем устанавливает соединения) и сделать аналогию на php. Если есть знания в c++, то можно сделать консольное приложение-авторизатор и залить его в роутер.