Памятка: обход блокировки TOR

Всё гораздо проще — блокируется всё, что не распознано как из белого списка в сторону определённых подсетей.

“Чинятся” те крупные хостинги, где есть белый список SNI например. Остальные не “чинятся”.

Ну вот ещё нашел у себя: Advania Island ehf, Castlegem SRL, Clouvider, FlokiNET ehf, G-Core Labs S.A., GREENCLOUD, частично GREEN FLOID LLC, Internetport Sweden AB, IOMART CLOUD SERVICES LIMITED, ISPpro Internet KG, Jan Smyrek, Melbikomas UAB, MillenialHost Limited, MVPS LTD, Owl Limited, Server Galactic Private Limited, SiteHUB. Как видно на примере GREEN FLOID LLC, не все диапазоны дискриминированы — видимо, халтурят исполнители заказа блокировок от чиновника.

для обычных сайтов в случае с 16кб блокировками хостингов
есть разброс с тем какие sni подходят для каких хостингов, попадались sni которые давали доступ ко всем кроме одного, и наоборот только к одному
и совместимостью стратегии с конкретным сайтом, некоторые ни в какую не приемлют изменение timestamp

может с тором происходит то же самое
попробуй менять sni в комбинации с разными стратегиями

Ещё какая проблема может быть с Snowflake - это недостаток прокси. В связи с сложившейся ситации в Иране (отключали интернет, теперь включили) происходит перенагрузка на сеть Snowflake. Это может быть проблемой побольше, чем если попадается прокси с “замедленным“ IP, так как много Snowflake’s на размещены на резидентских сетях.

Перебрал 295 найденных работающих obfs4 мостов: из них заблокированы по IP 50 — из ру хостингов так же не доступны, 85 оставшихся получают 16К блок из-за “плохого” хостинга (Akamai, Contabo, DigitalOcean, FranTech Solutions, G-Core Labs, Hetzner, HostPapa, M247 Europe, Oracle, OVH, Scalaxy, SCALEWAY, Vultr) — из ру хостинга доступны, 13 из оставшихся — медленные (< 8 Мбит/с), остальные 137 работают напрямую (46% от общего количества).

ASN12389, Ростелеком Питер.

В общем, такое впечатление что IPv6 мосты из сканера блокируются на хэндшейке практически полностью. Вообще v6 подключения менее стабильны.

У меня tor-relay-scanner перестал фунционировать, выдает около 25 из 30 адресов как рабочие с первой попытки, но фактически ни один не работает.

Такая же ерунда. В консоли

Test started…

The following relays are reachable this test attempt:

И пусто. При этом в лог падает вся пачка что тестировалась.

Сегодня включали белые списки, раньше tor-relay-scanner находил несколько работающих релеев в такой ситуации. Но теперь видимо tcp разрывается а не зависает, перебрались все адерса очень быстро, 0 успешных.

Искал в tor-relay-scanner как ему подсунуть json файл с адресами релеев, не нашел. Приходится http сервер локально зыпускать, когда встроенные url недоступны.

Это на мобильном интернете?

Да, на t2.

Опять умер, и уже несколько дней как.
На одном работает (как раз на том, где помирал до этого, и прочищался конфиг), но на момент отвала конфиг на всех был абсолютно одинаковый, так что это может быть до первой перезагрузки.

На втором, который тоже умирал в прошлый раз, так же завис на бутсрапе loading consensus как и в тот раз, но есть нюанс. Первым делом почистил конфиг от мостов, что выдавали в логе таймауты рефьюзы и сокс файлы, потом заметил
Parse error: missing pr element.
Error tokenizing router status
Unable to parse networkstatus consensus
Couldn’t set consensus from cache file “/var/lib/tor/cached-consensus”
И решил его удалить (но больше ничего оттуда не удалял, сейчас ещё проверил логи, и понял, что у меня это всю дорогу было, так что возможно удалять и не зачем было). После этого почистил от мостов, выдававших ворнинг DONE; DONE, с которым вообще раньше никогда не сталкивался, в результате осталсось всего пять ipv4 мостов, и дюжина-две ipv6, - все ванильные (почти все obfs отвалились по SOCKS failure). Но бутстрап так и не двигается.

Третий, в прошлый отвал единственный работал (но опять же - возможно просто потому что не перезагружался, с другой стороны, второй поциент тогда тоже вроде не перезагружался, но это не точно), и тут появляется нюанс - он и сейчас спокойно бустрапистя до 100 и “We now have enough directory information to build circuits”. Но при этом ничего всё равно не работает - не грузятся по таймауту страницы в браузере (НЕ в тор-браузере, он-то по прежнему работает, хоть и со скрипом и сменами мостов) - иногда пробивается, но где-то один раз в несколько часов, почтовый клиент не подключается. Шо есть бутстрап (на третьем), шо его нет (на втором) - по факту не работает, и хуже всего, что от лога абсолютно никакого толку - ни там ни там никаких ошибок (после чистки конфига от всех мостов, что их давали; на третьем, кстати, никаких дондонов, они только на втором, и соответственно ipv4 мостов оставлено больше аж в десять раз). Только периодическая ругань на директорию: “Ignoring directory request, since no bridge nodes are available yet”, изредка "Our directory information is no longer up-to-date enough to build circuits: We’re missing descriptors for 3/3 of our primary entry guards (total microdescriptors: ", и ещё реже “We’d like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish.” (и это, опять же после “We now have enough directory information to build circuits.”)

Сейчас попробую закомментить вообще все старые мосты, собрать пачку свежих, на втором компе очистить /var/lib/tor/ полностью, и если заработает так, видимо старые опять придётся ковырять в ручном режиме по одному.

Правила предполагают, что пользователь сам разберётся в проблеме и поделиться решением с сообществом. Надо снифать трафик тора и смотреть что там происходит — скорее всего адреса мостов находятся на “плохих” подсетях с 16К блоком и необходимо их убрать из конфигурации. Рекомендую, как вы и написали в конце, каждый мост тестировать по отдельности:

curl --insecure --silent --proxy socks5://[::1]:9050 -o NUL -w %{speed_download} http://cachefly.cachefly.net/10mb.test

Я собсно уже, только вот хотел написать/апдейтнуть.

С новыми мостами всё разом ожило и там и там.
Теперь придётся возиться с предыдущим списком, потому что что-то живое там должно быть, раз хоть раз в пол дня что-то пробивалось. Спасибо за курл с тестом, я даже не думал об этом, в прошлый раз именно что ручками, в браузере всё проверял - довольно изнурительно.
Вопросы которые у меня остаются (и ещё с прошлого раза):

  1. Можно сделать лог как-то полезнее? Запустить с каким-то параметром, или прописать что-то в конфиге, чтоб можно было хоть понять что происходит при подключении, какая нода в данный момент используется, или ещё что-нибудь что могло бы упростить жизнь?
  2. Что конкретно значат те ошибки, что есть? В частности этот DONE; DONE, и ошибки которые missing element и pars consensus (и почему он мог быть только на одной машине из двух). Но и остальные (no route, timeout, connectrefused, socks failure, и “гарад фейлит большое количество цепочек”) - в том смысле, что они значат примерно понятно, но не понятно отражают ли они полную смерть ноды, или только временную недоступность, и, соответственно, есть ли смысл их перепроверять потом? Особенно, с учётом того что новые похоже в дефиците, местный торскан уже неделю-вторую выдаёт только одну единственную ноду, тащемта например - выглядит пугающе.

Про 16КБ я тоже думал, но так и не понял, как это проверять, потому что сам до сих пор так с ними и не сталкивался, везде что у меня заблочено - обычный фул таймаут почти без выкрутасов (хотя вот последние несколько дней явно похуже стало, но трудно сказать это резко блокировать стали сильнее/хитрее, или из-за блокировки телеги сильно больше трафика за бугор через ВПН потекло и канал в целом перегружает), так что я даже не знаю на каких подсетях они есть и где посмотреть эти диапазоны чтобы сравнить адреса мостов. Знаю только про гибридный блок Хецнера. Но, опять же, откуда диапазоны брать для сравнения не знаю. Единственное что находил тут это список конкретных ip которые тригерят гибридные блокировки, и с ним уже мосты сравнивал.
И ещё мне не понятно почему первый компьютер с тем же самым конфигом как работал так и работает, и навернётся ли в след за остальными после первой же перезагрузки. Ну и, если бы это был 16К, значит он должен был бы появиться на новых подсетях, потому что проблема появилась из ниоткуда на мостах которые работали до этого, месяцами, некоторые - уже годами.
Если бы я мог разобраться со всем этим сам, мне бы незачем было сюда писать, и лишний раз, по пустякам и тому что тут, или где-то ещё что возможно нагуглить ли спросить у нейронки, уже есть я и не пишу.

Arti это показывает, с опцией:

.config/arti/arti.toml

[logging]
log_sensitive_information = “true”

кавычки исправьте.

  1. Надо запустить приложение транспорта отдельно, в torrc вместо
    ClientTransportPlugin __transport__ exec __path-to-binary__ [options]
    прописать
    ClientTransportPlugin __transport__ socks5 __IP__:__PORT__
    Ошибки транспорта будут выводится в этом отдельном окне.
  2. Незнаю. Я ищу строку в исходнике и смотрю условия появления. Можно отладочную сборку скомпилировать и запустить под отладчиком с точкой останова.

В вайршарке фильтр host адрес_моста и смотреть чё там. Подключить GeoIP базу нужно в настройках вайршарка.

Может выходной узел плохой или он блокируется со стороны почтового сервера. Можно исключить плохие ноды в конфигурации, но мне это давно надоело и просто пускаю по правилам SwitchyOmega/Proxifier капризные домены по отдельному маршруту. Ещё как вариант можно несколько инстансов тора поднять и через прокси-балансировщик подключатся пробовать одновременно.

Мосты можно получать из yggdrasil: Services | Yggdrasil Network.

Что могу сказать по поводу conjure транспорта. Работает, но не очень стабильно:

  1. Не всегда подключается, иногда надписи “станция перегружена”. На ru ip это реже, но тоже бывает.
  2. Качал как-то файлик весом около 100 мб, транспорт завис на середине.
  3. При неактивности отключается, а потом может не подключиться из-за перегрузки.
  4. conjure постоянно ест 5% моего не очень нового проца.

В yggdrasil также есть outproxy в интернет от acetone, если вам необязательно именно Tor. Его выходные айпишники от Incognet NL. Неудобство только в том, что ipv6 прокси не все проги принимают (совет: оберните IP квадратными скобками), acetone блочит некоторые ru назначения: vk, yandex, mail.ru. Если соединение установилось, пинг вполне нормальный, хотя скорость не очень. Но установление новых коннектов (например, из браузера) могут подлагивать. Я имею в виду, что для производительности желательно иметь keepalive к прокси. Эту проблему, а также цензуру ru сайтов, можно решить, если настроить psiphon на yggdrasil outproxy. Т.е. к сайтам будет подключаться psiphon. Скорость правда ещё подсядет, зато сёрфинг комфортней, т.к. затупов меньше (psiphon заставляет держать соединение).

“UpstreamProxyUrl”: “socks5://324:71e:281a:9ed3::fa11:1080”,

У меня это на маршрутизаторе (linux). Напрямую я не подключаюсь (через локальный прокси, по правилам доменов). Все клиентские браузеры в локалке работают через этот локальный прокси (он ещё и прозрачный). Yggdrasil как раз и нужен, для получания мостов, а там уже можно на любые сайты заходить. Прокси в yggdrasil просто ещё один дополнительный, не помешает.

не могу редактировать первое сообщение так что напишу тут.
старый способ работать перестал, и теперь мне ещё и хочется вынести тор на роутер с компа, так что вот что надо сделать:

  1. установить тор на роутер через apk add tor - у опенврт сменился пакетный менеджер так что команда именно такая, ну или можно через их селектор собрать образ прошивки в котором уже предустановлен тор, snowflake, i2pd и прочие интересные штуки
  2. скопировать репу обфускатора на комп через git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird.git
  3. перейти в папку обфускатора cd lyrebird
  4. скомпилировать его под опенврт через (GOOS=linux GOARCH=arm64 make build) обратите внимание что переменная GOARCH должна быть у каждого своя, у меня роутер на арме, у вас может быть mips или ещё чего-то такое.
  5. закинуть получившийся бинарник через ssh на роутер с опенврт, я по привычке это делаю через midnight commander, но это уже как вам удобнее будет. я рекомендую положить бинарник в /etc/tor вроде на опенврт именно там лежат файлы тора
  6. открыть конфиг тора через nano /etc/tor/torrc
  7. написать в конфиге строчку типа SOCKSPort 192.168.1.1:9050 чтобы все устройства в квартире могли ходить через тор, потом дописать в конец конфига
ExcludeNodes {ru},{by},{ua},{kz},{kg},{md},{tm} StrictNodes 1
ClientTransportPlugin obfs4 exec /etc/tor/lyrebird managed
%include /etc/tor/bridges.conf

отдельное спасибо челу с лора который единственный на весь интернет внятно показал что надо запускать транспорт с параметром managed - без этого у меня ничего не работало, не давая никаких внятных сообщений в логи.

  1. в файл /etc/tor/bridges.conf надо написать
Bridge obfs4 IP:PORT ДЛИННАЯ_СТРОКА cert=ДЛИННАЯ_СТРОКА iat-mode=2
UseBridges 1

строчку с параметрами мостов можно взять из тор браузера или с сайта тора (его на удивление плохо блокируют, как рутрекер какой-нибудь), или из тг канала, или из почты, в общем куча способов есть

  1. перезапустить тор через service tor restart

ну и после этого у меня заработало. скорее всего не хватит места на роутере, у обфускатора жирный бинарник на 22 мб, так что может потребоваться расширить хранилище на роутере за счёт флешки.

Можно сделать меньше исключений, в Туркменистане и Беларуси нет никаких реле Tor, в Кыргызстане одно реле, в Казахстане три (на самом деле одно). Если есть сомнения в поведении реле - напишите на bad-relays AT lists DOT torproject DOT org