Список заблокированных РКН ресурсов для использования с 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 доменных имен.
Подключайтесь, ставьте на голосование свои варианты (из расчета, чтобы этот вариант был полезен хотя бы некоторому кругу пользователей, а не только вам), голосуйте за чужие (и тут просьба - не тыкать бездумно "за", а задумываться, нужна ли такая запись в листе).
Надеюсь, что сообщество у нас достаточно адекватное и в источник мусора список, собираемый им, не превратится.
Традиционно отвечу на вопросы в комментариях.
Комментарии (38)
amarao
26.04.2022 23:12+9Мне кажется, надо делать наоборот. Есть чебуречные IP, которые надо пускать напрямую. И есть весь остальной интернет, который надо заворачивать в VPN. Т.е. вместо списка IP "для VPN" надо вести список IP не-для-VPN.
Экзотический подвид "фильтруемый РКНом сервис с русскими IP" можно считать вымершим.
Furriest Автор
26.04.2022 23:16+3Нет никакого смысла в такой конструкции, если вы, конечно, не скрываетесь от органов. Если вы готовы в большую часть интернета ходить через VPN - так и пропишите себе российское пространство IP статикой и дефолт в VPN. Набор российских IP часто не меняется, там BGP не нужен. И генерируется легко, в предыдущей статье был скрипт.
aborouhin
26.04.2022 23:24+2Пока самый оптимальный вариант - вычитать множество российских IP из множества заблокированных.
Практическую потребность в этом ощутил вот прямо сегодня, когда в взятом у Вас ipresolve.lst обнаружились IP сайтов Мосгорсуда и ещё пачки российских судов, которые, в свою очередь, в рамках недавнего параноидального огораживания госорганов, запрещают доступ с зарубежных адресов. Понятно, что кто-то из администраторов попавших в список доменных имён побаловался, но приходится вот так эту ситуацию отрабатывать...
nidalee
27.04.2022 06:41+1Это все же заметно медленнее связки из местного и зарубежного сервера, когда трафик прогоняется через второй только по необходимости.
Но отменяторов и прочих любителей покрутить фильтры cloudflare в списке Антизапрета, конечно, не хватает. Хотя понятно, что он о другом.
pfzim
26.04.2022 23:16+5Лечить надо причину, а не симптомы
dartraiden
27.04.2022 00:13+13Роскомнадзор должен быть разогнан, тут, разумеется, никаких компромиссов быть не может.
ValdikSS
27.04.2022 00:22+28Мне подход с маршрутизацией IP-адресов и диапазонов кажется несостоятельным.
В Реестр внесено множество доменов через звёздочку (блокировка зоны/поддоменов), и маршрутизировать через VPN нужно все поддомены конкретных доменов, а их не всегда можно узнать, они могут генерироваться динамически.
Домены, использующие CDN или просто геобалансировку, отдают разный набор адресов, в зависимости от стран/провайдеров/резолверов. Надёжно собрать их IP-адреса может быть затруднительно. Также бывают домены, которые просто сравнительно часто меняют IP-адреса.
Внереестровые блокировки часто затрагивают 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, давайте кооперироваться и придумывать вместе.
F0iL
27.04.2022 00:27WebRTC (DTLS) через библиотеку pion
Почему только через pion и как они определяют конкретную реализацию?
ValdikSS
27.04.2022 00:31+6Потому что пытались заблокировать механизм туннелирования snowflake Tor'а, но разработчики быстро определили и изменили фингерпринт в собственном форке библиотеки, а блокировку не убрали. Теперь snowflake работает, а стандартный pion в реальном софте — нет.
Также блокируют какие-то браузерные фингерпринты DTLS, еще не разбирался: Проблемы в работе ПО использующего WebRTC
aborouhin
27.04.2022 01:24С п.п. 1 и 2 сталкивался, да. Рабочая идея - всем клиентам локальной сети / VPN* прописывать свой DNS, на этом DNS парсить логи запросов и при совпадении с доменом/маской из реестра - добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.
По-быстрому сделать это несложно, но хочется не по-быстрому, а по-хорошему. Чтобы у ресловленных адресов в списке было какое-то время жизни, после которого, если есть новые адреса для этого же домена, старые отбрасываются. Чтобы маршрут к добавляемому таким образом IP не просто через некоторое время появлялся в таблице маршрутизации у всех клиентов, - а самое первое соединение того клиента, который сделал запрос к DNS, уже маршрутизировалось бы правильно. Ну и т.п. А тут уже время нужно, пока не дошли руки.
И есть некоторые проблемы, которые не решаются вообще. Ну, скажем, имеем ситуацию из п. 2. При этом мобильный клиент сначала был не подключён к локальной сети / VPN, при этом получил IP от другого DNS-сервера, закэшировал его и дальше стучится по этому IP. А у нас этот же домен ресолвится уже в другой IP, и поэтому запросы клиента не маршрутизируются куда надо.
---
* VPN у меня для мобильных подключений (телефоны, ноуты в дороге) на российском VPS, а оттуда уже выборочно маршрутизируется через зарубежный.
Moraiatw
27.04.2022 09:51Зачем в этой схеме 2 VPS?
aborouhin
27.04.2022 13:35На смартфон не особо передашь десятки тысяч маршрутов. А доступ к незаблокированным ресурсам и особенно - к своим локальным ресурсам, физически расположенным в России, хочется иметь без дополнительной latency 30-50 ms, которую добавляет зарубежный VPS.
ValdikSS
27.04.2022 16:43добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.
Прочтите концепцию https://bitbucket.org/anticensority/antizapret-vpn-container/src/
aborouhin
27.04.2022 16:47Я прочитал вчера, да. Но это, на мой взгляд, уже избыточное усложнение. Мой вариант позволяет обойтись стандартным софтом (минус задача по поддержанию актуальности своего форка DNS-сервера) с какой-то минимальной обвязкой, генерирующей для него конфиги.
sacai
28.04.2022 18:02с блокировкой WebRTC сталкивался по работе, причем блокируется именно шифрованный UDP-трафик, если соединение небезопасное, то не блокируется. правила фильтрации какие-то замудренные: иногда блокируется все, а иногда, например, только с определенным юзер-агентом. как-то раз сломал голову, почему входящий SIP-WebRTC звонок принимается в iOS Safari, но не принимается на том же устройстве в iOS-приложении. эффект всегда один и тот же: сигналинг по вебсокету бегает, а DTLS/ICE не проходит, пакетов просто не видно на стороне сервера.
при этом, если переключиться на TCP транспорт, то трафик не блокируется, видимо, не могут (пока?) разобрать пакеты.
Moraiatw
27.04.2022 09:05+1Изобретения велосипеда.
VPN есть VPN, не надо ему никаких списков.nidalee
27.04.2022 09:51+4Надо-надо, чтобы не гонять почем зря трафик по зарубежным серверам, набивая время отклика.
doctorw
27.04.2022 10:13По-моему очевидно, что списки это попытка снизить трафик через VPN, исключая из него то, что доступно и без него.
Moraiatw
27.04.2022 12:07+1Сегодня доступно, завтра недоступно.
Во первых, скорость через VPN достаточна для того, чтобы даже смотреть видео онлайн в хорошем качестве без смс.
Во вторых, вся эта возня с выборочной маршрутизацией, парсингом черных списков, в попытке угнаться за запретительством РКН - бессмысленная и смехотворная деятельность. В этом посте дошли уже даже до какого то голосования, Карл! Вам не жалко своего времени?
dartraiden
27.04.2022 14:40+2Сегодня доступно, завтра недоступно.
Так это и в обратную сторону работает. Сегодня Госуслуги доступны через VPN, завтра начинается специальная военная война и они перестают быть доступны. Плюс ресурсы типа Авито, которые и до войны не пускали к себе с диапазонов хостеров. И мы всё равно приходим к выборочной маршрутизации.aborouhin
27.04.2022 16:57Да уже сегодня полно сайтов, которые не пускают с нероссийских IP. Госорганы за последний месяц огородились знатно. Я выше писал - вчера в списке от antifilter.download прилетел IP сайта Мосгорсуда (видимо, кто-то побаловался, помню такие истории со времён крестового похода РКН на Телеграм), так мои юристы сразу застонали. А ещё раньше моя родная мама, роутер в квартире которой тоже через мой VPN ходил и изначально был настроен именно что маршрутизировать через заграницу всё, не смогла по той же причине передать показания счётчиков в энергосбыт.
Так что если изначально у меня раздельная маршрутизация была только там, где роутер спокойно переваривал все маршруты, то после нескольких таких историй сделал её и для маломощных / мобильных клиентов по схеме "VPN-сервер на российском хостинге, с него отдельный канал на зарубежный VPS с выборочной маршрутизацией".
DrinkFromTheCup
27.04.2022 11:48+1Пардоньте, мне не хватает навыка за разумное время вкурить самому, нужно пояснение.
Если домен заблокирован сами-знаете-кем, но при этом держатель домена - бедный больной человек, который расконфигурировал себе Cloudflare так, что через VPN'ообразные, как правило, не впускает вообще никого (Cloudflare мурыжит на окне с пятисекундным отсчётом, бесконечно), - этот способ поможет?
Надо будет вносить его сразу в список префиксов/IP, а не доменов?
Furriest Автор
27.04.2022 12:51+1Если клаудфларь не пускает через VPN - это решение, к сожалению, ситуацию не улучшит. Думаю, что оптимальным путем будет VPN с собственного сервиса, который ни с кем не разделяется и находится на IP, не входящем в известные пулы хостеров.
Но да, дорого.
uyrij
27.04.2022 12:07"Сам себе Роскомнадзор" == самостоятельно блокирую ненужные domains, ip (например рекламные сервисы). Как составить список ненужных сайтов ? Я так сначала понял цель статьи, но здесь о другом.
F0iL
27.04.2022 17:15+1Сам себе Роскомнадзор" == самостоятельно блокирую ненужные domains
Роскомнадзор обычно наоборот блокирует нужные домены :(
Barnaby
27.04.2022 14:55Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?
И еще можно сокс на микротике зароутить в интерфейс, чтобы каждый раз для проверки недоступного сайта фильтр в микротике не отключать? Нашел только как весь трафик с него зароутить, но это не совсем то =\
aborouhin
27.04.2022 17:20+1Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?
Маршрут к более узкой сети при равной метрике всегда имеет приоритет перед маршрутом к более широкой. Так что достаточно прописать статические маршруты к приватным сетям.
Furriest Автор
27.04.2022 19:03Более специфичные маршруты всегда побеждают. Поэтому любой маршрут на роутере победит дефолт, а маршруты на коннектед сети всегда самые приоритетные. Так что даже если бы дефолт или приватные сети как-то вылезли из сервиса (хотя там два раза каждый префикс проверяется, что он публичный и не мультикастный), на доступ к управлению маршрутизатором это не повлияло бы никак.
divanikus
27.04.2022 21:58Эх, ни один из предложенных списков не решает проблему аватарок в ютубе.
Furriest Автор
27.04.2022 22:01Хм. Посмотрите в консоли хрома, с какого конкретно url они у вас тянутся и во что он резолвится. Можно добавить в список прямо как IP.
GennPen
27.04.2022 22:05yt3.ggpht.com и судя по всему у него динамически меняется адрес.
Furriest Автор
27.04.2022 22:10Это cname для wide-youtube.l.google.com и оно действительно географически зависимое. Проблемы CDN качественно решаются, к сожалению, только на верхнем уровне модели, т.е. если вы загрузите список switchproxy в плагин своего браузера - всё будет работать.
Barnaby
27.04.2022 22:33Настроил через wireguard по старому методу, работает так себе - иногда сайты очень долго или вообще не открываются. Например, квест2 ~30 секунд проверял обновления и все равно не смог его скачать. При этом если зарутить весь трафик то работает хорошо, хотя скорость всего 30\50 vs 50\70 через прокси shadowsocks (хз почему, проц hap ac2 25/40%).
Имхо, лучше это все в впн-клиенте делать, чем на роутере. И быстрее и сильно проще будет.
TimsTims
28.04.2022 11:56Имхо, лучше это все в впн-клиенте делать, чем на роутере.
Тогда весь трафик будет идти через впн сервер. А значит пинг вырастет, в те же онлайн игры уже не поиграть, голосовые звонки тоже станут с дополнительной задержкой, да и гос.ресурсы щас будут открываться только с российских ip.
Barnaby
29.04.2022 02:08Зачем, клиент так же может загружать списки или юзать свой днс и решать какой трафик заворачивать в впн, а какой нет.
PS: Про скорость я наврал, это тестсервер такой был. 80 мбит и 40% cpu.
GennPen
antifilter.download хорош до тех пор пока не начнешь пользоваться IPv6.
А отказываться от IPv6 как то уже не хочется.
Furriest Автор
В комьюнити версию v6 добавить, в принципе, гораздо легче, поэтому в целом это всё не за горами.