Сам себе Роскомнадзор

Список заблокированных РКН ресурсов для использования с VPN стремительно теряет актуальность, поскольку, во-первых, многие ресурсы блокируются или замедляются на ТСПУ и записи для этих ресурсов в выгрузку не вносятся, во-вторых, после известных событий конца февраля многие ресурсы начали изображать РКН из себя и блокировать доступ с российских IP, в-третьих, избыточная отправка трафика в VPN приводит к недоступности уже российских ресурсов, которые отгородились от иностранных IP.

При этом по сути в черном списке РКН 99% ресурсов - никому не нужный трэш типа стопятисотого зеркала очередного онлайн-казино.

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

Поэтому на уже известном сервисе antifilter.download создан отдельный дополнительный сервис community.antifilter.download, предназначенный для ведения списка при помощи сообщества.

В телеграм-чате antifilter.download любой участник может поставить на голосование через бота любой ресурс (будь то IP адрес, IP сеть, доменное имя или автономную систему) и если другие участники проголосуют за добавление - IP адреса ресурса будут добавлены в список, который впоследствии можно автоматически забирать с сайта сервиса или получать по BGP (пока что в виде размеченных BGP community 65432:500 префиксов в общем фиде antifilter.download - т.е. путем простейшей фильтрации по комьюнити можно использовать только префиксы от сообщества.

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

Посмотреть, какие голосования еще не закончились, и проголосовать можно, использовав поиск #vote по чату.

Подключить сервис к своему микротику можно по инструкции из вот этой статьи, внеся небольшие исправления - вместо команды:

/routing filter add action=accept chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1

нужно использовать две команды:

/routing filter add action=accept bgp-communities=65432:500 chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1
/routing filter add chain=bgp_in action=discard

Это примет маршруты и установит выходной интерфейс для нужных префиксов и отбросит все остальные.

Для версии ROS 7.x - сами постройте по аналогии.

На момент написания этого поста сервис генерирует 209 префиксов и 88 доменных имен.

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

Надеюсь, что сообщество у нас достаточно адекватное и в источник мусора список, собираемый им, не превратится.

Традиционно отвечу на вопросы в комментариях.

@Furriest
27.04.2022 00:56 UTC
Первоисточник

Комментарии

@GennPen
26.04.2022 20:11 UTC
+2

antifilter.download хорош до тех пор пока не начнешь пользоваться IPv6.
А отказываться от IPv6 как то уже не хочется.

@Furriest
26.04.2022 20:13 UTC
0

В комьюнити версию v6 добавить, в принципе, гораздо легче, поэтому в целом это всё не за горами.

@amarao
26.04.2022 20:12 UTC
+9

Мне кажется, надо делать наоборот. Есть чебуречные IP, которые надо пускать напрямую. И есть весь остальной интернет, который надо заворачивать в VPN. Т.е. вместо списка IP "для VPN" надо вести список IP не-для-VPN.

Экзотический подвид "фильтруемый РКНом сервис с русскими IP" можно считать вымершим.

@Furriest
26.04.2022 20:16 UTC
+4

Нет никакого смысла в такой конструкции, если вы, конечно, не скрываетесь от органов. Если вы готовы в большую часть интернета ходить через VPN - так и пропишите себе российское пространство IP статикой и дефолт в VPN. Набор российских IP часто не меняется, там BGP не нужен. И генерируется легко, в предыдущей статье был скрипт.

26.04.2022 20:24 UTC
+2

Пока самый оптимальный вариант - вычитать множество российских IP из множества заблокированных.

Практическую потребность в этом ощутил вот прямо сегодня, когда в взятом у Вас ipresolve.lst обнаружились IP сайтов Мосгорсуда и ещё пачки российских судов, которые, в свою очередь, в рамках недавнего параноидального огораживания госорганов, запрещают доступ с зарубежных адресов. Понятно, что кто-то из администраторов попавших в список доменных имён побаловался, но приходится вот так эту ситуацию отрабатывать...

@nidalee
27.04.2022 03:41 UTC
+1
Это все же заметно медленнее связки из местного и зарубежного сервера, когда трафик прогоняется через второй только по необходимости.
Но отменяторов и прочих любителей покрутить фильтры cloudflare в списке Антизапрета, конечно, не хватает. Хотя понятно, что он о другом.
@pfzim
26.04.2022 20:16 UTC
+5

Лечить надо причину, а не симптомы

@dartraiden
26.04.2022 21:13 UTC
+13
Роскомнадзор должен быть разогнан, тут, разумеется, никаких компромиссов быть не может.
27.04.2022 08:59 UTC
+8

Причина не в Роскомнадзоре, а немного выше. Но и эти "молодцы", конечно.

@ValdikSS
26.04.2022 21:22 UTC
+29

Мне подход с маршрутизацией IP-адресов и диапазонов кажется несостоятельным.

  1. В Реестр внесено множество доменов через звёздочку (блокировка зоны/поддоменов), и маршрутизировать через VPN нужно все поддомены конкретных доменов, а их не всегда можно узнать, они могут генерироваться динамически.

  2. Домены, использующие CDN или просто геобалансировку, отдают разный набор адресов, в зависимости от стран/провайдеров/резолверов. Надёжно собрать их IP-адреса может быть затруднительно. Также бывают домены, которые просто сравнительно часто меняют IP-адреса.

  3. Внереестровые блокировки часто затрагивают IP-адреса CDN-сервисов, которые можно перенаправить на доступные точки входа, а не маршрутизировать. См. Не открываются некоторые сайты за Cloudflare CDN, Google Cloud Functions, Внереестровая блокировка Google Firebase (firebaseapp.com, forms.gle, posts.gle).

VPN АнтиЗапрета маршрутизирует трафик по-доменно, а не по IP-адресам и диапазонам: https://bitbucket.org/anticensority/antizapret-vpn-container/src/
Это наиболее эффективный подход, к тому же работающий на любом устройстве с поддержкой VPN, без дополнительной настройки на стороне клиента. За ≈6 лет применения этого метода никто более так и не реализовал подобную концепцию.

В теме Как нам максимально улучшить доступность сервисов в России? я изложил свои нереализованные идеи, в основном затрагивающие расширение возможностей DNS-резолверов, которые позволяют достигнуть лучшей доступности, чем есть сейчас.

Напоминаю, что помимо блокировок по IP-адресам и доменам, в России на оборудовании ТСПУ блокируется протокол QUIC (HTTP 3), WebRTC (DTLS) через библиотеку pion — их вы одной маршрутизацией не исправите. Вот здесь недавно описал (почти) всё, что помню.

Если вы заинтересованы в создании действительно эффективных технических средств — добро пожаловать на ntc.party, давайте кооперироваться и придумывать вместе.

@
26.04.2022 21:27 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
26.04.2022 21:31 UTC
+6

Потому что пытались заблокировать механизм туннелирования snowflake Tor'а, но разработчики быстро определили и изменили фингерпринт в собственном форке библиотеки, а блокировку не убрали. Теперь snowflake работает, а стандартный pion в реальном софте — нет.

Также блокируют какие-то браузерные фингерпринты DTLS, еще не разбирался: Проблемы в работе ПО использующего WebRTC

@aborouhin
26.04.2022 22:24 UTC
0

С п.п. 1 и 2 сталкивался, да. Рабочая идея - всем клиентам локальной сети / VPN* прописывать свой DNS, на этом DNS парсить логи запросов и при совпадении с доменом/маской из реестра - добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.

По-быстрому сделать это несложно, но хочется не по-быстрому, а по-хорошему. Чтобы у ресловленных адресов в списке было какое-то время жизни, после которого, если есть новые адреса для этого же домена, старые отбрасываются. Чтобы маршрут к добавляемому таким образом IP не просто через некоторое время появлялся в таблице маршрутизации у всех клиентов, - а самое первое соединение того клиента, который сделал запрос к DNS, уже маршрутизировалось бы правильно. Ну и т.п. А тут уже время нужно, пока не дошли руки.

И есть некоторые проблемы, которые не решаются вообще. Ну, скажем, имеем ситуацию из п. 2. При этом мобильный клиент сначала был не подключён к локальной сети / VPN, при этом получил IP от другого DNS-сервера, закэшировал его и дальше стучится по этому IP. А у нас этот же домен ресолвится уже в другой IP, и поэтому запросы клиента не маршрутизируются куда надо.

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

27.04.2022 06:51 UTC
0

Зачем в этой схеме 2 VPS?

27.04.2022 10:35 UTC
0

На смартфон не особо передашь десятки тысяч маршрутов. А доступ к незаблокированным ресурсам и особенно - к своим локальным ресурсам, физически расположенным в России, хочется иметь без дополнительной latency 30-50 ms, которую добавляет зарубежный VPS.

27.04.2022 13:43 UTC
0

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

Прочтите концепцию https://bitbucket.org/anticensority/antizapret-vpn-container/src/

27.04.2022 13:47 UTC
0

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

@sacai
28.04.2022 15:02 UTC
0

с блокировкой WebRTC сталкивался по работе, причем блокируется именно шифрованный UDP-трафик, если соединение небезопасное, то не блокируется. правила фильтрации какие-то замудренные: иногда блокируется все, а иногда, например, только с определенным юзер-агентом. как-то раз сломал голову, почему входящий SIP-WebRTC звонок принимается в iOS Safari, но не принимается на том же устройстве в iOS-приложении. эффект всегда один и тот же: сигналинг по вебсокету бегает, а DTLS/ICE не проходит, пакетов просто не видно на стороне сервера.

при этом, если переключиться на TCP транспорт, то трафик не блокируется, видимо, не могут (пока?) разобрать пакеты.

@Moraiatw
27.04.2022 06:05 UTC
0

Изобретения велосипеда.
VPN есть VPN, не надо ему никаких списков.

@nidalee
27.04.2022 06:51 UTC
+4
Надо-надо, чтобы не гонять почем зря трафик по зарубежным серверам, набивая время отклика.
@doctorw
27.04.2022 07:13 UTC
0

По-моему очевидно, что списки это попытка снизить трафик через VPN, исключая из него то, что доступно и без него.

27.04.2022 09:07 UTC
+1

Сегодня доступно, завтра недоступно.

Во первых, скорость через VPN достаточна для того, чтобы даже смотреть видео онлайн в хорошем качестве без смс.

Во вторых, вся эта возня с выборочной маршрутизацией, парсингом черных списков, в попытке угнаться за запретительством РКН - бессмысленная и смехотворная деятельность. В этом посте дошли уже даже до какого то голосования, Карл! Вам не жалко своего времени?

27.04.2022 11:40 UTC
+2
Сегодня доступно, завтра недоступно.
Так это и в обратную сторону работает. Сегодня Госуслуги доступны через VPN, завтра начинается специальная военная война и они перестают быть доступны. Плюс ресурсы типа Авито, которые и до войны не пускали к себе с диапазонов хостеров. И мы всё равно приходим к выборочной маршрутизации.
27.04.2022 13:57 UTC
0

Да уже сегодня полно сайтов, которые не пускают с нероссийских IP. Госорганы за последний месяц огородились знатно. Я выше писал - вчера в списке от antifilter.download прилетел IP сайта Мосгорсуда (видимо, кто-то побаловался, помню такие истории со времён крестового похода РКН на Телеграм), так мои юристы сразу застонали. А ещё раньше моя родная мама, роутер в квартире которой тоже через мой VPN ходил и изначально был настроен именно что маршрутизировать через заграницу всё, не смогла по той же причине передать показания счётчиков в энергосбыт.

Так что если изначально у меня раздельная маршрутизация была только там, где роутер спокойно переваривал все маршруты, то после нескольких таких историй сделал её и для маломощных / мобильных клиентов по схеме "VPN-сервер на российском хостинге, с него отдельный канал на зарубежный VPS с выборочной маршрутизацией".

@DrinkFromTheCup
27.04.2022 08:48 UTC
+1

Пардоньте, мне не хватает навыка за разумное время вкурить самому, нужно пояснение.

Если домен заблокирован сами-знаете-кем, но при этом держатель домена - бедный больной человек, который расконфигурировал себе Cloudflare так, что через VPN'ообразные, как правило, не впускает вообще никого (Cloudflare мурыжит на окне с пятисекундным отсчётом, бесконечно), - этот способ поможет?

Надо будет вносить его сразу в список префиксов/IP, а не доменов?

@Furriest
27.04.2022 09:51 UTC
+1

Если клаудфларь не пускает через VPN - это решение, к сожалению, ситуацию не улучшит. Думаю, что оптимальным путем будет VPN с собственного сервиса, который ни с кем не разделяется и находится на IP, не входящем в известные пулы хостеров.
Но да, дорого.

@uyrij
27.04.2022 09:07 UTC
0

"Сам себе Роскомнадзор" == самостоятельно блокирую ненужные domains, ip (например рекламные сервисы). Как составить список ненужных сайтов ? Я так сначала понял цель статьи, но здесь о другом.

@
27.04.2022 14:15 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@Barnaby
27.04.2022 11:55 UTC
0

Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?

И еще можно сокс на микротике зароутить в интерфейс, чтобы каждый раз для проверки недоступного сайта фильтр в микротике не отключать? Нашел только как весь трафик с него зароутить, но это не совсем то =\

@aborouhin
27.04.2022 14:20 UTC
+1

Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?

Маршрут к более узкой сети при равной метрике всегда имеет приоритет перед маршрутом к более широкой. Так что достаточно прописать статические маршруты к приватным сетям.

@Furriest
27.04.2022 16:03 UTC
0

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

@divanikus
27.04.2022 18:58 UTC
0

Эх, ни один из предложенных списков не решает проблему аватарок в ютубе.

@Furriest
27.04.2022 19:01 UTC
0

Хм. Посмотрите в консоли хрома, с какого конкретно url они у вас тянутся и во что он резолвится. Можно добавить в список прямо как IP.

27.04.2022 19:05 UTC
0

yt3.ggpht.com и судя по всему у него динамически меняется адрес.

27.04.2022 19:10 UTC
0

Это cname для wide-youtube.l.google.com и оно действительно географически зависимое. Проблемы CDN качественно решаются, к сожалению, только на верхнем уровне модели, т.е. если вы загрузите список switchproxy в плагин своего браузера - всё будет работать.

@Barnaby
27.04.2022 19:33 UTC
0

Настроил через wireguard по старому методу, работает так себе - иногда сайты очень долго или вообще не открываются. Например, квест2 ~30 секунд проверял обновления и все равно не смог его скачать. При этом если зарутить весь трафик то работает хорошо, хотя скорость всего 30\50 vs 50\70 через прокси shadowsocks (хз почему, проц hap ac2 25/40%).

Имхо, лучше это все в впн-клиенте делать, чем на роутере. И быстрее и сильно проще будет.

@TimsTims
28.04.2022 08:56 UTC
0

Имхо, лучше это все в впн-клиенте делать, чем на роутере.

Тогда весь трафик будет идти через впн сервер. А значит пинг вырастет, в те же онлайн игры уже не поиграть, голосовые звонки тоже станут с дополнительной задержкой, да и гос.ресурсы щас будут открываться только с российских ip.

28.04.2022 23:08 UTC
0

Зачем, клиент так же может загружать списки или юзать свой днс и решать какой трафик заворачивать в впн, а какой нет.

PS: Про скорость я наврал, это тестсервер такой был. 80 мбит и 40% cpu.