Есть момент с конфигом:
UseBridges 1
ClientTransportPlugin obfs4 exec /path to lyrebird.exe/
перед адресом моста надо добавить Bridge иначе выкатывает ошибку конфига
Какой аргумент для запуска tor.exe надо указывать для добавления нужного конфига ? по умолчанию он подхватывает из папки Roaming\ещк в Windows
Спасибо за ответ. Ещё один вопросик:
если в конфиге torrc не указана строка GeoIPv6File или указан правильный путь до файла geoip6 то запуск tor.exe останавливается после пункта Opened Socks и так висит. Но если указать неправильный путь до файла geoip6 в строке GeoIPv6File после сообщения [warn] Failed to open GeoIP file всё успешно работает. В связи с этим вопрос, как отключить в конфиге ipv6?
В примере OutboundBindAddress адрес IPv4, этого достаточно, чтобы тор и мосты не лазили по IPv6 (по крайней мере, у себя не разу не видел IPv6 подключений). Этот параметр может быть объявлен несколько раз для перечисления возможных адресов для биндинга (в том числе и IPv6). Есть ещё опция OutboundBindAddressPT только для транспортных плагинов.
Как ультимативное решение — разрешить в брандмауэре защитника Windows для транспорта подключение только по TCP к 0.0.0.0/0 (либо запретить 2000::/3).
Попробовал запускать с этими параметрами, но увы tor виснет так же на строке “Opened Socks listener connection (ready) on 127.0.0.1:9050”. И пока что выход это прописывать неверный путь в конфиге для GeoIPv6File
Вроде стал понимать проблему, пробуйте запустить тор прокси на виртуальной машине с вашим конфигом, если заработает — то это какая-то проблема с вашей ОС, в которой, возможно, поломан IPv6.
Должно быть в логах что-то вроде такого:
[notice] Opening Socks listener on [::1]:9050
[notice] Opened Socks listener connection (ready) on [::1]:9050
[notice] Opening DNS listener on [::1]:9053
[notice] Opened DNS listener connection (ready) on [::1]:9053
Посмотрел код функции geoip_load_file, да, сначала он открывает файл tor_fopen_cloexec, затем пишет в лог Parsing GEOIP %s file %s., затем парсит. Похоже у вас зависает на fopen, можно попробовать удалить файл и заново его распаковать из архива, попробовать открыть, попробовать сократить длину пути каталога, попробовать использовать только латиницу в пути.
Попробовал на виртуалке Win 7 и Win 10 версии 13.5.3 и 14.0a5. С путями к исполняемым файлам вроде всё ок. И такой же залип на “Opened Socks listener connection (ready) on 127.0.0.1:9050”
На win 7 до сих пор запускается )))
Действительно, стоило закомментить строчку Log notice как GeoIPv6File успешно распарсился и tor запустился. Спасибо!
(Просто как то не уловил связь между логгированием и залипанием при открытии geoip6)
А это вы первичный автор конфигурации или тоже её откуда-то взяли? В любом случае в отличие от того тролля, meeeeeh, полагаю вас хоть в кой-то степени профессионалом, а не диванным держателем двухста obfs 4.
Я с ней работал. Из неё взяты SafeLogging 0, HardwareAccel 1, AutomapHostsOnResolve 1, ну и UseBridges 1. Пользу остального не совсем понял. Очень много работал применительно именно к Ютубу, как в общем-то в своей теме и сказал. Отсюда хорватские выходные ноды, ибо с множеством других кантринодов при просмотре Ютуба возникают ошибки. Что я собственно и на ntc когда-то вроде обсуждал. Поэтому я смотрел пользу параметров для стабилизации Ютуба. По итогу разницу чувствовал только от замены выходных нодов.
ExcludeExitNodes {US},{RU},{BY} - не совсем имеет смысл, зачем исключать только {US} из западных стран? Чем {US} хуже чем например {DE}? По какой-то причине казахские ноды также на Ютуб давали те же геоблокировки, что и россиянам с белорусами. AvoidDiskWrites 1 убрал, ибо программа и так совсем немного весит. NewCircuitPeriod 300 тоже убрал, ибо не увидел на тот момент разницы с различными значениями с ним и без него. Оптимизировал конфиг для предельно конкретных вещей и на тот момент это был просмотр Ютуба. Я вам могу показать результаты и разницу, если получу стопроцентную воспроизводимость.
Возможно Ютуб стабильнее всего работает именно на хорватских выходных ибо они, как и сказал meeeeeh (после того как ему указали по лбу их существование), все в одной подсети находятся, и Ютуб не считает подозрительным такой трафик, а возможно дело всё же в их сравнительной непопулярности (до того как я повлиял на их использование россиянами для обхода замедления).
Я открыл исходники тора, перечитал параметры в файле документации
Что-то натяпляпил, что показалось важным, что-то видел у других, уже не помню (начал пользоваться на постоянку с 2013-ого года).
Не помню уже какую задачу решал, может в момент написания мне мешал региональный бан. Это всего лишь пример.
Эту рекомендацию где-то встречал для затруднения временной атаки, мне в принципе особой разницы нет.
Уже больше года урлы *.youtube.com начал пускать в обход тора через другую проксю по причине невыносимости ежедневного разгадывания светофоров, мне это было проще сделать, чем регулярно добавлять в исключение забаненые выходные ноды.
