Комментарии 38
antifilter.download хорош до тех пор пока не начнешь пользоваться IPv6.
А отказываться от IPv6 как то уже не хочется.
Мне кажется, надо делать наоборот. Есть чебуречные IP, которые надо пускать напрямую. И есть весь остальной интернет, который надо заворачивать в VPN. Т.е. вместо списка IP "для VPN" надо вести список IP не-для-VPN.
Экзотический подвид "фильтруемый РКНом сервис с русскими IP" можно считать вымершим.
Нет никакого смысла в такой конструкции, если вы, конечно, не скрываетесь от органов. Если вы готовы в большую часть интернета ходить через VPN - так и пропишите себе российское пространство IP статикой и дефолт в VPN. Набор российских IP часто не меняется, там BGP не нужен. И генерируется легко, в предыдущей статье был скрипт.
Пока самый оптимальный вариант - вычитать множество российских IP из множества заблокированных.
Практическую потребность в этом ощутил вот прямо сегодня, когда в взятом у Вас ipresolve.lst обнаружились IP сайтов Мосгорсуда и ещё пачки российских судов, которые, в свою очередь, в рамках недавнего параноидального огораживания госорганов, запрещают доступ с зарубежных адресов. Понятно, что кто-то из администраторов попавших в список доменных имён побаловался, но приходится вот так эту ситуацию отрабатывать...
Но отменяторов и прочих любителей покрутить фильтры cloudflare в списке Антизапрета, конечно, не хватает. Хотя понятно, что он о другом.
Лечить надо причину, а не симптомы
Мне подход с маршрутизацией 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, давайте кооперироваться и придумывать вместе.
Потому что пытались заблокировать механизм туннелирования snowflake Tor'а, но разработчики быстро определили и изменили фингерпринт в собственном форке библиотеки, а блокировку не убрали. Теперь snowflake работает, а стандартный pion в реальном софте — нет.
Также блокируют какие-то браузерные фингерпринты DTLS, еще не разбирался: Проблемы в работе ПО использующего WebRTC
С п.п. 1 и 2 сталкивался, да. Рабочая идея - всем клиентам локальной сети / VPN* прописывать свой DNS, на этом DNS парсить логи запросов и при совпадении с доменом/маской из реестра - добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.
По-быстрому сделать это несложно, но хочется не по-быстрому, а по-хорошему. Чтобы у ресловленных адресов в списке было какое-то время жизни, после которого, если есть новые адреса для этого же домена, старые отбрасываются. Чтобы маршрут к добавляемому таким образом IP не просто через некоторое время появлялся в таблице маршрутизации у всех клиентов, - а самое первое соединение того клиента, который сделал запрос к DNS, уже маршрутизировалось бы правильно. Ну и т.п. А тут уже время нужно, пока не дошли руки.
И есть некоторые проблемы, которые не решаются вообще. Ну, скажем, имеем ситуацию из п. 2. При этом мобильный клиент сначала был не подключён к локальной сети / VPN, при этом получил IP от другого DNS-сервера, закэшировал его и дальше стучится по этому IP. А у нас этот же домен ресолвится уже в другой IP, и поэтому запросы клиента не маршрутизируются куда надо.
---
* VPN у меня для мобильных подключений (телефоны, ноуты в дороге) на российском VPS, а оттуда уже выборочно маршрутизируется через зарубежный.
Зачем в этой схеме 2 VPS?
На смартфон не особо передашь десятки тысяч маршрутов. А доступ к незаблокированным ресурсам и особенно - к своим локальным ресурсам, физически расположенным в России, хочется иметь без дополнительной latency 30-50 ms, которую добавляет зарубежный VPS.
добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.
Прочтите концепцию https://bitbucket.org/anticensority/antizapret-vpn-container/src/
с блокировкой WebRTC сталкивался по работе, причем блокируется именно шифрованный UDP-трафик, если соединение небезопасное, то не блокируется. правила фильтрации какие-то замудренные: иногда блокируется все, а иногда, например, только с определенным юзер-агентом. как-то раз сломал голову, почему входящий SIP-WebRTC звонок принимается в iOS Safari, но не принимается на том же устройстве в iOS-приложении. эффект всегда один и тот же: сигналинг по вебсокету бегает, а DTLS/ICE не проходит, пакетов просто не видно на стороне сервера.
при этом, если переключиться на TCP транспорт, то трафик не блокируется, видимо, не могут (пока?) разобрать пакеты.
Изобретения велосипеда.
VPN есть VPN, не надо ему никаких списков.
По-моему очевидно, что списки это попытка снизить трафик через VPN, исключая из него то, что доступно и без него.
Сегодня доступно, завтра недоступно.
Во первых, скорость через VPN достаточна для того, чтобы даже смотреть видео онлайн в хорошем качестве без смс.
Во вторых, вся эта возня с выборочной маршрутизацией, парсингом черных списков, в попытке угнаться за запретительством РКН - бессмысленная и смехотворная деятельность. В этом посте дошли уже даже до какого то голосования, Карл! Вам не жалко своего времени?
Сегодня доступно, завтра недоступно.Так это и в обратную сторону работает. Сегодня Госуслуги доступны через VPN, завтра начинается специальная военная война и они перестают быть доступны. Плюс ресурсы типа Авито, которые и до войны не пускали к себе с диапазонов хостеров. И мы всё равно приходим к выборочной маршрутизации.
Да уже сегодня полно сайтов, которые не пускают с нероссийских IP. Госорганы за последний месяц огородились знатно. Я выше писал - вчера в списке от antifilter.download прилетел IP сайта Мосгорсуда (видимо, кто-то побаловался, помню такие истории со времён крестового похода РКН на Телеграм), так мои юристы сразу застонали. А ещё раньше моя родная мама, роутер в квартире которой тоже через мой VPN ходил и изначально был настроен именно что маршрутизировать через заграницу всё, не смогла по той же причине передать показания счётчиков в энергосбыт.
Так что если изначально у меня раздельная маршрутизация была только там, где роутер спокойно переваривал все маршруты, то после нескольких таких историй сделал её и для маломощных / мобильных клиентов по схеме "VPN-сервер на российском хостинге, с него отдельный канал на зарубежный VPS с выборочной маршрутизацией".
Пардоньте, мне не хватает навыка за разумное время вкурить самому, нужно пояснение.
Если домен заблокирован сами-знаете-кем, но при этом держатель домена - бедный больной человек, который расконфигурировал себе Cloudflare так, что через VPN'ообразные, как правило, не впускает вообще никого (Cloudflare мурыжит на окне с пятисекундным отсчётом, бесконечно), - этот способ поможет?
Надо будет вносить его сразу в список префиксов/IP, а не доменов?
"Сам себе Роскомнадзор" == самостоятельно блокирую ненужные domains, ip (например рекламные сервисы). Как составить список ненужных сайтов ? Я так сначала понял цель статьи, но здесь о другом.
Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?
И еще можно сокс на микротике зароутить в интерфейс, чтобы каждый раз для проверки недоступного сайта фильтр в микротике не отключать? Нашел только как весь трафик с него зароутить, но это не совсем то =\
Я правильно понимаю, что если автор отдаст 0.0.0.0/0 я даже в админку роутера зайти не смогу? Как добавить приватные сети в исключения?
Маршрут к более узкой сети при равной метрике всегда имеет приоритет перед маршрутом к более широкой. Так что достаточно прописать статические маршруты к приватным сетям.
Более специфичные маршруты всегда побеждают. Поэтому любой маршрут на роутере победит дефолт, а маршруты на коннектед сети всегда самые приоритетные. Так что даже если бы дефолт или приватные сети как-то вылезли из сервиса (хотя там два раза каждый префикс проверяется, что он публичный и не мультикастный), на доступ к управлению маршрутизатором это не повлияло бы никак.
Эх, ни один из предложенных списков не решает проблему аватарок в ютубе.
Хм. Посмотрите в консоли хрома, с какого конкретно url они у вас тянутся и во что он резолвится. Можно добавить в список прямо как IP.
yt3.ggpht.com и судя по всему у него динамически меняется адрес.
Это cname для wide-youtube.l.google.com и оно действительно географически зависимое. Проблемы CDN качественно решаются, к сожалению, только на верхнем уровне модели, т.е. если вы загрузите список switchproxy в плагин своего браузера - всё будет работать.
Настроил через wireguard по старому методу, работает так себе - иногда сайты очень долго или вообще не открываются. Например, квест2 ~30 секунд проверял обновления и все равно не смог его скачать. При этом если зарутить весь трафик то работает хорошо, хотя скорость всего 30\50 vs 50\70 через прокси shadowsocks (хз почему, проц hap ac2 25/40%).
Имхо, лучше это все в впн-клиенте делать, чем на роутере. И быстрее и сильно проще будет.
Сам себе Роскомнадзор