Closed AerialAirwaves closed 1 year ago
- Контрмеры против блокировок TORа
Всё что относится к доп.настройкам Tor (ipv6 и пр.) не имеет прямого отношения к ruantiblock. Пожалуй, нужно в вики написать про необходимость бриджей теперь...
- Отделение Transparent proxy от TOR
При следующем обновлении добавлю ещё один режим - прозрачного прокси (PROXY_MODE=3). Тоже самое, что и Tor, но без .onion. Помню, когда-то тестировал redsocks в Tor-конфигурации и всё прекрасно работало, но, согласен, что концептуально лучше разделить конфигурации. Тема с прозрачным доступом в .onion очень опасна и я, честно говоря, считаю это плохой практикой (изначально не нужно было добавлять эту возможность вообще). Поэтому .onion оставлю только в Tor-конфигурации.
- Outline (и HiLoad VPN)
Если там shadowsocks прокси (судя по этой инструкции), значит можно через redsocks в него трафик заворачивать?
Помню, когда-то тестировал redsocks в Tor-конфигурации и всё прекрасно работало
Так и есть.
Если там shadowsocks прокси (судя по этой инструкции), значит можно через redsocks в него трафик заворачивать?
Да, оно умеет поднимать socks5 и, следовательно, можно на shadowsocks-libev поднять socks5, и затем задействовать redsocks для создания transparent proxy. Такой сценарий вполне рабочий, хотя можно и несколько проще. Как я писал ранее, shadowsocks-libev сам умеет поднимать прозрачный прокси через ss-redir, так что redsocks для этого совершенно не обязателен.
Всё что относится к доп.настройкам Tor (ipv6 и пр.) не имеет прямого отношения к ruantiblock
В таком случае, получается, и к проекту нет никаких вопросов по существу, если смотреть на него как на компонент решения задачи, а не как на расширяемое решение всей задачи. Справедливости ради, с этой ролью отлично справляется, - спасибо. Но тогда, получается, Issue как таковой не имеет смысла. Не сюда, наверное, это нужно было. Я просто идейно намекнул на пару вариантов, как из проекта получить полное решение в текущих реалиях без необходимости вкладываться в приобретение VPN'а. Не для себя или вас, а для будущих пользователей.
Чуть более, чем полгода назад перенес домашний роутер с Padavan на OpenWRT и использую ваш проект. Использую не как готовое решение, а с некоторой "доработкой напильником", т.е. в несколько нестандартном сценарии, и, возможно, некоторый частный опыт мог бы пригодиться как идеи для дальнейшего расширения проекта.
1. Контрмеры против блокировок TORа
Я думаю, известно, что где-то с осени 2021 в России блокируются выходные узлы. Решений этому есть несколько. Можно, как некоторые пишут, использовать relay'и. А можно задействовать 6in4 или 6to4, и принудить TOR цепляться только к IPv6 выходным узлам. И вот второй вариант, на мой взгляд, наиболее поддается автоматизации. По меньшей мере, до недавнего времени я использовал Tor как халявный VPN и такое быстро сочиненное еще осенью 2021 года решение работает до сих пор. 6to4 поднимается, вообще ничего не требуя. Для 6in4 же нужна регистрация у одного из брокеров туннелей и последующее указание реквизитов для подключения. Из потенциальных проблем только то, что провайдер может уже выдавать IPv6 и тут нужно смотреть: если подключение к тору не блокируется через IPv6, то оставлять провайдерскую конфигурацию WAN6, иначе же заменять на 6in4 или 6to4.
2. Отделение Transparent proxy от TOR
В настоящий момент для обхода в вашем проекте существует 2 сценария: VPN, т.е. маршрутизации на интерфейс; и TOR, использующий сквозной прокси соответствующего демона.
А что если механизм обхода, который используется, предполагает задействование прозрачного прокси. Будь то socks5 прокся, обернутая в прозрачную через redsocks или shadowsocks подключение.
Тогда при текущей архитектуре проекта единственным вариантом интеграции является подмена порта торовской прозрачной прокси на используемую. Но возникает 2 аномалии: ruantiblock пытается стартовать тор, предполагая использование стандартного сценария. С другой же стороны, даже если тор и установлен и запускается при такой конфигурации, - к .onion ресурсам банально не достучаться, ибо очевидно, что подцепленный вместо тора сквозной прокси не обязан маршрутизировать TORовские частные IP. Т. е. при таком сценарии от тора получается никакой выгоды, - он работает впустую.
Возможно, стоит выделить TOR как вспомогательный компонент, реализующий 2 независимые роли: предоставление доступа из локалки к .onion ресурсам и средство обхода блокировок как частный случай прозрачного прокси. И затем оставить пользователю выбор, условно 2 опции конфигурации - "Tor необходим при работе" и "предоставлятьиз локалки доступ к .onion". Вторая опция принудительно включает первую, т. е. ruantiblock при старте стартует тор, только если явно указано, что он необходим, или если он используется для предоставления доступа к .onion. Притом при настройке прозрачного прокси оставить адрес прокси тора по умолчанию.
Думаю, так решение получится гибче и притом настройка обхода через тор станет не сильно сложнее, чем сейчас.
3. Outline (и HiLoad VPN)
Среди халявных средств обхода, помимо Tor'а существует проект HiLoad VPN (легко ищется в телеге), заявленная цель которого - создать бесплатное средство обхода цензуры. Построено оно на Outline, который фактически, - косметическая надстройка над shadowsocks. В репозитории OpenWRT есть shadowsocks-libev, через которую можно подцепиться к shadowsocks и сделать для нее как прозрачный прокси, так и socks5. Но последнее бесполезно, ибо нельзя роутить пакеты в socks5, а tun2socks в репах OpenWRT нет. Почему бы не сделать автоматическую конфигурацию Outline клиента как источника обхода блокировок. Там, фактически, нужно распарсить реквизиты сервера из строки-ключа подключения, сунуть shadowsocks-libev шаблон конфига, в который в нужные места сунуть реквизиты подключения. Относительно несложная процедура. На худой конец, можно сделать подробную инструкцию как более сложный, нежели socks5 прокси в связке с redsocks, пример настройки обхода через прозрачный прокси.