Комментарии 15
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, давайте кооперироваться и придумывать вместе.
WebRTC (DTLS) через библиотеку pion
Почему только через pion и как они определяют конкретную реализацию?
Потому что пытались заблокировать механизм туннелирования snowflake Tor'а, но разработчики быстро определили и изменили фингерпринт в собственном форке библиотеки, а блокировку не убрали. Теперь snowflake работает, а стандартный pion в реальном софте — нет.
Также блокируют какие-то браузерные фингерпринты DTLS, еще не разбирался: Проблемы в работе ПО использующего WebRTC
С п.п. 1 и 2 сталкивался, да. Рабочая идея - всем клиентам локальной сети / VPN* прописывать свой DNS, на этом DNS парсить логи запросов и при совпадении с доменом/маской из реестра - добавлять отданный клиенту IP в локальный список, который затем суммировать с полученным от внешнего сервера.
По-быстрому сделать это несложно, но хочется не по-быстрому, а по-хорошему. Чтобы у ресловленных адресов в списке было какое-то время жизни, после которого, если есть новые адреса для этого же домена, старые отбрасываются. Чтобы маршрут к добавляемому таким образом IP не просто через некоторое время появлялся в таблице маршрутизации у всех клиентов, - а самое первое соединение того клиента, который сделал запрос к DNS, уже маршрутизировалось бы правильно. Ну и т.п. А тут уже время нужно, пока не дошли руки.
И есть некоторые проблемы, которые не решаются вообще. Ну, скажем, имеем ситуацию из п. 2. При этом мобильный клиент сначала был не подключён к локальной сети / VPN, при этом получил IP от другого DNS-сервера, закэшировал его и дальше стучится по этому IP. А у нас этот же домен ресолвится уже в другой IP, и поэтому запросы клиента не маршрутизируются куда надо.
---
* VPN у меня для мобильных подключений (телефоны, ноуты в дороге) на российском VPS, а оттуда уже выборочно маршрутизируется через зарубежный.
Изобретения велосипеда.
VPN есть VPN, не надо ему никаких списков.
Сам себе Роскомнадзор