Комментарии 60
Годнота! С нетерпением жду когда будут автоматически выкладываться отфильтрованные списки url'ов.
Я роучу через прозрачный nginx по sni_name. Расстраиваюсь от того что приходится держать в нем целую кучу бестолковых и давно неактуальных записей жрущих память.
Как вариант, можно поднять на домашнем роутере nfqws и указать, чтобы он сам пополнял список заблокированных ресурсов. Т.е. при первом столкновении с таким ресурсом он понимает, что ресурс блокируется, добавляет его в список и дальше уже всегда "дурит" трафик, адресованный ресурсу.
Таким образом, обход блокировок применяется лишь к ресурсам, которые пользователь реально хочет посетить, силы не отвлекаются ни на зеркала казино, ни даже на заблокированные домены, которые пользователь не посещает. Бонусом это позволяет обходить и непубличные блокировки а-ля YouTube/Discord, поскольку способ не полагается на какие-либо публичные списки.
Минус: невозможно попасть на сайты, которые сами со своей стороны блокируют доступ россиянам, но таких сайтов несравнимо меньше.
Dogsfanos.ru - квадроберы же :)
Спасибо! Давно напрашивалось! Подключился. Работает.
вот это весьма и весьма интересно, благодарю, вы сделали то что говорили многие но все ленились.
Youtube бы прикрутить )
материал огонь! лайк, подписка, колокольчик
Twitter / X не грузит фото/видео без этой подсети 146.75.88.158/31
Список очень полезный, пригодится.
Может кто подскажет решение для роутеров чтобы заворачивать только https соединения с конкретным sni через прокси? Я вот гуглил, да не нагуглил. А пускать весь трафик через vpn/proxy не удобно. Пришлось пилить своё решение:
https://github.com/Jipok/dpi-bypass-proxy
Оно конечно работает. Но всё равно при нескольких толстых соединений скорость проседает и роутер бывает подглючивает. Лучше стало когда я перешёл с socks5 на wireguard в ядре, но до конца проблему не решило.
Я начал переписывать на использование nfqueue, но так и не смог найти как перебросить(заблочить то легко) соединение на другой интерфейс. Как только с mark и conmark не возился, но так и не смог осилить. Смотрел в сторону ebpf, но что-то как-то сложно и лень изучать.
Я так понимаю, вы хотите выборочную маршрутизацию по доменным именам. Можно поднять контейнер АнтиЗапрета (OVPN/WG/IPSec) на своём сервере.
При правильной настройке через VPN-туннель пойдёт трафик до заблокированных ресурсов, а до незаблокированных пойдёт напрямую. Можно использовать как список РКН, так и собственный (например, список из этой статьи).
Есть поддержка WireGuard Amnezia и XOR для OpenVPN (на роутере соответственно клиент должен это уметь), чтобы обходить блокировку протоколов.
А оно именно по sni работает, не делает dnslookup и потом по ip роутит?
Но даже так, что-то жирновато выглядит для роутера. И как условный телевизор подключать? Прописывать там что-то не вариант. Заворачивать весь трафик с роутера на сервер и оттуда обратно по производительности даже хуже моего решения выйдет. Да и на сервере всякий софт крутится, которому тоже vpn иногда нужен.
Оно работает не по SNI. Там решение на основе DNS. Только не совсем как вы написали. Заблокированным доменам присвается фейковый IP, и при обращении на этот IP запросы пересылаются на IP реальный.
Я тоже пыталась найти решение для роутинга по SNI, но к сожалению не очень успешно. Есть софт под названием sniproxy, проблема в том, что он не поддерживает HTTP/2 и HTTP/3 (QUIC), которые на сегодняшний день являются стандартом де-факто. Автор в курсе проблемы, но вместо того чтобы как-то это пофиксить, просто заабандонил проект.
а как оно может не поддерживать HTTP/2 если SNI идет на уровне выше от него?
или оно все же полноценное прокси?
На странице проекта написано, что не поддерживает
Заворачивать весь трафик с роутера на сервер и оттуда обратно по производительности даже хуже моего решения выйдет
Никто никуда весь трафик не заворачивает. Трафик, адресованный navalny.com, роутер отправляет в VPN-туннель, через ваш зарубежный сервер. Трафик, адресованный kremlin.ru, роутер направляет как обычно, через вашего провайдера.
И как условный телевизор подключать?
Телевизор получает интернет от роутера, на роутере поднят VPN-клиент, трафик до "запрещёнки" идёт через него.
что-то жирновато выглядит для роутера
Докер-то будет не на роутере, а на зарубежном сервере в интернете. На роутере только VPN-клиент.
А оно именно по sni работает
Нет, но если вам именно с перламутровыми пуговицами, то не подойдёт.
выборочную маршрутизацию по доменным именам
я для этого использую прокси 3proxy:
# direct
allow * * *.ru,*.yandex.net,*.yastatic.net
# proxy
allow *
parent 1000 socks5 proxy.digitalocean.com 1080
технически можно адаптировать для списков ркн, автоматически создав для каждого домена оттуда allow-запись
само собой чтобы это работало нужно резолвить адреса на стороне прокси
Дисклеймер:
для
товарищейгосподинов майоров: эта инструкция просто про настройку роутинга по sni в Русском веб сервере Angie. Я не имею возможности знать кем и для чего эта инструкция может быть использованна.для пользователей: неправильное использование этой инструкции может привести к нежелательным последствиям, просмотра того что Вам смотреть запрещено в Ваших интересах. Будьте осторожны!
В качестве прокси используется Русский державный православный сертифицированный майором веб сервер Angie (но если Вы поддерживаете Обаму (тьфу на Вас) и/или из "этих" (тьфу на Вас еще раз) - Вам подойдет вражеский nginx).
Околоминимальный скелет конфигурации:
angie.conf
# Instanse 1
stream {
# Мапы $ssl_preread_server_name -> 1 или 0 (default)
include /opt/config/broken_hardware.conf;
include /opt/config/custom.conf;
# Удобно потом в лог выводить на основе чего была маршрутизация
map $custom_hosts:$broken_hardware_hosts $upstream_name {
0:1 {{ instance2_ip }};
1:0 {{ instance2_ip }};
1:1 {{ instance2_ip }};
default $ssl_preread_server_name;
}
server {
listen 443;
resolver {{ external_dns_ip }} ipv6=off;
proxy_pass $upstream_name:443;
ssl_preread on;
}
}
# Instance 2
stream {
server {
listen 443;
resolver {{ external_dns_ip }} ipv6=off;
proxy_pass $ssl_preread_server_name:443;
ssl_preread on;
}
}
Что-то не пойму. Это два физических сервера надо? Или второй инстанс в контейнере поднять можно?
Я конечно могу ошибаться, но это не отличается от моего решения с технической точки зрения. nginx ведь тоже будет пакеты копировать в userspace, т.е. всё те же просадки скорости и перегрев. Роутеры слабые ведь.
Хотелось бы чтобы ядро само управляло пакетиками, а софт только решал на уровне соединений через какой интерфейс трафик пускать.
Я поступил иначе и раздаю с роутера (на самом деле нет, но не важно) файл .pac с правильными прокси. Браузер сам послушно сходит куда надо и не надо перехватывать https. Но браузеры придется настроить один раз. И хромоиды не подхватывают .pac через file://, только http(s).
PS я где-то что-то видел про раздачу .pac через DHCP, но не уверен, что мне не показалось и что это реально работает.
Очень полезная работа проделана, планируется ли сразу .pac файл генерировать для SwitchyOmega например? Чтобы подставил свой SOCKS5 сервер в него и готово. BGP штука полезная, но не особенно удобная если надо "на лету" переключать точки выхода трафика.
у меня не было опыта создания pac файлов, создал тестовый по аналогии с anticensority, можете попробовать https://raw.githubusercontent.com/1andrevich/v2box/refs/heads/draft/draft.pac
Вот тут https://bitbucket.org/anticensority/antizapret-pac-generator-light можно посмотреть как оно все устроено.
Можно ли разобрать список с помощью apt install golang git? Как сделать? Если это возможно
Звучит так, как будто кто-то смог сделать существование РКН чуть более осмысленным. Спасибо, брат!
включая IP адреса серверов Discord
Что значит адреса Discord, если (как минимум) серверы для звонков - это запускаемые/останавливаемые инстансы? Для каждого региона резолвились по DNS типа region-[0-999]?
Я как-то писал скрипт резолвинга, потому что Discord блокировал со своей стороны одну подсеть Hetzner (ту что в Falkenstein, но не финнов).
те адреса которые удалось найти онлайн List of all of discord's voice servers as of 08-03-2020 (github.com) , для нормальной работы голоса в Discord надежнее направлять набор соответствующих портов UDP через прокси
Успешно завел для xray на роутере keenetic, вроде всё работает, за исключением inst с телефона не грузил, хотя веб работал. Вечером буду вылавливать домены которых нет в dat файлах
Спасибо за такое колличество статистики, много где пригодится, да и наработки что надо!💪

Про резку забыли не нашел в списках?
по какой-то причине не попала в список, за всеми ресурсами не смог уследить, можете предложить в community list Pull requests · 1andrevich/Re-filter-lists (github.com)
а ipv6 планируется?
поднял с Вами BGP, а оттуда только v4 прилетает =( пришлось вернуться на antifilter.network
Спасибо за BGP. Большая проблема с антифильром в том, что почти весь cloudflare там. И маршруты зачастую ходят через VPN, даже когда не нужно. У вас лист чуть почище.
Еще раз спасибо, великолепная работа.
Можно такое же, но для Молдовы?
"Если в списке РКН так много мусора, почему бы вообще от него не отказаться?"
В ДНК тоже не мало мусора...
На этом этапе я брал список доменов у Antifilter.download и фильтровал по ключевым словам
См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/master/config/exclude-regexp-dist.awk, здесь ключевые слова, которые отсеят зеркала, присутствующие в вашем списке.
На этом этапе (step 2 в исходниках) проверялось два основных критерия -
Доступность сайта по одному из способов - ping, http, https
Увы, не всегда сработает с доменами, заблокированными по *.зоне
— на корневом домене может не быть записей, но домен при этом может активно использоваться. Либо же домен может не отвечать на ICMP и стандартные порты.
3-ий этап [...] был самым ресурсозатратным, по сути похож на первый, но на этом этапе нужно отфильтровать в том числе припаркованные домены и сайты с нормальными доменами, но бесполезным содержимым
Один из вариантов оптимизации фильтра припаркованных доменов — по именам из NS-записей или по IP-адресам ответов. См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/1cef07bd0d6c17e9668e244925c32af100aa97be/scripts/resolve-dns-nxdomain.py#lines-28
Это быстрее, но необходимо вручную собрать адреса парковочных страниц/NS.
Если совместить однократное/редкое сканирование по ключевым словам внутри страницы, а из результатов сделать список NS/IP, то процесс значительно ускорится.
В этом случае также разумно применить уплощение до зоны, это уменьшит количество доменов.
По итогам этого этапа осталось 41598 доменов
Ваш вариант со сканированием ключевых слов выглядит эффективным. Анализировали ли вы ложноположительные срабатывания? Список получился подозрительно маленьким.
Мой основной интерес это роутеры, которые могут использовать в основном суммаризованные списки IP адресов
Блокировки осуществляются по доменам, и маршрутизировать их нужно по доменам. Однако маршрутизация так не работает. Все пытаются использовать существующие неподходящие инструменты, и не могут выбраться из этой парадигмы. Сбор IP-адресов — бесперспективное занятие, даже в сравнении с альтернативными, не менее костыльными методами.
Возможные решения описал здесь: https://ntc.party/t/варианты-маршрутизации-отдельных-доменовпрограмм-в-vpn/11408
Итого: первое соединение либо разрывается из-за несовпадения адресов, вызванных внезапной сменой маршрута, либо «зависает», по аналогичной причине. Последующие соединения (если IP-адрес тот же) будут устанавливаться успешно. Если у домена несколько адресов, аналогичные проблемы будут для каждого адреса.
...
Техническое решение этой проблемы однозначно осуществимо, но мне неизвестны ни готовые программы, ни даже наработки в эту сторону. Одна из тех проблем, где нужно просто взять и сделать ПО, но из года в год никто не делает.
К сожалению, я не видел вашего поста и пытался реализовать сам. Пришлось повозиться с отправкой RST, но зато я уяснил бесперспективность этого пути. Кажется что у ядра нет никаких механизмов "переиграть" соединение отданное в userspace. Но даже если с помощью ebpf или какого-нибудь модуля ядра получится красиво объединить/редиректнуть соединение, то не стоит забывать про сервер. Каждый запрос к заблоченному сайту будет каждый раз слать tcp-handshake, который хоть как надо отправить как есть. И моё кратковременное тестирование показало, что помимо того что браузер "ломается" от разрывов соединений, я стал очень часто видеть капчу по причине "Ваше запросы похоже на автоматические..."
Ну и программы могут использовать какой-нибудь свой протокол(или вообще любой помимо https). И запросы пойдут напрямую.
А если добавлять после первого подключения ip в таблицу маршрутизации чтобы система сама все запросы к этому ip проксировала, то какой смысл возиться с сетевым стеком, если можно поднять днс-сервер/прокси который также будет применять правила маршрутиризации? И ведь в этом случае будут работать любые другие протоколы. И UDP тоже.
Ну в теории. Я сейчас для себя использую вариант с чтением ответов от днс-сервера с помощью nfqueue. Все сайты работают отлично, роутер как будто вообще не ощутил нагрузки. Но вот в дискорде связь не работает. И я не пойму почему, а навыков в wireshark не хватает чтобы разобраться. Есть идеи?
Была ещё идея объединить прокси(который в master) с добавлением правил ip route. Сделать так, чтобы на прокси в userspace слались только первые соединения к новому для этой сессии ip. Прокси добавит нужное правило маршрутизации, ну а текущее соединение отработает в ручном режиме, ну с splice. Но тогда в таблицу маршрутизации придётся добавлять вообще все подярд ip и я не знаю как это скажется на системе.
И профит по сравнению с днс-прокси будет только если у клиента какой-нибудь не отключаемый dns over tls. Зато потеряется проксирование http/3 трафика, ибо у того sni не прочитать.
спасибо большое за подробный отзыв и советы! подробно не разбирал, но сталкивался с тем что по некоторым тегам для потенциально мошеннических сайтах ошибочно фильтруются некоторые СМИ, например:
"2024-09-11 10:54:43,424 - INFO - Domain reported: thebell.io contains suspicious content. Keywords: ставки, ставка, доход, кредит "
Из-за чего для итогового списка убирал некоторые ключевые слова и увеличил количество совпадений для отсеивания
Из чего следует вопрос, а действительно ли нам нужны все эти заблокированные адреса и домены?
Мой ответ - нет, и вот почему
возможно я пропустил, или никто не писал, но а как же разделегирование домена в ru-зоне? как это было с одним сайтом для скачивания файлов. реестр уменьшится на 30% точно
Попробовал в Zapret новый скрипт, get_refilter_domains.sh, который пушит из вашего репозитория - перестало работать приложение инсты на iOS. Глубоко не копал. Никаких претензий, просто FYI
@Andrevich, а вы не сталкивались с тем, что при любом варианте проксирования через V2rayA, отваливается Яндекс.Музыка?
Я пробовал и правила из текущего поста:
default: direct
ip(geoip:refilter)->proxy
domain(ext:"LoyalsoldierSite.dat:refilter")->proxy
И правила старые с антифильтром:
default: direct
# write your own rules below
ip(geoip:antifilter)->proxy
ip(geoip:antifilter-community)->proxy
#domain(ext:"LoyalsoldierSite.dat:antifilter")->proxy
domain(ext:"LoyalsoldierSite.dat:antifilter-community")->proxy
domain(domain: youtube.com) ->proxy
domain(domain: googlevideo.com) ->proxy
И ручками добавлял ТОЛЬКО то, что нужно проксировать:
default: direct
domain(contains: discord) -> proxy
domain(domain: youtube.com) ->proxy
domain(domain: kino.pub) ->proxy
domain(domain: googlevideo.com) ->proxy
domain(domain: medium.com) ->proxy
domain(domain: instagram.com) ->proxy
domain(domain: cdninstagram.com) ->proxy
domain(domain: facebook.com) ->proxy
domain(domain: fbcdn.net) ->proxy
И даже пытался принудительно все домены и адреса Яндекса направить в директ.
Во всех вариантах всё работает, но Я.М стартует, песню, иногда две играет, а потом замолкает и нужно перезапускать.
Браузерный чуть лучше и дольше живёт, но в итоге так же...
Здравствуйте! А я правильно понимаю, что " список IP адресов полученных из резолвинга - 23434 IP адреса " - это вот как раз почищенная база антифильтра, в которой изначально около 90к адресов (ip.lst с их сайта)? Я просто забираю у них все 90к адресов по 32 маске, скриптом формирую на впс роутинг-таблицу и раздаю ее по bgp впн-клиентам. Но 90к, конечно, не всякий микрот прожует (все, что похуже ac2, уже захлебывается), а даже если и прожует, незачем плодить сущности, поэтому хотелось бы сохранить схему, но со списочком поменьше.
Было-бы еще неплохо иметь список ресурсов, которые сами блокируют подключения из РФ.
Я против т. н. фильтрации по ключевым словам, по маскам подсетей. Когда мы фильтруем по ключевым словам условные казино, мы отбрасываем нужды огромного количества людей, на том произвольном основании, что они нам не нравятся. Предположение, что РКН изначально является “хорошим органом” и “должен” фильтровать что-то, считаю абсурдным в своём основании. Когда мы используем подсети, допуская то, что будет отфильтровано и что-то лишнее, НИ К ЧЕМУ хорошему это не приводит. Соответственно идеальным вариантом является использование домёнов. И когда мы говорим об ограничениях по размеру, мы обычно подразумеваем реализацию антизапрета, стремящегося оптимизировать себя под старые браузеры. У антизапрета есть моральное основание даже на такую произвольную фильтрацию, какая произведена здесь, но если мы говорим об оптимизированном и очищенном списке, то о таком основании не может идти и речи. Соответственно, идеальной реализацией является быстрая, очищенная именно ОТ МУСОРА система, использующая точные домёны, но при этом затрагивающая максимальное количество заблокированных ресурсов, и работающая на современных машинах. В этом плане без примера антизапрета никуда. Но у антизапрета в отличие от маминых оптимизаторов есть огромная устойчивая проксисеть которой пользуется более миллиона человек в России, и об этом нельзя забывать.
Альтернативный список заблокированных в РФ ресурсов Re:filter