MaxHero
Content Type
Profiles
Forums
Calendar
Posts posted by MaxHero
-
-
Я бы все таки поставил локальный ретрекер и настроил прокси на соседей, но если не знаете как организовать подобное, то делайте, как написано на хабре.
-
Спасибо тут что нужно, но редактировать до себя для мен проблемно.
Возможно еще кого єто за интеррисует и поможет?
Я так понял нужно сделать
1- Поднять middleman (прозрачній прокси)
2- Пототом передать все перловскому скрипту (http://pastie.org/700734) который среди всего выделяет запросы на трекеры.
И потом закидываем ИП адресса трекеров в таблицу
Как я еще понял, пункт 1-2 можно сделать разово. или не часто.
3- При попытке запроса на трекет, делаем редирект на middleman который через скрипт называется external в mman.xml. Передает инфу другому скрипту.
4- Скрипт mypatcher.pl уже делает подмену, дописывая нужные нам ретрекеры.
Хоть тут я правельно понял способ работы?
Да, все верно.
Но данный способ все таки плох с точки зрения нейтральности к передаваемой пользователями информации. По сути вы вмешиваетесь в информацию, которую пользователи вытягивают из сети, что не есть хорошо. Кроме того, если пользователь каким-либо способом уже получил .torrent - файл (друг принес на флешке и т.д.), то адресов ретрекеров в таком файле не будет. Также, некоторые трекеры по тем или иным причинам не добавляют в список трекеров retracker.local. А данный способ насильно этот ретрекер добавит.
Также существует еще одна проблема: т.к. ваш ретрекер должен будет обслуживать не только внутреннюю сеть но и внешнюю (сети партнеров), то вам придется ретрекер открыть наружу, таким образом в течение времени у ретрекера будут появляться пиры не только из вашей сети. Придется либо грамотно фильтр настраивать (чтобы попадали только пиры из вашей сети и сетей партнеров, а остальные дропались), либо никаких гарантий, что в список пиров не попадут пиры из остального интернета. Это очень важный момент, т.к. в течение времени ретрекер может превратиться в помойку (будет смесь из пиров внутренней сети и остального интернета)
При всех равных, сделать прокси-ретрекер, ИМХО, решение более разумное, но сложнее. Если не секрет, какой ретрекер используете?
-
Советую почитать хабру, там как раз ребята решали схожую с вашей проблему путем редактирования .torrent файлов на лету на прокси-сервере.
Ну или как вариант, если у вас ретрекер на php-движке, то немного его модифицировать таким образом, чтобы при запросе на этот ретрекер из локальной подсети, он отдавал не только своих пиров, но и запрашивал пиров с ретрекеров соседних сеток и тоже их отдавал. Так сказать прокси-ретрекер будет
-
Если дропать все p2p соединения, то вы решаете только пол беды. В настоящее время большинство BitTorrent клиентов поддерживают шифрованные соединения (протокол PHE). Так вот правило drop all p2p их не режет. Единственный метод сделать это: создать регексп в L7 на определение подобных шифрованных соединений. Единственное но: не только BitTorrent использует подобный метод шифрования, поэтому возможна блокировка "нормальных" соединений. Кроме того L7 - фильтр дает очень большую нагрузку на микротик.
С другой стороны, резать все исходящие соединения по протоколам UDP и TCP на порты, большие, чем 10000 - тоже не вариант. Выше уже написали, что это негативно сказывается на играх и скайпе. Опять же как вариант - можно контролировать pps на каждом таком соединении и общее кол-во соединений (например pps на соединение не более 20, чего с головой хватит для игр и скайпа, и максимум 30 соединений) Таким образом http и ftp у нас будут летать, т.к. по pps и кол-ву соединений мы их не ограничиваем, а прочие протоколы будут лимитированы. Это не позволит качкам-торрентоводам забить канал.
-
торенты частично микротик шейпает, однако если включен протокол toredo,в win7 вроде он по умолчанию...то с этим протоколом вообще ничего не сделается.
а L7 ?
Даже в L7 не все необходимые соединения определяются, как bit-torrent, т.к. в uTorrent'е, например по-умолчанию разрешено установление/прием шифрованных соединений. Я когда-то смотрел спеки этого шифрованного протокола, так там все гораздо сложнее и обычными регэкспами не обойдешься, кроме того на детектирование подобных соединений система будет тратить значительные ресурсы, т.к. постоянно нужно будет декодировать поток данных с динамически изменяющимся ключем.
-
юзери валять wifi-БС торентами з їх неуловимими socket'ами. Один перекриваєш, піднімається інший. Підкажіть, якщо хтось мав таку халепу.
В микротике в фаерволе при создании правил есть опция P2P. Указываем там bit-torrent. Только это спасет от нешифрованных соединений. Шифрованные по прежнему будут бегать (в uTorrent вроде включена такая опция по-умолчанию).
-
Прошу прокоментировать Вашу точку зрения, есть ли смысл делать подключение равным нулю, если присутствует минимальная конкуренция на рынке? На сколько это увеличивает прибыль? отпугивает или заманивает новых пользователей?
Из личного могу сказать: было бесплатное - подключались, сделали 100 грн - подключаются не чем не хуже. Но 100 грн на дороге не валяются, грубо говоря зп для одного рабочего в день...
Рад буду выслушать все за и против!
Считаю, что нельзя делать подключение бесплатным, если нет в этом крайней необходимости. Конкуренты тоже спать не будут, сделают подключение бесплатно. Так если в вашей сети есть возможность уйти абоненту в небольшой минус (кредит), то в спорных ситуациях (например летом был на море, забыл приостановить услугу) абонент без раздумий уйдет к конкуренту (подключение то бесплатное), чем оплатит долг. Такой нынче абонент пошел
-
MaxHero, Спасибо большое за ответ. Для UDP, ICMP все проще. Просто пропорционально шлем пакеты в разные каналы и все. С ТСР все сложнее. Тем же вконтакте.ру очень не нравится, что http-сесии открываются то с одного айпи, то с другого и они просят повторно авторизироваться.
Не, не, не. Если с ICMP еще такое прокатит, то с UDP такое делать нельзя. Например, торренты юзают UDP протокол. Вот представьте себе ситуацию: пришел первый пакет (аутентификация) с ip-адреса, например 100.100.100.100. Мы отвечаем на этот адрес. Далее приходит пакет (данные) с адреса 200.200.200.200 - такой адрес у нас аутентификацию не проходил, следовательно - это UDP флуд, мы на него не отвечаем. Таким образов, данные, не уложившиеся в один пакет UDP могут быть не обработаны получателем.
Кстати, почему подобный метод не стоит делать и с ICMP: мы даже трассировку нормальную не сделаем, т.к. пакеты с разным ttl будут ходить по разным каналам - в конечном итоге получим неверную информацию о трассе.
-
Правильно делать пропрциональную балансировку с запоминанием на некоторое время открытых сессий. Только как это сделать...
На самом деле каналов 4, еще подключены напряму к FreeBSD.
Подскажи хотя бы как протащить в тунеле каналы с модемов, распределение нагрузки я могу и на фре сделать.
Просто нереально разобраться с этими настройками. Интерфейсов на микротике 5, мне нужно 3. Как отключить 2 остальных непонятно. Назначаю айпи на одном интерфейсе, его видно на двух. Вот такие вот странные ситуации...
Ткните носом хоть куда копать. Замучался уже воевать с этим микротиком...
То что так правильно - я не спорю, а как быть с UDP, ICMP трафиком? Ведь для UDP и ICMP понятия установки соединения не существует
По поводу проброса 4 каналов в тунеле - сам не пойму как сделать получше - видимо только VLAN тут поможет. Я бы все таки делал балансировку на микротике.Насчет интерфейсов, увы, ничем не помогу, т.к. я работал только с обычными PC, на которые ставился микротик. С аппаратными микротиками дел не имел.
Вот тут когда - то читал по поводу балансировки, мне помогло.
-
Доброго времени суток!
Никогда раньше не работал с микротиком, вот сейчас пришлось. Немогу разобраться.
Итак задача:
Есть Mikrotik RouterBOARD 750G
Есть 2 adsl модема к укртелекому в режиме роутеров (10.30.0.1/24 и 10.30.1.1/24).
Есть сеть пользователей 10.10.0.0/24.
Есть роутер с FreeBSD 10.10.0.1 в этой сети.
Задача:
На микротике реализовать динамичискую нагрузку обоих каналов. Все это дело запихнуть в pptp-тунелю к freebsd. При этом учитывать,что нужно запретить маршрутизировать трафик в интернет с порта микротика, который включен в локальную сеть.
Я это вижу так:
На микротике организовывается динамическое распределение нагрузки каналов (как сделать?).
На микротике поднимается pptp-server. FreeBSD вяжется к этому серверу и получает уже доступ в интернет.
На lan порту микротика файрволом закрывается все, кроме 1723 порта tcp, протокола gre и портов для управления микротиком (каких?). Или просто запрещается маршрутизация по этом порту (как такое реализовать?).
Настроек в сей коробочке нереально много. Уже второй день мучаюсь. Помогите пожалуйста.
Самое сложное - сделать правильную балансировку каналов. У меня не получалось на микротике завести балансировку в зависимости от текущей нагрузки канала
Я делал следующим образом: в фаерволе создавал 2 списка ip-адресов. Далее каждый пакет проверялся на адрес назначения, если этот адрес находился в первом списке ip-адресов, то маскарадил на первый канал, если адрес назначения во втором списке ip-адресов, то маскарадил на второй канал. Если же ip-адрес не в первом и не во втором списке, то тогда с вероятностью в 50% помещал адрес в первый список ip-адресов и маскарадил на первый канал, в противном случае помещал адрес во второй список ip-адресов и маскарадил на второй канал.Таким образом достигалась долее-менее равномерная нагрузка каналов. Пляски со списками необходимы для того, чтобы не выходило таких ситуаций, что с одним и тем же ресурсом каждый раз соединения будут идти с разных ip. Например, файлообменники этого очень не любят и нормально работать не будут. Если у вас каналы разных емкостей, например один - 4 мегабита, второй - 8 мегабит, то надо тогда выставлять другие проценты вероятностей помещения ip-адресов в списки - 34% и 66% для 4 и 8 мегабит.
Также некоторые делают балансировку в зависимости от адреса-источника. Т.е. часть абонентов сажают на один канал, остальных - на второй. Но тут есть проблема, что если в одной группе у нас одновременно начинают 2-3-4 абонента одновременно качать, например, торренты, то канал может легко забиться, в то время, как второй канал будет простаивать. Поэтому, ИМХО, правильнее делать балансировку в зависимости от адреса-назначения.
-
появилась идейка
на маршутизатор поставлю пхп сервер http://www.dd-wrt.com/wiki/index.php/Router_Dir-320_DD-WRT_%2B_WWW_%2B_PHP_%2B_MySQL_%2B_PERL
с помощью крона буду запускать скрипт на пхп (каждих 40 сек) какой будет авторизироваться на сайте (авторизирувался раз и 40 секунд инета
))) )интересно токо видержит ли марушизатор если я на него еще торент поставлю =)))))
если сделаю отпишусь
ИМХО, идея не бред. Надо посмотреть (сетевым снифером) что делает авторизатор (куда какие пакеты шлет, с кем устанавливает соединения) и сделать аналогию на php. Если есть знания в c++, то можно сделать консольное приложение-авторизатор и залить его в роутер.
Автоматическое дописывание ретрекеров.
in For people
Posted
Я не http-proxy имел ввиду, а т.н. ретрекер-прокси
Т.е. локальный ретрекер, получая запрос на определенную раздачу, в свою очередь отправляет такой же запрос (но от своего ip) ретрекерам-соседям, далее объединяем ip-шники сидеров/личеров ретрекеров-соседей плюс ip-шники локальных сидеров/личеров и отдаем ответ.