По поводу этой ошибки, мне помогает отчистка каталога /var/lib/tor/*. Может быть это и совпадение и не связано. А всему этому предшествует, то что через tor вдруг перестают открываться сайты, в nyx мосты “пропадают”. Можно долго ждать, но если tor остановить, почистить тот каталог, потом запустить tor, как всё нормализуется. Уже пару лет так.
ASN12389, Ростелеком Питер.
Obfs мосты отвалились в середине декабря. Мосты из https://torscan-ru.ntc.party/ требовали ежедневного внимания, но работали пока три дня назад не отвалились вообще все. На стадии SSL/tsl handshake, если не путаю - то самое [notice]. Зато внезапно, но не слишком стабильно заработал Snowflake, который перестал работать раньше чем obfs. Webtunnel блокировали одновременно с obfs. И да, мосты из бота в Телеграм и по емейлу не работают с середины декабря, повторюсь.
snowflake-мосты в последние дни тоже никакие - ужасные скорости. Выход, по-моему, свои webtunnel-мосты поднимать.
да, у меня тоже отвалились все мосты. самое смешное что у меня на провайдере всё прошло максимально криво и пришлось врать про ддос-атаку, хотя на самом деле это ркн криво накатывал обнову, после которой резко перестали работать все мосты.
может быть разработчики lyrebird выпустят патч который поправит ситуацию.
Здравствуйте, у меня похожая проблема. Загрузка выше 10% не поднимается. Перепроверил мосты тем же скриптом, и они не рабоают. В чем может быть проблема? Новая блокировка от РКН? Использую стандартный Tor из репозиториев Debian 12, без lyrebird, вчера все работало нормально.
Обновляю, проблема именно в мостах. Попробовал другие мосты и прогресс доходил до 25%, но были ошибки с SSL и дальше не пошло. Достаточно интересная проблема.
А вы дожидались полного сканирования?
./scanner --torrc -n 25 -g 6 --timeout 5
проблема не в том что мосты не те, а в том что трафик к мостам распознаётся и блокируется. сканер считает все мосты рабочими видимо потому что либо пингует их либо просто устанавливает ssl-соединение, но видимо для реального подключения надо слать другой трафик, и этот трафик стал распознаваться dpi.
Данный скрипт эмулирует работу ТорБраузера и после пробует подключиться .
Да, похоже на такую блокировку. А так, похоже что скрипт использует обычное SYN сканирование как masscan. Но что делать теперь? Переходить на WebTunnel?
Обновляю, забыл дописать то сообщение. Если во время застревания Tor на 10% зайти и посмотреть в Wireshark, то на всех пакетах будет “TCP Retransmission”. Думаю это точно блокировка obfs4.
Еще раз обновляю, нашел метод обхода через DPI. Снимок экрана плохого качества, прошу простить.
Снимок экрана просто убийственный.
На РТ Тор ВПН приложение из Гугл стора работает без мостов с запретом, с мостами тем более,
Мосты torscan, о которых писал, у меня заработали внезапно. А Snowflake плавно деградировал - хотя кое-как работал.
мне мешок битых пикселей, пожалуйста! с собой
у меня после обновления версии Release tor-relay-scanner v1.0.4 · ValdikSS/tor-relay-scanner · GitHub тор заработал.
хотя мне казалось что для этого надо обновлять lyrebird а не сканер.
В последнее время появилось много проблем с доступом к некоторым ASN-сетей, похоже.
Поэтому много мостов не работают именно из-за такой блокировки, а не из-за точечной блокировки Tor-мостов. Некоторые мосты можно пробить продвинутыми стратегиями zapret’а, а другие - нельзя. (даже если хоть какие-то пакеты проходят, иногда просто невозможно сделать полноценное соединение) Разница в том, что когда блокировка ASN-сетей/хостинг провайдеров (в основном), то хоть какие-то пакеты проходят. Если же все пакеты блокируются, то значит это IP-блок моста - это самая подходящая теория проверки наличия такой блокировки, по-моему. Почему же это не может быть “точечной блокировкой“ определённого моста? Потому что попробуйте зайти на сайт хостинга - если та же проблема как и с мостом, то значит не только мост затронут.
Это распространяется в основном на зарубежные хостинг-провайдеры и не обязательно только больших.
Из обнаружений: некоторые мосты, размещённые на подобных “замедлённых” провайдерах “лечатся” при использовании продвинутых zapret-аргументов, как упомянуто ранее.
Ссылки на продвинутые zapret-аргументы
Здесь есть программа для Windows, но вы можете просто скопировать аргументы и вставить их в оригинальный zapret.
А здесь есть автоматическая настройка для Linux, но там также можно использовать оригинальный zapret.
Представьте: есть список из 25+ провайдеров, которые РКН каким-то образом “замедляет“, много мостов на них и размещается, вот вам и поломанные мосты. Если кто-то больше про это знает - делитесь, ведь может происходит что-то ещё или это работает по-другому. Вроде это ещё известно как 16-20kb block.
В некоторых случаях obfs4-мосты могут не работать из-за например блокировки полностью-зашифрованного трафика, если мост не заблокирован по IP и вдобавок не размещён на “замедлённом провайдере“, то эта инструкция может помочь.
Получается, некоторые WebTunnel мосты поподают под SNI-блокировку + замделение провайдера, некоторые просто по SNI и которые не заблокированы никак, но это надо их найти.
Поэтому это мнение какое-то нелогичное, т.к. как они могут отличать обычный сайт от WebTunnel моста? По сути, если не “собрали“ мост, то никак. WebTunnel же замаскирован под https. Вдобавок, наверняка другие IP провайдера, на котором размещён этот мост тоже имеют проблемы с подключением - проверьте.
Про obfs4: некоторые заблокированы - по IP; другие - по “полностью-зашифрованному трафику“ (то есть не точечно-заблокированы и можно обойти через запутывание); мосты без блокировок и мосты, конечно, неработующие из-за замедления некоторых провайдеров.
Поэтому надо найти работающий для себя мост, некоторые потребуют дополнительные настройки/программы, некоторые - нет.
А про Snowflake: вроде работают его “fronts“ - это через что вы получаете данные для подключения к Snowflake-прокси, обычно знак успешного подключения к этим ресурсам - продвижение в строке подключения в Tor Browser. Но с Snowflake видимо трудности начинаются с Snowflake-proxy. Вам может быть выдаётся прокси, который стоит на одном из “замедленных“ провайдерах, вот и подключение не работает. Что же можно сделать, чтобы обойти такое? Можно остановить подключение, закрыть приложение (чтобы отчистить кэш подключения) и попробовать установить новое соединение. Это скорее всего поменяет IP-зону прокси, которого вам выдадут. Поэтому в итоге соединение скорее всего должно сработать, если сразу Snowflake не работает.
Snowflake по умолчанию не самый быстрый “мост“, там ведь подключение идёт вот так:
Вы (после нахождения прокси для подключения) > Snowflake-прокси (например человек на домашнем интернете с браузерным расширением в другой стране) > специальный мост Tor’а, не спонсируемый проэктом Tor (принимающий трафик от пользователя с расширением) > средний узел > выходная нода > веб-трафик
Ещё как вариант есть meek, более медленный, чем Snowflake, но возможно будет работать, так как выглядит как соединение с серверами Microsoft. Кстати, размещать meek-мосты - очень дорого для проэкта Tor, поэтому используйте с пониманием, по возможности используйте другой вариант подключения - себе скорость повысите и сделаете меньше затрат.
Интересно, если весь трафик некоторых провайдеров “замедляется“, есть ли протоколы которые не под “замедлением“? Проэкт Tor рассматривает добавление протокола “Proteus“, который более гибко можно кастомизировать без выкатывания обновлений к стороне сервера и клиента, но он может быть встроен через какое-то количество времени, пока - нет.
С этими знаниями - станет ли понятнее причина неработоспособности мостов для некоторых пользователей?
Было бы хорошо иметь больше информации про эту странную массоваую блокировку мостов Tor (и вообще про “замедление некоторых провайдеров“), чтобы лучше понимать эту систему.
Что конкретно интересует, список блокируемых хостингов для фильтрации списка мостов? Я себе веду список блокируемых, но у меня там в куче: заблокированные по IP и на “плохих” хостингах — надо заново перепроверить и отсортировать (последние “плохие” помню: Contabo, NForce Entertainment B.V., WIIT AG).
Да, недавно когда тор работал совсем без мостов, т.е. сам выбирал ноды, попадались ноды на 16к хостингах. В arti клиенте видел, что если попалась 16к нода, то периодически из лога она исчезала, потом появлялась. Но конкретно в этом случае основные данные ходили по второй нормальной ноде. Их обычно 2.
Если точнее, палится размер зашифрованных пакетов, когда там TLS внутри. shadowsocks тоже страдает от этого.
Ну оригинально имелась ввиду сама система: почему одни мосты “чинятся“ запретом, а другие, хоть и не все пакеты блокируются - не чинятся. Например может одни хостинги полностью “замедлены“ без возможности обхода, а другие - частично. (например обойти блокировку Discord можно через zapret. (Discord на cloudflare стоит, поэтому наверное сложно заблокировать полностью?))
Но собирать список хостингов, с которыми возникают проблемы не помешало бы)