id: Гость   вход   регистрация
текущее время 08:01 19/04/2024
Автор темы: Гость, тема открыта 23/12/2009 14:31 Печать
Категории: софт, анонимность, анализ трафика, tor, атаки
https://www.pgpru.com/Форум/UnixLike/БалансировкаДвухTor-каналовVsАнонимность
создать
просмотр
ссылки

Балансировка двух Tor-каналов vs анонимность


Если хочется получить бОльшую скорость работы через Tor, или если хочется не ассоциировать разные анонимные identity посредством использования одних и тех же цепочек в Tor, можно, в простейшем случае, поднять два разных тор-клиента, и связать каждый из них со своим пользователем на машине. Однако, у такого подхода, если единственная его цель – улучшение качества и скорости связи, есть очевидный минус: "ручная" балансировка задач между разными Tor-каналами далеко не самая оптимальная. В связи с этим предлагается обсудить следующую схему. Допустим, что у нас есть два тор-канала (соответствуют одновременно запущенным двум Tor-клиентам) с прозрачным заворачиванием всего трафика от нужных юзеров в сеть Tor. Логично было бы сделать автоматическую балансировку нагрузки между этими каналами стандартными средствами firewall'а (например, altq в OpenBSD PF с использованием опций типа round-robin, route-to и, может быть, source-hash: какие-то примеры обсуждались здесь). Однако, мне не очевидно что такая схема будет работать корректно, т.к. всё зависит от того, отправляются ли разные tcp-сессии через разные gateway (Tor-клиенты), и, если нет, то как отреагирует firewall на ситуацию с сосуществованием двух независимых маршрутов до одного и того же внешнего IP. Также возникает вопрос о всевозможных последствиях для анонимности в таком подходе: сможет ли, к примеру, внешний хост определить, что пользовательский Tor-клиент настроен именно вышеуказанным способом? Вдруг разные элементы web-страницы будут загружаться через разные exit-ноды? Просьба к уважаемым участникам, кто понимает как технически работают балансировки интернет-каналов и Tor высказаться по этому поводу. Конкретные тезисы, выносимые на обсуждение, следующие:

  • Возможно ли настроить такую схему (нет ли здесь противоречий со стандартами)?
  • Каковы последствия данной настройки для анонимности?
  • Какие конкретные технические рекомендации вы можете дать для организации такой настройки? (В терминологии iptables или, что лучше, pf, т.к. с ним я знаком лучше)

 
На страницу: 1, 2 След.
Комментарии
— Гость (07/05/2010 18:35)   <#>
Подумалось вот о чём: можно ли приспособить идею топика к ускорению работы скрытого сервиса? Например, клиентам раздаётся 3 разных onion-адреса для своего http-сервера (физически все они на одной машине), а клиенты настраивают балансировку нагрузки при обращениях к серверу. Непосредственно такое, наверное, не сделать, но можно поиграться с костылями: к примеру, опция AutomapHostsOnResolve позволяет отобразить все скрытые сервисы на какие-то виртуальные IP. Далее можно согласованно "продолжить маршрут" на серверной и клиентской стороне так, чтобы все IP, соответствующие onion-адресам, были gateway'ями на один какой-то IP адрес уже собственно нужного http-сервера. Iproute/iproute2/iptables вроде бы позволяют нагородить такой огород (?) У кого какие мысли по этому поводу?
— SATtva (07/05/2010 20:30)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Балансировку каких нагрузок это решает? Самая затратная с точки зрения времени часть HS-протокола — это построение двух цепочек до точки встречи.
— Гость (07/05/2010 21:25)   <#>
Допустим, http-клиент скачивает какой-то файл. Если его скачка идёт параллельно по двум цепочкам, он должен качаться быстрее.
— Гость (11/01/2014 00:30)   <#>
Mellon'у пофиг на профилируемость из-за балансировки, скрипты готовы.
— тестерТьюринга (11/01/2014 09:24)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4

Когда-то давно интересовался подобным вопросом. Под Винду находил проги, которые могли устанавливать до 500 соединений одновременно.

В общем случае, скорость не увеличится. Винда и Линукс – это операционки с разделением по времени. Будет происходить чередование каналов закачки. Лет десять назад, скорость по разным маршрутам могла заметно отличаться из-за разницы в качестве обслуживания. Возможно, на многоядерных/многопроцессорных машинах скорость увеличится на число ядер, но для этого нужны проги специально написанные и скомпиленные соответствующим компилятором.
— Гость (11/01/2014 20:51)   <#>
Причем тут ядра? Скорость одиночного TCP потока ограничена cognestion control алгоритмом и сильно зависит от пинга. Поэтому общеизвестный факт, что нужно качать в много потоков чтобы выжать всю ширину канала. Все download менеджеры так делают.
— тестерТьюринга (12/01/2014 00:53)   профиль/связь   <#>
комментариев: 301   документов: 8   редакций: 4

В том-то и дело, что одиночного. А про ядра – это просто предположение.
— Гость (13/01/2014 11:30)   <#>

Есть разные утилиты типа half-open fix, которые увеличивают кл-во соединений по умолчанию с десяти, как правило до ста, правкой файла tcpip.sys. Это в виндах, которые не тронуты руками говносборщиков. Хотя среди сборок есть неплохие, но при работе с виндой предпочтительны чистые образа, во избежание глюков и малвари от сборщика, что не редкость. Бэкдоры от Майкрософт и АНБ не рассматриваются, потому что использование винды развлекательное или для официальной работы.

Раньше в винде было ограничение на 10 соед. Потом его снимали вроде в каких-то версиях, в общем от оси к оси, в зависимости от SP и обновлений, там разные решения были.

Обычно увеличивают до 100, как правило выставляют значение <100>. Но можно устанавливать любое произвольное количество, если не изменяет память, то и 500, и хоть тысячу, хоть две, не помню, есть ли вообще там ограничение, в частности в half-open fix'e. Вообще-то, 100 за глаза хватает рабочей станции, активно юзающей сеть + торенты.
Это в основном для торентоводов-стахановцев. Например, устаревшая, но до сих пор популярная среди юзеров торентов модель роутера асус RT-n16, по словам производителя, позволяет устанавливать до 300 тысяч одновременных соединений.


Жлобское сетевое поведение. И DM так делают, если выставить подобные настройки и сервер позволит качать в несколько потоков. Как правило, чаще встречаются просьбы (либо предопределенные политики) владельцев сетевого ресурса качать в один-два потока. Или бан.
Во многих случаях агрессивного поведения качальщика, он мало что выигрывает. Если один поток отдает 1 Мб/с, то это не значит, 10 потоков будут отдавать в сумме 10 Мб/с.

Про балансировку тора читать странно. Зачем? Тем более, если рассматривать с прицелом на анонимность, без пол-литра не обойтись.
Сейчас и так из коробки все быстро и анонимно. Но можно попробовать. Смотря для чего использовать балансировку.
Mellon, результаты экспериментов будут опубликованы? Тем более, что топик древний.
Кстати, кажется ранее в каком-то из торент-клиентов была встроена поддержка Tor. Vuze вроде, но он неудобный показался, с рекламой был года 4 назад, он как-то сразу не понравился, поэтому мной не только режим торификации не тестировался, но и обычное использование.
— Гость (14/01/2014 00:26)   <#>
Про балансировку тора читать странно. Зачем?

Сейчас и так из коробки все быстро и анонимно.

Топик был создан более четырёх лет назад, когда со скоростью всё было не так хорошо, опасность профилирования ещё не осознавалась, а TBB не было. Я — автор топика, если что.

ранее в каком-то из торент-клиентов была встроена поддержка Tor. Vuze вроде

Почему-то сразу вспоминается это и это.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3