This small script downloads all Tor Relay IP addresses from onionoo.torproject.org and checks whether random Relays are available.
It could be used to find working Relay in a countries with internet censorship and blocked Tor.
The site now only contains working Relays. Use the program above to perform real scan.
На сайте теперь только публикуются рабочие Релеи. Используйте программу выше для проведения настоящего сканирования.
Pure Javascript version that works in browser.
В России на провайдерах с ТСПУ доступно множество Tor Relay’ев, которые можно использовать в качестве Bridge (мостов). Их блокируют гораздо реже, а работают они стабильней.
Сделал страницу для поиска рабочих Relay’ев прямо в браузере:
Nice work!
Shouldn’t this script check relay flag’s and outputs only ‘Stable’ and ‘Valid’ nodes?
onionoo.torproject.org is blocked by my ISP, so I need a proxy to download relay list.
The script loads only running=true nodes over API, I guess that’s sufficient.
Javascript version has two proxies in case the main endpoint is blocked.
Развернул тоже у себя в Telegram: Contact @mtpro_xyz_bot, не помешает
Трафик к узлам появился, начнутся блокировки. Было бы интересно изучать эту динамику для оставшихся узлов.
Возможно они оставили эти узлы для спецслужб. Помните фразу: пришли из спецслужб к роскомнадзору и говорят “вы нам работать мешаете”. Хотя скорее всего просто недосмотр.
Недосмотра нет. Узлы и мосты находят из трафика через ТСПУ.
А как они определяют принадлежность к obfs4, если порт нетипичный?
Кстати, заметил проблему с релеями, которые предлагает Valdik. Tor подключается, но если им не пользоваться какое-то время, то потом он уже не коннектится (после простоя). В браузере ошибка таймаута. В логе тор пишет что-то вроде (я уже удалил лог): “запрос от приложения… хорошей идеей будет соединиться со знакомыми узлами”. Таких строчек много. Релеев указано 10 (3 нерабочих).
Дважды такое было. А с obfs4 все в порядке.
Tor 0.4.3.5 standalone как systemd служба на Ubuntu 16.04 + браузер SeaMonkey 2.53.4. Это не с российского IP, интернет чистый.
Рестарт службы помогает, конечно.
Хороший вопрос.
Использование релея в качестве моста это необычный сценарий. Возможны ошибки, которые не замечали/не исправимы.
Was it this?
Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
There is a long-existing bug in tor where it sometimes stops trying to connect, if one of its bridges does not work. At least, I think that is the cause—I don’t fully understand myself. Here are two issues to look at:
Yes, that’s the error.
Someone mentioned patches in the discussion.
Фсё.
Добавили первоисточник в источник адресов для блокировки.
Что это значит?
Блокируют адреса (практически) всех узлов.
Хм, вы правы, но заблокированы они иначе: узлы выдают connection refused вместо отсутствия ответа.
Узлы снова работают, спустя 2 минуты. Похоже, тестируют новый способ блокировки на части ТСПУ.
torscan-ru.ntc.party пишет, что relay доступны, хотя по всем релеям та же консоль браузера пишет GET https://IP_XX:9001/ net::ERR_CONNECTION_REFUSED
Сегодня утром на тиере все именно так
Почти все ipv4 релеи заблокированы
Я поправил количество узлов в коде на 50. Все-таки иногда проскакивают доступные ipv4 релеи
Самый большой вклад в блокировки может дать использование ru узлов которые сумели попасть в консенсус, но при этом сидят за чебурнетом.
Можно добавить исключение для выдачи ru релеев (если адрес такого узла был найден этим сканером). Или, что надежней, попросить (все) управляющие директории исключить ru узлы и мосты.