dee

у меня какая то проблема с extFilter в лог много пишет записей в целом смотрю что всё работает (адреса не мои) что за буфер не пойму если что то в конфиге стоит : rst_to_server = false (но есть подозрение что что то пытается отправить всё равно) странно , поставил http_redirect = false (было true) и всё пропало ещё нашел проблему с роутингом пары сегментов (на них не было blackhole и при обращении несуществующих адресов была попяо в мирроре )

я так и не понял есть способ блокировки квика через extfilter ?

я хотел сказать как это реализовать в extfilter ? есть файлик protos , в нём кое какие зхаписи уже есть : сюда мож что то дописать можно ?

как по поводу exfilter`а будут новые версии ?

https://habr.com/ru/news/t/562970/ что по поводу этой новости ?

там всё жестко и не очевидно в некоторых случаях ,сам 2 дня с миру по нитке еле собрал себе под гост2012 ссл если кратко :

https://ru.aliexpress.com/item/32908013209.html?spm=a2g0o.productlist.0.0.42d94b4fssxXsq&algo_pvid=d7eb055e-4dda-44c4-b14e-fd6cc1385fdd&algo_expid=d7eb055e-4dda-44c4-b14e-fd6cc1385fdd-18&btsid=29e93949-3b1c-4fab-a7b8-4233acb2fed3&ws_ab_test=searchweb0_0,searchweb201602_7,searchweb201603_52 вот на этих сетёвках всё будет огонь (с запасом)

ну допустим если блокируется через реджект хост анричебл (этого достаточно ?) , по факту то это косяк ревизора что он залипает так долго

2019-10-30 10:37:25.868 [18145] Information TriesControl - Loaded 116878 lines from the domains file '/usr/local/etc/extfilter/DUMP/domains' 2019-10-30 10:37:25.909 [18145] Information TriesControl - Loaded 93363 lines from the urls file '/usr/local/etc/extfilter/DUMP/urls' 2019-10-30 10:37:27.180 [18145] Information TriesControl - Loaded 128294 lines from the domains file '/usr/local/etc/extfilter/DUMP/ssl_host' ./extFilter -v extFilter version 0.99.4 я у себя проверил всё гут

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

может мак пропал нужный или сменился или влан пропал ?

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

ну я не могу на это ответить , но как писал ранее если не сходить с ума и построчно вносить каждое правило одной строкой (типа ipset -A revizor 1.1.1.1 потом другая строка (в цикле например) ipset -A revizor 2.2.2.2 и т.д) , тогда будет ооочень долго , я сперва готовлю текстовый фаил в котором куча строк формата (add revizor 1.1.1.1 сл строка add revizor 2.2.2.2) и таких строк сотни тысяч (где слово revizor это имя ipset таблицы) и этот файл у меня генерируется примерно 3 - 5 сек , после чего запускается консольная команда ipset -F revizor && ipset restore < ./мой_файл_с_кучей_строк и где то в течении 3 - 5 сек он сразу заливается в таблицу. Важно что бы таблица была точно пустая перед заливанием и строки с ip адресами ни в коем случае не совпали хоть раз , каждая запись должна быть уникальная или ipset restore ругнётся и вывалится). так же я проверяю количество строк в таблице типа ipset -L blocked | wc -l 449044 - примерное количество строк (меньше 400 тыщ не должно быть точно)

кстати для тех у кого PC роутеры или микротик системы , я в своё время топил прям за ip route blackhole , но в какой то момент увидел как там появилось порядка 400 тыщ маршрутов (меня это расстроило , т.к штатными средствами заливать это приходилось даже не быстрой системе по 15 минут (это в случае очистки таблицы и залития новой (можно обойтись конечно сравнением массивов , но заморачиваться не стал т.к нашел метод на 10 сек) , тот же самый ipset с параметром ipset create revizor hash:net maxelem 999999999 , что бы убрать штатное ограничение в 65535 записей и сперва генерить текстовый фаил вида add revizor х.х.х.х (с кучей строк) , а потом делать ipset restore < ./my_file (заливается где то за 5 сек) . Удобно и всегда актуальный список (можно держать 2 списка для обнуления одного , а потом их менять местами что бы в эти 5 сек ни кто не проскочил). Так же гуглил в сторону ip route save/restore - тоже работет очень быстро , но там заморочка в генерации файла для заливки (бинарник) , нужно поднимать библиотеки и что то ваять (вроде на питоне было что то , но ipset спас ситуацию).