Добрый день.
Возникла проблема следующего содержания: необходимо, чтобы ретрекером могли пользоваться только пользователи из определенной подсети.
Если рассматривать более широко, то проблема заключается в следующем: у пользователя может быть 2 IP - белый внешний и внутрисетевой. Если клиент пользователя производит обмен через внешний адрес, то идет нагрузка на интернет-шлюз.
Подскажите, пожалуйста, что можно предпринять в сложившейся ситуации?

Вообще-то ретрекер для этого и ставиться. Если вы ставите все по инструкции, то у вас ретрекер должен иметь вид хттп://вашлокальныйИП:2710/анноунс, соответственно он будет виден только тем, кто входит в вашу локальную сеть.
Если все равно не понятно- пишите, попробуем объяснить.

Вы пропишите в ностройках вашего веб-сервера что урл анонс адрес или полностью хост будет доступен только с локальных ип

Да, эта проблема решена, ретрекер виден только из нашей сети. С этим проблем не возникает.
Проблема заключается в следующем: клиенты обмениваются белыми IP-адресами, вместо серых. То есть (насколько я понимаю саму идею ретрекера) пользователь A отдает ретрекеру свой адрес. после этого все подключившиеся к ретрекеру пользователи получают этот адрес и добавляют его в список своих источников, после этого они начинают обмениваться с пользователем А по локальному трафику. Однако, если пользовательский клиент отдает ретрекеру свой БЕЛЫЙ адрес, то есть адрес, который используется для выхода в интернет, то обмен информацией происходит через главный шлюз, что создает большую нагрузку на сервер шлюза. задача: избежать передачи пользователями информации по белым адресам. То есть если пользователь передает ретрекеру белый адрес (т.е. не из указанной подсети), то ретрекер должен отказать в соединении.
Возможно ли это каким-то образом реализовать?

Вы говорите про белые и серые адреса или про внешние и внутренние? Если ретрекер правильно настроен, то он не будет выдавать внешние адреса. Может быть неправильно хост привязали. Какой адрес ретрекера?

Да, именно внешние и внутренние. Прошу прощения, не подумал, воспользовался терминологией нашего главного администратора
Система такая: подключение происходит через VPN, поэтому у пользователя в некоторый момент времени может быть 2 IP-адреса (внутренний, в подсети 10.0.x.x и внешний в подсети 62,x,x,x). Весь трафик, который передается по внешнему адресу идет через шлюз и из-за этого создает нагрузку.
Если наблюдать за списком пиров, участвующих в передаче, то там можно увидеть как внутренние, так и внешние адреса, обмен информацией с которыми происходит явно на локальных скоростях, однако трафик с белых адресов идет через шлюз. Что делать?
Адрес у ретрекера - внутренний, насколько я помню, не имеет внешних интерфейсов, юзеры указывают announce-адрес внутренний.

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

Проблему то мы определили уже давно. Сложность вот в чем получается: когда 2 пользователя A, с IP-адресом 62.34.81.32 (вымышленный, главное, что внешний) и B с адресом 10.0.4.79 (внутренний) обмениваются информацией, в этом процессе участвует сервер. Что, естественно, создает большую нагрзку, т.к. пользователи качают через ретрекер очень много.
Обмен происходит именно с нашими пользователями, т.к. адреса из нашей подсети и скорости локальные.
Однако при скачивании через ретрекер наблюдается обмен инф. как с внешними адресами, так и с внутренними.
Насколько я понимаю, проблема заключается именно в том, что торрент-клиенты некоторых пользователей представляются ретрекеру с белых адресов, т.е. говорит, мол, мой адрес 62.x.x.x и ретрекер не знает, что у него есть еще и внутренний адрес. Такие запросы нужно "разворачивать" и не принимать.

А почему вы тогда не сделаете чтобы ретрекер слушал только внутри сети? Какие-то сложности?

да. Не нашел, где это настраивается..

Да хоть файерволом, этого уже будет достаточно.

Вы не понимаете проблемы. Клиенты то коннектятся к ретрекеру по внутреннему адресу, однако сообщают ему свой белый адрес. То есть фаервол тут не поможет, нужно настроить сам ретрекер

либо:
а) ретрекер все таки виден снаружи, куда и конектятся юзеры (может днс-ки прописаны коряво или кто то сам прописал на компе личный днс сервер - к примеру opendns, либо вирусы прописали..)
б) сами клиенты сообщают внешний ип (в клиентах прописан проброс портов\либо кто то вручную вбил ип - "сообщать трекеру ип" и т.д)

от 2-го можно попробовать включить (если пхп-шный ретрекер) в конфиге:


либо тупо не давать записывать внешние адреса в ретрекер примерно таким условием:

Спасибо, именно такое решение и требовалось. Но проблема: куда это вписать? Ретрекер xbtt.

"я его в глаза не видел" - как говорят в одессе ))
я пользую пхп-шный (http://code.google.com/p/re-tracker/)

у меня вот другой вопрос - можно ли научить пхп-шный ретрекер распознавать внутренний ip адрес клиента который находится за NAT?

апд: можно! и этот модуль называется "realip_module" - $_SERVER['HTTP_X_REAL_IP'];
но не на всех хостингах он включен - зато можно без спросу добавлять частный адрес и не париться )))

А почему вы об этом сообщаете чуть ли не в конце страницы? Примите к сведению - такие вещи пишут сразу, в первом же сообщении.

Для xbtt такое решение кнечно не подойдёт, но там есть настройка:

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

В том-то и дело, например в nginx он вообще не включен и чтобы включить нужно гуглить и читать мануал.

Прошу прощения.. Я не знал о существовании других ретрекеров
спасибо за помощь. установили этот ретрекер на php.. пока пробуем..