Tor Expert Bundle и настройка конфига torrc

Как бы то оно не было, если не сегодня, то завтра тунели отвалятся и появятся новые. Придётся бегать смотреть работающие тунели (obfs4 у меня работает 5% от предлагаемых). Был бы инструмент по аналогии https://torscan-ru.ntc.party/ для поиска незаблокированных тунелей — пользы будет больше (и вреда — РКН может просто начать парсить список).

@Xunlei Ответ разработчика портативного Тора на критику сообщества NTC

Хочу спросить, а можно как то настроить, чтобы средний и выходной ip стран отличались, в последнее время часто замечаю одинаковые страны. Знаю можно просто вручную прописать сюда - такие, туда - другие, но нуежели нельзя автоматически это настроить?

Не знаю, предполагаю что и нельзя без модификиции (удобный недостаток для time атаки). Подобным вопросом задавался для выбора релеев для dnscrypt, по итогу просто маршруты захардкодил.

Жаль, придется вручную собирать…спасибо за ответ. Насчет dncrypt не понят, там же другая система, есть ли смысл? Всегда выбираю один сервер, до которого меньше пинг и anon, до которого тоже пинг небольшой и все

Если выбирать по пингу то смысла точно не будет, т. к. релей вероятнее попадётся от того же оператора, что и сервер. Для повышения resiliency настроил шесть серверов.

Или я чего то непонимаю, или мы о разных вещах говорим. Там же проименовано все. Запускаю по дефолту без выбранного сервера, он чекает и дает список по пингу, выбираю из первых один нужный оптимальный (не всегда самый первый и близкий), а потом выбираю близкий релей исходя из страны первого так как пинг суммируется. Это если я dncrypt сервера использую. Сейчас временно на DOH, а там с ODOH тяжко идет, так что без релея

Вот такая ошибка при просмотре Ютуба возникает:

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

Речь идёт о нидерландском 5.255.124.150 и хорватском 45.95.169.227, у них обоих пропускная способность в районе 20 mb/s (на практике по спидтесту получается выше, в районе 30-40 mb/s) и они сравнительно непопулярны. На вебтуннелях получается скорость приемлемая для просмотра 4К на Ютубе. На диапазоне 45.95.169.223/26 такой ошибки не возникает, но скорость там не всегда достаточная для просмотра видео в 4К (45.95.169.227 самый быстрый на этом диапазоне). Притом ошибка, как и вся борьба с Тором у Ютуба, возникает только на некоторых видеороликах. Я тестировал ту самую blue lagoon. Это если что вот.

Может у кого есть идеи как это фиксить? КРОМЕ того чтобы захардкодить под ютуб только определённый экзит. Я автор портативного Тор Эксперта которым пользуется в районе 1000 человек, занимался оптимизацией под 4К, и выскочила эта проблема. Если использовать самые популярные торовские ip-шники, там вообще своеобразный блок на них стоит, с ошибкой “видео недоступно”, который не прорвать никак. А вот это я надеялся хоть как-то прорвать, никак не получается, защита Ютуба тригерится.

Когда количество активных мостов в моей конфигурации превысило 64 начал получать Bootstrapped 100% (done): Done лишь через минут пять после запуска, чтобы вернуть скорость старта добавил параметр:

MaxClientCircuitsPending 64

Ещё для snowflake и webtunnel мостов полезная опция для тех, у кого ISP не предоставляет IPv6:

ClientPreferIPv6ORPort 0

а зачем столько мостов? если они постоянно отваливаются можно скачать валдиковский чекер мостов, посадить его в папку /etc/tor/ и запустить

#!/bin/bash 
        while true
        do
                rm -f /etc/tor/bridges.conf
                python torparse.pyz --torrc --outfile /etc/tor/bridges.conf
                systemctl restart tor
                sleep 1h
        done

и каждый час скрипт будет автоматически приносить свежие мосты которые будут точно работать, при желании можно без sleep обойтись, но мне неохота его в cron пихать.

если винда то в принципе можно и батник сделать который делает по сути то же самое, не думаю что его сильно менять придётся.

не все сидят на vanilla
у меня например резервный конфиг с 128+ webtunnel хотя бы часть работает и ладно

Спойлер

https://photos.app.goo.gl/adnhgtgm4BD7fZHv7
https://photos.app.goo.gl/UadawdQZjjBN3kX5A

Вопрос знатокам:
как в конфиге тора задать опцию смену exit-node в определенный промежуток времени?
и
как настроить браузер Firefox на использование тора? никак не хочет ходить по ссылкам .onion, некоторые рекомендуют изменить в конфиге network.dns.blockDotOnion на false, но и это не помогает, хотя в TorBrowser (который с torproject.org) иммеет network.dns.blockDotOnion = True, что как то вообще не логично (или я чего то недогоняю)

Конкретно exit-node не знаю, но полностью перестроить маршрут каждые 5 минут:

NewCircuitPeriod 300

Помимо этого нужен чтобы файрфокс резолвил .onion имена. Это делается либо через включение опции Proxy DNS when using SOCKS v5, либо необходимо создать зону .onion на вашем DNS резолвере и отфорвардить на порт DNS тора, который задается DNSPort в torc (желательно отключив кэширование для этой зоны).

А network.proxy.socks_remote_dns вы включили? По умолчанию отключен.

эти опции тоже надо?

AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

Нужно, если есть необходимость в резолвинге .onion зоны при DNS запросе. Если только браузер ходит передавая адрес через Proxy DNS when using SOCKS v5, то не обязательно.

@LeonMskRu почитай ЛС

Спасибо!
с network.proxy.socks_remote_dns работает.
однако смысл опции network.dns.blockDotOnion остается загадкой.

Спасибо за ответ. Я правильно понимаю, что при использовании tor все DNS запросы идут через exit-node?

Если настроен Proxy DNS when using SOCKS v5 и проксификация через TOR, то да. Для избегания этого я настроил между тором и браузером менеджер тунелей GOST для локального резолвинга с политиками блокировок и кешированием.

смысл опции network.dns.blockDotOnion остается загадкой

Настройка network.dns.blockDotOnion=true (именно true) нужна, чтобы если:

  1. network.proxy.socks_remote_dns=false (т.е. DNS идёт не через socks прокси, а напрямую) или
  2. Если прокси отключен
    то чтобы dns запрос onion сайта не отправлялся на системный dns резолвер. Т.к. это лишено смысла и небезопасно:
  3. Системный dns резолвер не знает про onion.
  4. Нечего ему знать какие onion сайты запрашивает браузер.

Так что network.dns.blockDotOnion=true это лисий дефолт, в том числе тор браузера.