tor-control-panel Tor bridges testing

Здравствуйте.

Пользуюсь вашим софтом уже некоторое время, вещь очень удобная для своих целей.

Существует задача решить вопрос с медленным соединением в сети Tor. Принципиально я подход выработал, иногда в пиках полоса пропускания до 40-50 Мбит может доходить, в среднем 15-20 Мбит. Нужно использовать Conflux, который поддерживается в основном новыми Webtunnel мостами. И при использовании 8-10 качественных Webtunnel мостов достигается нужный эффект.

В сети как уже здесь писали действительно есть пару источников мостов, но материал там сырой, нужно тестировать и отсеивать.

Не буду вас загружать вопросами типа "А можете сделать?", наверное и сам смогу (Go). Интересует ваше экспертное мнение по вопросу как правильно организовать тестирование Webtunnel мостов? Нужно проверять

живой ли мост
поддерживает ли Conflux
нужно замерять полосу пропускания чрез мост

Цель - выбрать из большого количества мостов самые лучшие и использовать в конфигурации и на выходе получить комфортное качество соединения через сеть Tor.

Какой бы вы подход использовали для решения этой задачи?

Заранее благодарен за ваш ответ!

May 18 '25 05:05 navigator-droid

ИМХО ТОР не про скорость. даже с conflux.

не говоря уже о разной скорости провайдеров/хостингов-серверов/нагрузке на ноды

consensus_weight для примерной оценки он же скорость-канала в TCP

можно использовать что то вроде

REM set herzner=ash-speed.hetzner.com REM set hetzner=hel1-speed.hetzner.com set hetzner=fsn1-speed.hetzner.com curl.exe -4 -x 127.0.0.1:11080 -O -k -H "Host: %hetzner%" --connect-to ::%hetzner% https://play.google.com/100MB.bin -w %{speed_download}

curl -4 -o NUL -k --connect-to ::speedtest.selectel.ru https://mail.google.com/10MB -w %{speed_download}

May 18 '25 10:05 LeonMskRu

Спасибо за ваше мнение.

Честно говоря, больше всего интересует как без бубна проверить поддерживает ли мост Conflux? Нужно обязательно соединение поднимать и в логах смотреть? Похоже на костыль какой-то....

May 18 '25 12:05 navigator-droid

Ну, эксперт из меня так себе и, возможно, ничего нового вы не узнаете, тем не менее, попробую ответить.

I. Живой ли мост:

Самый простой способ - это попытаться установить соединение с сокетом (IP:порт). Если за отведённое время, соединение не произошло значит мост - мёртвый. Таким способом можно отсеять большинство нерабочих мостов, особенно когда их тысячи. В случае с webtunnel-мостами, когда IP-адрес из несуществующей подсети [2001:db8::] /32, можно сканировать параметр моста url. Если нет коннекта к этому адресу, значит и мост работать не будет.
Удачное tcp соединение с адресом и портом моста не всегда гарантирует, что мост действительно рабочий, ведь на этих адресах и портах вполне мог быть раньше мост, а сейчас веб-сервер стоит или публичный промежуточный/выходной узел, а не мост. Поэтому второй шаг определения - попытаться подключиться к tor, используя этот мост:
- Настраиваем torrc-файл на работу с мостами и добавляем их не больше 100 за одно сканирование, потому что tor долго и упорно пытается соединиться со всеми мостами, генерируя кучу полуоткрытых tcp соединений. Можно поиграться с опциями torrc-файла: SocksTimeout, MaxClientCircuitsPending, чтобы не ждать 2 минутного таймаута соединения и очередь подключений двигалась шустрее.
- Если подключение прошло удачно, то tor загружает дескриптор этого моста и помещает его в файл DataDirectory\cached-descriptors.new. Если список мостов не менялся с прошлого запуска tor или не прошло много времени, то при следующем запуске tor, cached-descriptors.new перемещается в cached-descriptors. Если же список мостов изменился, то оба файла дескрипторов чистятся и все по новой будет сканироваться, поэтому всю очередь надо отсканировать за один запуск tor, а потом отпарсить результаты, либо организовывать несколько запусков tor, накапливая промежуточные результаты в отдельный файл, который потом парсить.

II. Поддерживает ли Conflux:

По умолчанию, любой мост, который запущен на tor версии 0.4.8.1 и выше, поддерживает Conflux, но пользователь его может отключить через опцию ConfluxEnabled 0, поэтому точно узнать поддерживает ли мост Conflux можно из его дескриптора (файл cached-descriptors.new). Если в параметре "proto" есть Conflux=1, то поддерживает.

III. Нужно замерять полосу пропускания через мост:

Это самая неопределённая задача, потому что полоса пропускания постоянно меняется и зависит от многих факторов: общая полоса пропускания моста; количество клиентов, подключённых к мосту; количество маршрутизаторов и качество каналов связи между узлами сети. Подключиться, напрямую к мосту не получится, поэтому конечная скорость канала будет зависеть от тех же факторов и на промежуточных/выходных узлах цепочки. Даже если вы измерите скорость сейчас и она будет высокой, есть большая вероятность того, что она изменится в худшую сторону в ближайшие 30 минут.
Каких-то встроенных инструментов для измерения скорости скачивания в tor нет, поэтому придётся использовать либо внешние утилиты (wget/curl), либо встроенные возможности GO по скачиванию файлов. Обязательно должна быть возможность качать через прокси-сервер. Алгоритм такой:
- Запускаем tor-прокси, используя один мост. Промежуточные и выходные узлы, лучше выбрать фиксированные (по IP/Fingerprint) через MiddleNodes и ExitNodes, чтобы уменьшить случайный фактор скорости, остальных узлов в цепочке. Опцию EnforceDistinctSubnets ставим в 0, чтобы разрешить строить цепочки из узлов одной подсети.
- Качаем тестовые файлы через tor-прокси, замеряем скорость, фиксируем результат.
- Меняем мост на следующий и так повторяем со всеми мостами.
Специально измерять полосу пропускания каждого из мостов - способ довольно сомнительный, поэтому при выборе быстрых мостов стоит ориентироваться и на другие данные:
- Uptime - чем дольше работает мост, тем больше вероятность что он сейчас используется другими и скорость ниже.
- Advertised bandwidth - это максимальная полоса пропускания моста, которая была зафиксирована за отчётный период. Чем она выше, тем больше конечная скорость.
- Ping - чем ниже пинг между вами, мостом и другими узлами цепочки, тем меньше сетевые издержки и как следствие, более высокая скорость.
Ping измеряется намного быстрее, чем скорость. Advertised bandwidth и Uptime можно взять из cached-descriptors, а чтобы постоянно не использовать tor для обновления этих данных, можно воспользоваться Onionoo API, через запрос. Можно и не указывать Fingerprint, тогда можно получить JSON со всеми доступными мостами и узнать: какие из них вообще работают, а какие нет (по флагу Running и наличию в JSON), какие из них последний раз перезапускались, а какие из них новые. По каким каналам распространяются: сайт, телеграм, по запросу из Tor-браузера (moat). Какой транспорт используется и многое другое.

При сопоставлении ваших списков мостов с данными по мостам из Onionoo, нужно помнить 2 вещи:
- Onionoo использует Hashed Fingerprint - это SHA-1 хэш Fingerprint-а, который указывается в адресе моста.
- IP-адреса и порты в Onionoo фейковые, поэтому единственный способ сопоставить мост - это Fingerprint.

Надеюсь эта информация хоть как-то вам поможет, но, как по мне, вариант со сканированием мостов на скорость - вообще не вариант, слишком затратно по времени и по нагрузке на TOR-сеть. Результаты таких сканирований не совсем объективны и зависят от большого количества факторов, которыми трудно управлять.Tor всё-таки не про скорость, а про анонимность и анти-цензуру.

May 18 '25 14:05 abysshint

Ну.... Сначала я все внимательно почитаю и поразбираюсь :-)

И потом обязательно отпишусь.

P.S.: Все относительно. По сравнению со мной в вопросе Tor'а вы эксперт.

May 18 '25 15:05 navigator-droid

про списки мне пока для тестов хватает 290 штук из https://github.com/scriptzteam/Tor-Bridges-Collector/blob/main/bridges-webtunnel

May 18 '25 15:05 LeonMskRu

Да, я тоже про них ) Но просто там большая часть битая. Я этот список в TCP вставлял. Он не смог все переварить, что в общем-то понятно, не для того он создавался. Переварил какую-то часть, выбрал лучшие и показал тот результат о котором я писал в первом сообщении, что как я думаю очень хорошо.

Решил создать функционал под Linux по обработке всего списка.

P.S.: И на тему того, что Tor не про скорость а про конфиденциальность. Да, полоса пропускания деградирует, и довольно быстро, 5-15 минут и уже нет никаких 15-20 Мбит/сек. Но как показала практика все решается созданием новой цепочки. Никто нам не мешает создать некий скрипт поддержки работы tor инстанса, верно?

May 18 '25 16:05 navigator-droid