В долгосрочной все достижения или потери состоят из таких вот эпизодов. Так что и один эпизод важен.
В краткосрочной — в ковровых блокировках виноват не Телеграм.
Теоретически могут, конечно. Но вероятность не очень высока. Для загрифованной информации сильно растут требования к защищенности ИС. Им и механизм распределения реестра среди провайдеров придется перепиливать, и голову АС «Ревизор». На всё это нужны деньги, а у РЧЦ их нет.
Судя по этому комментарию, у вас проблемы либо с дефицитом общения, либо с некорректным использованием кванторов всеобщности. Либо вы просто пытаетесь троллить, но тут, как говорил герой Бандераса в «Маске Зорро» — «вы пытаетесь, а она танцует». Очень неумело.
Я, конечно, не очень глубоко знаю архитектуру SOHO-устройств, но для более-менее серьезных железок маршрутизация делается в кремнии и практически ничего не стоит, а вот файрвол для маркирования сильно подороже по ресурсам. Равно как и у PC-роутеров сейчас она опускается в кремний сетевых карт.
И здесь, мне кажется, маршрутизация должна стоить дешевле, чем файрвол. Не настолько дешевле, как в тяжелых, но всё же дешевле.
Надо у микротиковедов узнавать.
А вы не пробовали не покупать наркотики в Телеграм? Им можно для общения и для бизнеса пользоваться.
Если прочитать статью, перед тем как писать комментарий, можно увидеть, для чего это всё.
Крутить роут-демон можно в любом месте шарика, в том числе и не за пределами. Но да, если в принципе ни одного linux/unix в досягаемости нет — то моё решение не подойдет.
Нет. Для того у нас и BGP. На сервер вытягиваем новые (и только новые) версии дампа, они автоматически парсятся — и на роутер прилетает актуальный список. На роутере никаких страшных роутмапов, просто «всё, что изучено по bgp, заворачивать в туннель». В этом, собственно, идея и есть — роутер с его не очень-то обычно производительным процессором не надо насиловать постоянными обновлениями настроек, он всегда в одной конфигурации.
Смысл в том, чтобы отправлять в туннель не весь трафик, а только трафик к заблокированным ресурсам. И не тратить время на постоянное отслеживание «что же еще заблокировал РКН». По BGP и передается информация, что именно заблокировано.
И это, безусловно, тоже вариант. У него есть минус в двух действиях, которые надо выполнять последовательно. А смысл делать по сохраненной выгрузке без ее обновления не очень есть, всем же интересна как раз динамика.
Можно сделать как у меня, вытягивать кроном через git и запускать скрипты через хук post-merge. Тогда в результирующих файлах всегда будет свежее значение.
Можно скормить результат количества в Grafana и строить красивый график, как это делает Фил на usher2.club (правда, он это делает не в Grafana).
В целом есть немало хороших вариантов развития идеи, в том числе и ваш, главное — понять, чего хочется достичь.
Чтобы каждый мог самостоятельно считать, ниже два простейших скрипта.
Список префиксов: curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -n
На его основе — общее количество заблокированных адресов: curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -n | cut -d"/" -f2 | sed 's/\(^\)/(32-/g' | sed 's/\($\)/)/g' | bc | sed 's/\(^\)/2^/g' | bc | awk '{s+=$1} END {print s}'
Авторство не моё, но работает и это главное.
Используя первый, запилил bgp-сервис, который отдает список заблокированных префиксов по ebgp multihop. Удобно кормить домашнему роутеру, если у вас с него поднят туннель в цивилизацию. Любому желающему обеспечу подключение к сервису, потому что за работу сети уже нужно как-то бороться.
Коды ошибок HTTP имеют смысл, если запрос HTTP.
Ну и блокировка по IP не подразумевает возврата кодов ошибок, даже в случае HTTP-запроса. Чисто формально, поскольку по приказу 249 способы блокировки трактуются нерасширительно, переадресация на заглушку в этом случае может быть поводом для претензии РКН оператору. На практике, конечно, такое развитие событий маловероятно.
Почему нет заглушки — при блокировке по IP заглушку технологически показывать некому. Там же может быть и не браузер (как в случае телеграма, например). Поэтому по IP блокируется просто отправкой пакетов в Null.
В краткосрочной — в ковровых блокировках виноват не Телеграм.
И здесь, мне кажется, маршрутизация должна стоить дешевле, чем файрвол. Не настолько дешевле, как в тяжелых, но всё же дешевле.
Надо у микротиковедов узнавать.
Если прочитать статью, перед тем как писать комментарий, можно увидеть, для чего это всё.
Можно сделать как у меня, вытягивать кроном через git и запускать скрипты через хук post-merge. Тогда в результирующих файлах всегда будет свежее значение.
Можно скормить результат количества в Grafana и строить красивый график, как это делает Фил на usher2.club (правда, он это делает не в Grafana).
В целом есть немало хороших вариантов развития идеи, в том числе и ваш, главное — понять, чего хочется достичь.
Список префиксов:
curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -nНа его основе — общее количество заблокированных адресов:
curl -s https://raw.githubusercontent.com/zapret-info/z-i/master/dump.csv | cut -d";" -f1 | tr '|' '\n' | grep '/' | tr -d ' ' | sort -k1 -n | cut -d"/" -f2 | sed 's/\(^\)/(32-/g' | sed 's/\($\)/)/g' | bc | sed 's/\(^\)/2^/g' | bc | awk '{s+=$1} END {print s}'Авторство не моё, но работает и это главное.
Используя первый, запилил bgp-сервис, который отдает список заблокированных префиксов по ebgp multihop. Удобно кормить домашнему роутеру, если у вас с него поднят туннель в цивилизацию. Любому желающему обеспечу подключение к сервису, потому что за работу сети уже нужно как-то бороться.
Ну и блокировка по IP не подразумевает возврата кодов ошибок, даже в случае HTTP-запроса. Чисто формально, поскольку по приказу 249 способы блокировки трактуются нерасширительно, переадресация на заглушку в этом случае может быть поводом для претензии РКН оператору. На практике, конечно, такое развитие событий маловероятно.