Пропускная способность Tor ноды


Я пользуюсь Tor больше 5 лет, держу несколько middle нод, как держал и много лет назад, но в последнее время замечаю несколько странностей в работе сети Tor, которым не вижу очевидного объяснения.
Первая странность – использование полосы. Раньше Tor использовал столько полосы сколько дадут, вплоть до гигабита, сейчас же началась какая-то странная фигня, некоторые ноды пропускают дикие объемы трафика, другие не нагружены вообще.
Одна из моих нод[link1], аптайм которой 2 недели, пропускает 0.7мбит трафика из 80 разрешенных, почему?
Другой пример вот эта[link2] нода, пропускает 33мбит из 40 разрешенных.
Что влияет на использование пропускной способности? Как правильно настраивать ноду чтобы она выжирала сколько сказано, не больше и не меньше? Зависит ли это от соотношения BandwidthRate/BandwidthBurst, от ORPort и DirPort, или от каких-нибудь других параметров?

Вторая странность – за последние коды соединения начали работать быстрее, я использую rdp через тор, тогда как раньше не мог к нему подключиться из-за черепашьей скорости. Но tor browser очень часто выдает "The connection was reset", причем не у меня одного, помогает смена ексита. Может в последних версиях Tor что-то сломалось?

Комментарии
Гость (30/11/2012 15:52)   
Зависит ли это от соотношения BandwidthRate/BandwidthBurst, от ORPort и DirPort, или от каких-нибудь других параметров?

Напрямую зависит от клиентов: в конечном итоге цепочку строят они. И ведь заметте – далеко не всегда выбирают по каким-то критериям будь то скорость, порты, или даже версия сервера и его ОС...(в качестве подтверждения посмотрите статистику и графики на torstatus.blutmagie.de torstatus.all.de torstatus.info)
Согласитесь, что последнее время наблюдается рост нодов(сейчас их около 3000), а года 2 назад было в 1,5-2 раза меньше. Как там дела обстоят с ростом популярности чисто клиентской части сказать трудно, но можно предположить что "матёрые" пользователи предпочитают для пущей маскировки запускать ноды, а новых появляется всё меньше из-за всенарастающих прочих анонимайзеров, пусть даже и менее безопасных, но зато удобнее приминимых и вполне подходящих под свои задачи. Возможно это и играет некую второстепенную роль в том что за последние годы соединения начали работать быстрее.
— SATtva (30/11/2012 16:37, исправлен 30/11/2012 16:39)   
Возможно это и играет некую второстепенную роль в том что за последние годы соединения начали работать быстрее.

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


Большинство улучшений описаны здесь[link3].

Гость (30/11/2012 18:24)   

Мне тоже интересен ответ на этот вопрос. Вот конкретно: почему?! Почему одни ноды рыжее других, в чём причина?
Гость (30/11/2012 19:20)   
Почему одни ноды рыжее других, в чём причина?

Может помимо объёма трафика учитывается количество обработанных запросов? Может в конфиге и это регулируется?
Гость (30/11/2012 20:10)   
[ZOG-версия]
Существенную часть трафика через Tor генерирует кто-то ОДИН, и он пропускает его только через ему подконтрольные ноды. Остальные ноды в пролёте.
[/ZOG-версия]
— unknown (30/11/2012 21:36)   


  • Запущены ли ноды у разных провайдеров? На разных виртуальных хостингах?
  • Включены ли ноды в опцию MyFamily?
  • если нода на обычном компьютере, не находится ли она за слабым роутером, который плохо держит большое количество соединений (хотя с массовой поддержкой торрентов это почти неактуально)?
  • Работают ли ноды на одном порту? Все ли ноды имеют и onion-порт, и порт зеркала директорий?
  • В приведённом примере медленная нода на Windows, быстрая на Linux — может ли что-то мешать в настройках ОС?
  • Что насчёт п.14[link4]? Или каких-то советов отсюда[link5]?
  • Замеряли ли трафик сами и сравнивали ли с тем, что выдаёт статистика с веб-узлов? Лучше из этого источника[link6].
Гость (30/11/2012 23:53)   
Запущены ли ноды у разных провайдеров?
У разных хостеров в разных ДЦ, все на выделенных серверах. Ни у одной трафик не доходит даже до половины лимита.

Включены ли ноды в опцию MyFamily?
Нет, не хочу лишний раз палить связь.

если нода на обычном компьютере, не находится ли она за слабым роутером, который плохо держит большое количество соединений
Все на выделенных серверах, на канале не менее 100мбит, некоторые на гигабите. Слабое железо да, бывает.

Работают ли ноды на одном порту? Все ли ноды имеют и onion-порт, и порт зеркала директорий?
Где как. Порты 80,443,9001,9030, зеркало директорий где есть а где нет.

В приведённом примере медленная нода на Windows, быстрая на Linux — может ли что-то мешать в настройках ОС?
Другие приложения, тот же торрент, утилизируют гигабит создавая тысячи соединений. Трансфер одиночного файла по ftp разгоняется до 200мбит.

Замеряли ли трафик сами и сравнивали ли с тем, что выдаёт статистика с веб-узлов?

Точные цифры из статистики atlas.torproject.org и torstatus.blutmagie.de, свой трафик по виндовому показометру околонулевой, хотя должен занимать не менее трети полосы.

Пример конфигурации одной ноды с почти нулевым трафиком:

Исходя из этой конфигурации, нода должна жрать 3*8*2=48 мегабит и в пиках 6*8*2=96 мегабит полосы, а реально жрет меньше мегабита. Что тут не так?
Гость (01/12/2012 21:05)   

Они там пишут[link7], что
If a user misuses the service, ie. by posting spam or otherwise illegal content, the owner of this IP address – usually the ISP – might be contacted to deal with this "abuse". The most efficient way for most ISPs to deal with it is to terminate contracts that attract abuse, and you might have a hard time explaining that you were not responsible for the abusive behavior.
Интересно, как скоро разработчики договорятся до того, что чтоб сделать Tor ещё теплее и ламповее, надо выработать единую политику блокировки сайтов на экситах, т.е. чтобы через Tor юзеры могли зайти только на кое-кому угодные сайты?


Выше написано, что
Раньше Tor использовал столько полосы сколько дадут, вплоть до гигабита
Могло ли что-то настолько концептуально поменяться в самом Tor с тех времён(?).
— SATtva (02/12/2012 13:02, исправлен 02/12/2012 13:02)   
Включены ли ноды в опцию MyFamily?

Нет, не хочу лишний раз палить связь.

Интересное кино. Не огласите ли список Ваших узлов, чтобы заинтересованные пользователи внесли их в свои блэклисты?

Гость (02/12/2012 20:42)   
Включены ли ноды в опцию MyFamily? Нет, не хочу лишний раз палить связь.
А она и сделана, чтобы меньше палить связь
That way clients will know to avoid using more than one of your relays in a single circuit. You should set MyFamily if you have administrative control of the computers or of their network, even if they're not all in the same geographic location.
translate.google.com в помощь
более оптимально
Старайтесь избегать этой распространенной ошибки
Гость (02/12/2012 20:52)   
Вот такую байду проверяли?
Sat Dec 1 04:34:22 2012 Время вашего компьютера возможно не верно. – Tor обнаружил, что часы вашего компьютера возможно спешат на 28972 секунд по сравнению с "OR:128.31.0.34:9101". Если ваши часы не правильны, Tor не сможет работать. Пожалуйста, проверьте что ваш компьютер показывает правильное время.
А нода под виндой не должна бы быть медленнее исходя из номеров ее портов, потенциальных то юзеров больше.
Гость (03/12/2012 00:18)   
Интересное кино. Не огласите ли список Ваших узлов, чтобы заинтересованные пользователи внесли их в свои блэклисты?
Уверяю вас, трафк на нодах не снифается и ничего плохого не делается.


Вот такую байду проверяли?
Часы выставлены правильно и в логах всё чисто. На всякий случай приведу полный лог одной ноды:

Судя по логу, никаких проблем не наблюдается, но трафик не идет. В чем может быть причина? Может у DA есть какие-то скрытые особенности распределения трафика по нодам?
Гость (03/12/2012 04:48, исправлен 03/12/2012 16:08)   
Интересное кино. Не огласите ли список Ваших узлов, чтобы заинтересованные пользователи внесли их в свои блэклисты?
Уверяю вас, трафк на нодах не снифается и ничего плохого не делается.

Не так. Смотри, как нужно топить:


Интересное кино. Не огласите ли список Ваших узлов, чтобы заинтересованные пользователи внесли их в свои блэклисты?

Ваш праведный гнев бы, да разрабам Tor в уши. Где ваше возумщение на /comment57954[link8]? Кто эти анонимные спонсоры? Почему пользователи Tor не должны знать, кто заказывает музыку? Где эти 125 пресловутых спонсорских нод? Они тоже будет помечены, как MyFamily? Ага, сейчас. DARPAм, CIAм и Navy есть чего боятся, им простительно нарушать правила, они же такие бедняги уязвимые, что пипец. А анониму, за которым на стоит могущественное государство, и который трясётся за свою задницу, бояться, конечно же, нечего. Всё логично. Пусть все знают где, на каких хостингах и какие сервера он крутит, откуда берёт на это деньги, зачем ему лично поддерживать Tor. Только ZOGу можно нарушать любые правила и соглашения, работать исподтишка, всем остальным — запрещено категорически. Если "заинтересованный пользователь" хочет заблеклистить кого-то, пусть блеклистит сразу весь Tor, т.к. проект, куда можно заплатить и вбросить столько нод, сколько хочешь, доверия не внушает.


И, вообще, где срач на эту тему? Где анонс в блоге Tor? Где вопли в рассылке? Где клятвенное покаяние Роджера? Все делают вид, что всё ОК, всё именно так и должно быть. Анонимные спонсоры. Анонимные сотни чьих-то нод. Анонимный Tor такой анонимный... только для кого?


С точки зрения такого взгляда вопрос, почему чьи-то ноды пропускают много трафика, а чьи-то мало, начинает играть другими красками[link9].

Гость (03/12/2012 04:54)   
А нода под виндой не должна бы быть медленнее исходя из номеров ее портов
В смысле, исходя из того, на каких портах слушает Tor в обсуждаемой виндовой ноде? Так-то количество доступных портов на машине стандартизировано независимо от ОС (0-65535).
Гость (03/12/2012 21:18)   
О Боже!, но я же не это имел в виду! Read The Fucking Manual!
11. If your computer isn't running a webserver, please consider changing your ORPort to 443 and your DirPort to 80. Many Tor users are stuck behind firewalls that only let them browse the web, and this change will let them reach your Tor relay. Win32 relays can simply change their ORPort and DirPort directly in their torrc and restart Tor. OS X or Unix relays can't bind directly to these ports (since they don't run as root), so they will need to set up some sort of port forwarding so connections can reach their Tor relay. If you are using ports 80 and 443 already but still want to help out, other useful ports are 22, 110, and 143.
После применения translate.google.com:
11. Если ваш компьютер не работает веб-сервер, пожалуйста, рассмотреть вопрос об изменении вашего ORPort в 443 и DirPort до 80. Многие Tor пользователи могут застрять позади брандмауэров, которые только позволяют им просматривать веб-страницы, и это изменение позволит им достичь ваш сервер. Win32 реле могут просто изменить свой ORPort и DirPort непосредственно в их torrc и перезапустить Tor. OS X и Unix реле не может связать непосредственно к этим портам (так как они не запускать с правами администратора), поэтому им нужно будет создать своего рода перенаправления портов, так соединения могут достичь своих ретранслятор. Если вы используете порты 80 и 443, но хотите помочь, другие полезные порты 22, 110 и 143.
Гость (03/02/2013 23:42)   
Кстати, заметили вброс странных нод количеством более сотни? Все в США, у всех 1Кб/с скорость, всем присвоено буквенно-цифровое наименование из 16 символов.
Всегда количество нод около 3000. 3000-3200 в среднем. Сейчас под 3500.
Что бы это могло означать?)
Гость (04/02/2013 01:37)   
Кстати, заметили вброс странных нод количеством более сотни?

Почему бы не написать в рассылку tor-or-talk, спросить?
Гость (04/02/2013 01:38)   
... а заодно спросить и про вброс этих[link10] нод.
Гость (04/02/2013 01:49)   

1 б/с (байт/с)
Много они нагенерят трафа. Суммарная пропускная способность 0,1 Кб/с... WTF?
А ведь уже 4 дня шумят.
Гость (04/02/2013 03:10)   
вброс странных нод количеством более сотни? Все в США, у всех 1Кб/с скорость, всем присвоено буквенно-цифровое наименование из 16 символов.

Кто-то запустил кучу экситов на ботнете*, но он дурак и не смог отобрать для этого подходящие машины. Там 95% на NAT-ах и, соответственно, совсем не работают.

Ничего хорошего такой вброс не несет. Качество таких нод очень низкое, сеть может начать глючить и тормозить. Имхо, стоило бы ввести регистрацию нод на сайте вручную, через капчу, хотя автоматическая установка ноды тоже бывает нужна. Предыдущий вброс прожил два дня[link11]. Интересно, сколько этот проживёт.

*Конфа везде одна, версия Tor одна, везде винда, IP разные из разных стран ⇒ ботнет 100%.
Гость (04/02/2013 04:32)   
Кто-то запустил кучу экситов на ботнете*
Нет, среди них ни одного экзита нет.

*Конфа везде одна, версия Tor одна, везде винда, IP разные из разных стран ⇒ ботнет 100%.
Версии и конфы идентичны, да, но везде не винда, а линух, IP разные, страна одна – США. Все на Амазоне хостятся.

Интересно, сколько этот проживёт.
Уже более 4 суток тормозит живет.
— unknown (04/02/2013 09:37, исправлен 04/02/2013 09:37)   
Качество таких нод очень низкое, сеть может начать глючить и тормозить.

Вероятность выбора узла зависит от его пропускной способности.


Все на Амазоне хостятся.

Чей-то очередной исследовательский проект?

Гость (04/02/2013 10:49)   
Много они нагенерят трафа.

Всё не так уж и без облачно[link12]. Пока непонятен целиком весь замысел, но картину уже портят.
— unknown (04/02/2013 11:16, исправлен 04/02/2013 11:17)   

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

Гость (04/02/2013 11:44)   
А, так у них быстрые вычисляются в зависимости от процентов узлов всей сети?

Да.
Тогда после такого вброса (если нет допустимой нижней границы) каждый заурядный узел может получить статус быстрого и сторожевого? Может замысел в этом?

Получит каждый узел флаги всех статусов, и? Какая может быть разумная цель в этом?
— SATtva (04/02/2013 11:52)   
Как минимум, proof-of-concept, что общесетевую статистику крайне легко исказить. При обсуждении многих атак иногда апеллируют к тому, что некоторые сценарии могут быть экономически нецелесообразны, т.к. не каждый первый узел способен стать, например, сторожевым — требуется удовлетворение условиям стабильности и пропускной способности. А тут мы видим, что выполнение этого второго условия (по идее, более затратного) на самом деле тоже ничего не стоит.
— unknown (04/02/2013 12:10)   
Если параноить дальше, то резкие откаты статистики могут косвенно облегчать, например, раскрытие скрытых сервисов. Которым придёться перестроить цепочки и точки встречи, после того, как всё нормализуется. И кстати, сторожевые для них тоже критичны.
Гость (04/02/2013 12:11)   
А ведь уже 4 дня шумят

Нельзя доверять информации из дескриптора. Может узлы и запущены 4 суток, но в сети они могут быть известны только с момента появления в консенсус-документе. И там они появлись только 3 февраля в час ночи по гринвичу.
Гость (04/02/2013 12:25)   
не каждый первый узел способен стать, например, сторожевым — требуется удовлетворение условиям стабильности и пропускной способности. А тут мы видим, что выполнение этого второго условия (по идее, более затратного) на самом деле тоже ничего не стоит.

Флаг со статусом Fast на самом деле мало что решает. Все определяется скоростью, которую замеряют корневые директории. Fast это такой рудимент из прошлого, в современности клиент просто не использует узел без этого статуса. Если рассмотреть амазоновские узлы, то их клиент всё равно использовать не сможет, потому как в килобайтах получается 0.
— SATtva (04/02/2013 12:38)   
Суть не в этом. Если я правильно понял, это искажение статистики привело к тому, что изменился вес всех прочих узлов сети, даже если их скорость была не многим выше нуля. Соответственно, получить статус гарда в такой ситуации потенциально может первый встречный (при достаточной стабильности узла, разумеется).

Но легко может быть, что я ошибаюсь.
— unknown (04/02/2013 12:45)   
И если пока это действительно может затормозить сеть, то далее может вынудить при отктатывании статистики к нормальному виду порвать соединения с этими временными гвардами-самозванцами.

А это нежелательная флуктуация для анонимности пользователей и HS.
Гость (04/02/2013 13:39)   
Нельзя доверять информации из дескриптора. Может узлы и запущены 4 суток, но в сети они могут быть известны только с момента появления в консенсус-документе. И там они появлись только 3 февраля в час ночи по гринвичу.
Вероятно, что да. Были обнаружены только вчера. Ранее замечены не были.
Кстати, коллега звонил и поделился следующей картиной. У него скорость соединения через Tor временами падала до нескольких бит/сек. Я говорю, может попал на медленную ноду? Так вот, скорее всего, было попадание на один из этих узлов, если их фактическая пропускная способность действительно <1 б/с. Правда, там есть и помимо этих медленные ноды. Но их скорость начинается от нескольких Кб/с.
Между тем, за ночь их число удвоилось (вот пример для ВВП) и составляет в настоящее время более 230 узлов...

Они уже здесь!
Гость (04/02/2013 13:49)   
Если я правильно понял, это искажение статистики привело к тому, что изменился вес всех прочих узлов сети, даже если их скорость была не многим выше нуля. Соответственно, получить статус гарда в такой ситуации потенциально может первый встречный (при достаточной стабильности узла, разумеется).

Достаточно стабильный уже не первый встречный :) Внезапно, гардом можно стать без этой атаки, просто изобразив скорость в дескрипторе. Главное не скорость, а стабильность, которую узел изобразить не в состоянии. При этом клиент будет выбирать по скорости которую измеряют корневые директори, а не изображает сам узел.
— unknown (04/02/2013 14:00)   

И гард-флаг ему присваивать будут тоже они, проверив скорость, так что сами по себе его претензии на желание быть гардом без консенсуса от DA, просто манипулируя цифрами скорости в дескрипторе, останутся для клиентов незамеченными.
Гость (04/02/2013 14:12)   
И если пока это действительно может затормозить сеть, то далее может вынудить при отктатывании статистики к нормальному виду порвать соединения с этими временными гвардами-самозванцами.

В данном случае важней факт внедрения в сеть тысяч подконтрольных противнику узлов, чем игры с флагами.
Гость (04/02/2013 14:14)   
И гард-флаг ему присваивать будут тоже они, проверив скорость

Не проверяют они скорость. Вот в чем фокус. Аптайму не верят, а скорости при назначении на роль быстрого или охранника верят.
— unknown (04/02/2013 14:23)   
Ну это бага какая-то. Раз для статистики для клиентов скорость проверяется, то почему для флагов в консенсусе это не так?
Гость (04/02/2013 14:29)   
Раз для статистики для клиентов скорость проверяется, то почему для флагов в консенсусе это не так?

Хороший вопрос.
Гость (04/02/2013 14:44)   
В данном случае важней факт внедрения в сеть тысяч подконтрольных противнику узлов
Не преувеличивайте. Не тысяч, а сотен. В части противника тоже есть вопросы. Хотя на благие намерения этот вброс не похож.
Я уже послал охранника сгонять за пивом за попкорном.
Гость (04/02/2013 14:56)   
У меня есть теория об ошибке в скрипте который формировал конфиги для этих узлов, верю я в доброе и светлое в людях. Амазон часто рекламили в блоге для запуска бриджей. Сотня бриджей это было в задумке, а скорость в 1 байт и попадание в публичную сеть это случайная ошибка.
Гость (04/02/2013 15:02)   

Подождем, что скажут Вести24 в новостях.
— unknown (04/02/2013 15:17)   

Пока что ваше мнение не разделяют:
https://trac.torproject.org/projects/tor/ticket/8151
Гость (04/02/2013 22:35)   

Отображается то 116 узлов, то 232. Как когда. 0 б/с скорость сейчас. Всего 3522 ноды онлайн. Вброшенные ноды составляют около 6% сети. Стремительный рост. Завтра их будет уже 464?
— unknown (05/02/2013 09:38, исправлен 05/02/2013 10:25)   

Скоро[link13] будет обновление и эту вакханалию прикроют.
Причём, сама потенциальная уязвимость была опубликована[link14] два года назад.


Собственно, альфа-версия[link15] уже закрывает этот[link12], этот[link16] и этот[link17] баг.



Помимо исправления данной ошибки, туда также опционально внедряют протокол[link18] односторонней анонимной аутентификации Диффи-Хеллмана на эллиптических кривых.


А ещё на скрытых сервисах можно будет открывать виртуальный хостинг: http://foo.aaaaaaaaaaaaaaaa.onion/ и http://bar.aaaaaaaaaaaaaaaa.onion/ будут двумя разными вебсайтами на одном скрытом сервисе.

Гость (07/02/2013 06:25)   
Извиняюсь за ламерский вопрос, но как DA может надёжно измерить скорость Tor-ноды?
— unknown (07/02/2013 09:56)   
Прокачивая через неё трафик.
Гость (08/02/2013 00:26)   
Извиняюсь за ламерский вопрос, но как DA может надёжно измерить скорость Tor-ноды?
Прокачивая через неё трафик.

Ну, вот нода и будет отдавать при проверках со стороны DA одну скорость, а реально иметь другую, это открытая дыра для мошенничества со стороны ноды.
— unknown (08/02/2013 09:34, исправлен 08/02/2013 09:35)   

Периодически через разные цепочки? Надо точнее смотреть, как это реализовано, но наверное такие тривиальные случаи предусмотрены. Потому что борьба с махинациями при выставлении параметров ноды обсуждалась ещё в самом начале реализации проекта. Хотя, как видим, могли что-то и пропустить.

Гость (10/02/2013 04:07)   
Периодически через разные цепочки?

Ну, не знаю, как они там проверяют. Если DA будет строить цепочку через нужную ноду, скорость будет ограничена не только нодой, но и скоростями других нод в цепочке, к которым тоже надо откуда-то брать доверие. Короче, это какая-то самосогласованная система с непонятными, но, возможно, вполне существующими методами вывода её из равновесия.
Гость (12/09/2013 00:37)   
TorProject выступил с объяснением всех чудес с пропускной способностью Tor-нод: «The lifecycle of a new relay»[link19].

Ссылки
[link1] http://torstatus.blutmagie.de/router_detail.php?FP=069bacf26ed3268a8c54a429cf2153fca30ee9b3

[link2] http://torstatus.blutmagie.de/router_detail.php?FP=cef71e9cb5dc9cfcc9ad9d47a602c6c4616e26e7

[link3] http://www.pgpru.com/biblioteka/statji/8y

[link4] https://www.torproject.org/docs/tor-doc-relay.html.en

[link5] https://www.torservers.net/wiki/setup/server

[link6] https://metrics.torproject.org/relay-search.html

[link7] https://www.torservers.net/about.html

[link8] http://www.pgpru.com/comment57954

[link9] http://www.pgpru.com/comment58540

[link10] http://www.pgpru.com/comment58604

[link11] http://www.pgpru.com/comment40207

[link12] https://trac.torproject.org/projects/tor/ticket/8145

[link13] https://trac.torproject.org/projects/tor/timeline?from=2013-02-05T05:33:28Z&precision=second

[link14] https://trac.torproject.org/projects/tor/ticket/2286

[link15] https://lists.torproject.org/pipermail/tor-talk/2013-February/027233.html

[link16] https://trac.torproject.org/projects/tor/ticket/8146

[link17] https://trac.torproject.org/projects/tor/ticket/8147

[link18] https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/216-ntor-handshake.txt

[link19] https://blog.torproject.org/blog/lifecycle-of-a-new-relay