Пропускная способность 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 что-то сломалось?
Ссылки
[link1] http://torstatus.blutmagie.de/router_detail.php?FP=069bacf26ed3268a8c54a429cf2153fca30ee9b3
[link2] http://torstatus.blutmagie.de/router_detail.php?FP=cef71e9cb5dc9cfcc9ad9d47a602c6c4616e26e7
[link3] https://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] https://www.pgpru.com/comment57954
[link9] https://www.pgpru.com/comment58540
[link10] https://www.pgpru.com/comment58604
[link11] https://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
Напрямую зависит от клиентов: в конечном итоге цепочку строят они. И ведь заметте – далеко не всегда выбирают по каким-то критериям будь то скорость, порты, или даже версия сервера и его ОС...(в качестве подтверждения посмотрите статистику и графики на torstatus.blutmagie.de torstatus.all.de torstatus.info)
Согласитесь, что последнее время наблюдается рост нодов(сейчас их около 3000), а года 2 назад было в 1,5-2 раза меньше. Как там дела обстоят с ростом популярности чисто клиентской части сказать трудно, но можно предположить что "матёрые" пользователи предпочитают для пущей маскировки запускать ноды, а новых появляется всё меньше из-за всенарастающих прочих анонимайзеров, пусть даже и менее безопасных, но зато удобнее приминимых и вполне подходящих под свои задачи. Возможно это и играет некую второстепенную роль в том что за последние годы соединения начали работать быстрее.
Сильно второстепенную. Разработчики потратили уйму сил на оптимизацию процесса выбора узлов для цепочки, чтобы не создавать бутылочное горлышко из высокоскоростных, на сам процесс построения (optimistic connections, при которых данные начинают передаваться до получения положительного отклика от узла) и т.д. То есть сеть сейчас более оптимально использует свои ресурсы.
Большинство улучшений описаны здесь[link3].
Мне тоже интересен ответ на этот вопрос. Вот конкретно: почему?! Почему одни ноды рыжее других, в чём причина?
Может помимо объёма трафика учитывается количество обработанных запросов? Может в конфиге и это регулируется?
[ZOG-версия]
Существенную часть трафика через Tor генерирует кто-то ОДИН, и он пропускает его только через ему подконтрольные ноды. Остальные ноды в пролёте.
[/ZOG-версия]
У разных хостеров в разных ДЦ, все на выделенных серверах. Ни у одной трафик не доходит даже до половины лимита.
Нет, не хочу лишний раз палить связь.
Все на выделенных серверах, на канале не менее 100мбит, некоторые на гигабите. Слабое железо да, бывает.
Где как. Порты 80,443,9001,9030, зеркало директорий где есть а где нет.
Другие приложения, тот же торрент, утилизируют гигабит создавая тысячи соединений. Трансфер одиночного файла по ftp разгоняется до 200мбит.
Точные цифры из статистики atlas.torproject.org и torstatus.blutmagie.de, свой трафик по виндовому показометру околонулевой, хотя должен занимать не менее трети полосы.
Пример конфигурации одной ноды с почти нулевым трафиком:
Исходя из этой конфигурации, нода должна жрать 3*8*2=48 мегабит и в пиках 6*8*2=96 мегабит полосы, а реально жрет меньше мегабита. Что тут не так?
Они там пишут[link7], что Интересно, как скоро разработчики договорятся до того, что чтоб сделать Tor ещё теплее и ламповее, надо выработать единую политику блокировки сайтов на экситах, т.е. чтобы через Tor юзеры могли зайти только на кое-кому угодные сайты?
Выше написано, что Могло ли что-то настолько концептуально поменяться в самом Tor с тех времён(?).
Интересное кино. Не огласите ли список Ваших узлов, чтобы заинтересованные пользователи внесли их в свои блэклисты?
А она и сделана, чтобы меньше палить связь translate.google.com в помощь Старайтесь избегать этой распространенной ошибки
Вот такую байду проверяли? А нода под виндой не должна бы быть медленнее исходя из номеров ее портов, потенциальных то юзеров больше.
Уверяю вас, трафк на нодах не снифается и ничего плохого не делается.
Часы выставлены правильно и в логах всё чисто. На всякий случай приведу полный лог одной ноды:
Судя по логу, никаких проблем не наблюдается, но трафик не идет. В чем может быть причина? Может у DA есть какие-то скрытые особенности распределения трафика по нодам?
Не так. Смотри, как нужно топить:
Ваш праведный гнев бы, да разрабам Tor в уши. Где ваше возумщение на /comment57954[link8]? Кто эти анонимные спонсоры? Почему пользователи Tor не должны знать, кто заказывает музыку? Где эти 125 пресловутых спонсорских нод? Они тоже будет помечены, как MyFamily? Ага, сейчас. DARPAм, CIAм и Navy есть чего боятся, им простительно нарушать правила, они же такие бедняги уязвимые, что пипец. А анониму, за которым на стоит могущественное государство, и который трясётся за свою задницу, бояться, конечно же, нечего. Всё логично. Пусть все знают где, на каких хостингах и какие сервера он крутит, откуда берёт на это деньги, зачем ему лично поддерживать Tor. Только ZOGу можно нарушать любые правила и соглашения, работать исподтишка, всем остальным — запрещено категорически. Если "заинтересованный пользователь" хочет заблеклистить кого-то, пусть блеклистит сразу весь Tor, т.к. проект, куда можно заплатить и вбросить столько нод, сколько хочешь, доверия не внушает.
И, вообще, где срач на эту тему? Где анонс в блоге Tor? Где вопли в рассылке? Где клятвенное покаяние Роджера? Все делают вид, что всё ОК, всё именно так и должно быть. Анонимные спонсоры. Анонимные сотни чьих-то нод. Анонимный Tor такой анонимный... только для кого?
С точки зрения такого взгляда вопрос, почему чьи-то ноды пропускают много трафика, а чьи-то мало, начинает играть другими красками[link9].
В смысле, исходя из того, на каких портах слушает Tor в обсуждаемой виндовой ноде? Так-то количество доступных портов на машине стандартизировано независимо от ОС (0-65535).
О Боже!, но я же не это имел в виду! Read The Fucking Manual! После применения translate.google.com:
Кстати, заметили вброс странных нод количеством более сотни? Все в США, у всех 1Кб/с скорость, всем присвоено буквенно-цифровое наименование из 16 символов.
Всегда количество нод около 3000. 3000-3200 в среднем. Сейчас под 3500.
Что бы это могло означать?)
Почему бы не написать в рассылку tor-or-talk, спросить?
... а заодно спросить и про вброс этих[link10] нод.
1 б/с (байт/с)
Много они нагенерят трафа. Суммарная пропускная способность 0,1 Кб/с... WTF?
А ведь уже 4 дня шумят.
Кто-то запустил кучу экситов на ботнете*, но он дурак и не смог отобрать для этого подходящие машины. Там 95% на NAT-ах и, соответственно, совсем не работают.
Ничего хорошего такой вброс не несет. Качество таких нод очень низкое, сеть может начать глючить и тормозить. Имхо, стоило бы ввести регистрацию нод на сайте вручную, через капчу, хотя автоматическая установка ноды тоже бывает нужна. Предыдущий вброс прожил два дня[link11]. Интересно, сколько этот проживёт.
*Конфа везде одна, версия Tor одна, везде винда, IP разные из разных стран ⇒ ботнет 100%.
Нет, среди них ни одного экзита нет.
Версии и конфы идентичны, да, но везде не винда, а линух, IP разные, страна одна – США. Все на Амазоне хостятся.
Уже более 4 суток
тормозитживет.Вероятность выбора узла зависит от его пропускной способности.
Чей-то очередной исследовательский проект?
Всё не так уж и без облачно[link12]. Пока непонятен целиком весь замысел, но картину уже портят.
А, так у них быстрые вычисляются в зависимости от процентов узлов всей сети? Тогда после такого вброса (если нет допустимой нижней границы) каждый заурядный узел может получить статус быстрого и сторожевого? Может замысел в этом?
Да.
Получит каждый узел флаги всех статусов, и? Какая может быть разумная цель в этом?
Как минимум, proof-of-concept, что общесетевую статистику крайне легко исказить. При обсуждении многих атак иногда апеллируют к тому, что некоторые сценарии могут быть экономически нецелесообразны, т.к. не каждый первый узел способен стать, например, сторожевым — требуется удовлетворение условиям стабильности и пропускной способности. А тут мы видим, что выполнение этого второго условия (по идее, более затратного) на самом деле тоже ничего не стоит.
Если параноить дальше, то резкие откаты статистики могут косвенно облегчать, например, раскрытие скрытых сервисов. Которым придёться перестроить цепочки и точки встречи, после того, как всё нормализуется. И кстати, сторожевые для них тоже критичны.
Нельзя доверять информации из дескриптора. Может узлы и запущены 4 суток, но в сети они могут быть известны только с момента появления в консенсус-документе. И там они появлись только 3 февраля в час ночи по гринвичу.
Флаг со статусом Fast на самом деле мало что решает. Все определяется скоростью, которую замеряют корневые директории. Fast это такой рудимент из прошлого, в современности клиент просто не использует узел без этого статуса. Если рассмотреть амазоновские узлы, то их клиент всё равно использовать не сможет, потому как в килобайтах получается 0.
Суть не в этом. Если я правильно понял, это искажение статистики привело к тому, что изменился вес всех прочих узлов сети, даже если их скорость была не многим выше нуля. Соответственно, получить статус гарда в такой ситуации потенциально может первый встречный (при достаточной стабильности узла, разумеется).
Но легко может быть, что я ошибаюсь.
И если пока это действительно может затормозить сеть, то далее может вынудить при отктатывании статистики к нормальному виду порвать соединения с этими временными гвардами-самозванцами.
А это нежелательная флуктуация для анонимности пользователей и HS.
Вероятно, что да. Были обнаружены только вчера. Ранее замечены не были.
Кстати, коллега звонил и поделился следующей картиной. У него скорость соединения через Tor временами падала до нескольких бит/сек. Я говорю, может попал на медленную ноду? Так вот, скорее всего, было попадание на один из этих узлов, если их фактическая пропускная способность действительно <1 б/с. Правда, там есть и помимо этих медленные ноды. Но их скорость начинается от нескольких Кб/с.
Между тем, за ночь их число удвоилось (вот пример для ВВП) и составляет в настоящее время более 230 узлов...
Они уже здесь!
Достаточно стабильный уже не первый встречный :) Внезапно, гардом можно стать без этой атаки, просто изобразив скорость в дескрипторе. Главное не скорость, а стабильность, которую узел изобразить не в состоянии. При этом клиент будет выбирать по скорости которую измеряют корневые директори, а не изображает сам узел.
И гард-флаг ему присваивать будут тоже они, проверив скорость, так что сами по себе его претензии на желание быть гардом без консенсуса от DA, просто манипулируя цифрами скорости в дескрипторе, останутся для клиентов незамеченными.
В данном случае важней факт внедрения в сеть тысяч подконтрольных противнику узлов, чем игры с флагами.
Не проверяют они скорость. Вот в чем фокус. Аптайму не верят, а скорости при назначении на роль быстрого или охранника верят.
Ну это бага какая-то. Раз для статистики для клиентов скорость проверяется, то почему для флагов в консенсусе это не так?
Хороший вопрос.
Не преувеличивайте. Не тысяч, а сотен. В части противника тоже есть вопросы. Хотя на благие намерения этот вброс не похож.
Я уже послал охранника сгонять
за пивомза попкорном.У меня есть теория об ошибке в скрипте который формировал конфиги для этих узлов, верю я в доброе и светлое в людях. Амазон часто рекламили в блоге для запуска бриджей. Сотня бриджей это было в задумке, а скорость в 1 байт и попадание в публичную сеть это случайная ошибка.
Подождем, что скажут
Вести24в новостях.Пока что ваше мнение не разделяют:
https://trac.torproject.org/projects/tor/ticket/8151
Отображается то 116 узлов, то 232. Как когда. 0 б/с скорость сейчас. Всего 3522 ноды онлайн. Вброшенные ноды составляют около 6% сети. Стремительный рост. Завтра их будет уже 464?
Скоро[link13] будет обновление и эту вакханалию прикроют.
Причём, сама потенциальная уязвимость была опубликована[link14] два года назад.
Собственно, альфа-версия[link15] уже закрывает этот[link12], этот[link16] и этот[link17] баг.
Помимо исправления данной ошибки, туда также опционально внедряют протокол[link18] односторонней анонимной аутентификации Диффи-Хеллмана на эллиптических кривых.
А ещё на скрытых сервисах можно будет открывать виртуальный хостинг: http://foo.aaaaaaaaaaaaaaaa.onion/ и http://bar.aaaaaaaaaaaaaaaa.onion/ будут двумя разными вебсайтами на одном скрытом сервисе.
Извиняюсь за ламерский вопрос, но как DA может надёжно измерить скорость Tor-ноды?
Прокачивая через неё трафик.
Ну, вот нода и будет отдавать при проверках со стороны DA одну скорость, а реально иметь другую, это открытая дыра для мошенничества со стороны ноды.
Периодически через разные цепочки? Надо точнее смотреть, как это реализовано, но наверное такие тривиальные случаи предусмотрены. Потому что борьба с махинациями при выставлении параметров ноды обсуждалась ещё в самом начале реализации проекта. Хотя, как видим, могли что-то и пропустить.
Ну, не знаю, как они там проверяют. Если DA будет строить цепочку через нужную ноду, скорость будет ограничена не только нодой, но и скоростями других нод в цепочке, к которым тоже надо откуда-то брать доверие. Короче, это какая-то самосогласованная система с непонятными, но, возможно, вполне существующими методами вывода её из равновесия.
TorProject выступил с объяснением всех чудес с пропускной способностью Tor-нод: «The lifecycle of a new relay»[link19].