dimon27254

Теперь куда-то исчезла ссылка на github. Так стало ещё подозрительнее. Исходного кода именно исполняемого файла AntiKeen.exe мы так и не дождались.

@eralde @Anna_ С мобильного устройства стало неудобно работать в диалоговых окнах. На текстовые поля сразу при открытии устанавливается фокус, и, как результат, появляется экранная клавиатура. Приходится её постоянно закрывать. На видео показал сравнение 5.0 Alpha 1 и 4.3.2:

Можете. При следующем сохранении ничего не перезапишется. Главное, соблюдайте оформление списка адресов, как в исходном файле.

Вероятно, @spatiumstas имел ввиду, чтобы присвоить статический адрес можно было сразу же в процессе регистрации за один "проход".

Было бы еще лучше, чтобы таблица выглядела как-то так: Пусть будут разделительные линии между туннелями, а также перед колонкой с пирами для "больших" туннелей.

Проблема немного получается "индивидуальной", и проявляется у каждого по разному.

Данная проблемка имеется и в других местах веб-интерфейса:

@Le ecureuil Понадобилось мне понаблюдать за работой object-group fqdn, так как по ощущениям снова появились задержки в обновлении списков адресов доменов. Включаю dns-proxy debug, и затем на роутере полностью перестает работать DNS. Не резолвятся домены как с устройств в локальной сети, так и, например, через Entware. В логах вижу бесконечный поток сообщений о таймаутах curl, ошибках от https-dns-proxy и неудачных попытках запросов. Проблема исправляется при отключении debug, а затем последовательном вводе no service dns-proxy и service dns-proxy. Данную проблему ранее уже замечал на более ранних 4.3, однако там было достаточно просто выключения debug.

Предложите вариант "ступенчатого" использования ip2net, когда он будет группировать уже имеющиеся подсети /24 (не конкретные IP) в более крупные /23, /22, /21, /20 и т.д. Это было бы действительно полезное его применение. По документации и своим тестам я вижу, что ip2net собирает только IP, а уже готовые подсети игнорирует и выдает без изменений. Если и использовать ip2net для "сборки" кандидатов, то мне пока непонятно, как потом очищать исходный список кандидатов при подсетях крупнее /24, ведь через grep/sed уже не найдется соответствие, например, для 1.1.1.4 и 1.1.0.0/22.

@FLK прав, наиболее "ресурсоемкой" задачей является свёртывание адресов-кандидатов в подсети. Я тестировал на списке из 11 тысяч адресов, на KN-1012 обработка занимала около двух секунд. В реальности, конечно, такие списки кандидатов могут собраться только при неработающем cron 😅 Я рассмотрю ваше предложение по очистке ascn_ips при нахождении совпадения в ascn_subnets.

Планирую исключить вообще из обработки Antiscan такие адреса. Не будет ни блокировки по IP/подсетям, ни накопления в списке кандидатов.

Можно, но ранее было пожелание загружать собственные списки заблокированных адресов, и для этих целей вообще в целом я и запланировал отдельные ipset и работу с ними. Адреса-исключения появятся "за компанию".

К 1.3 планировал реализовать вынесение пользовательских списков в отдельные ipset. Там как раз хочу сделать отдельно черный список адресов и также список адресов, на которые не будет распространяться работа Antiscan.

Вероятно, это проблема с переменной среды PATH. Попробуйте добавить следующую строку в crontab перед всеми задачами: PATH=/opt/bin:/opt/sbin:/sbin:/usr/sbin:/bin:/usr/bin

С данным списком все в порядке, однако, не срабатывает его обработка и "свертывание" в подсети. Судя по всему, у вас какие-то неполадки с cron - он или не запускает задачу, или что-то в процессе выполнения идет не так. Cron у вас уже был ранее настроен, или воспользовались инструкцией по ссылке из первого сообщения?

Возможно, что-то иначе работает в Safari. Я проверял в Chrome на Android и Windows. @eralde @Anna_ стоит отметить, что если изменить тему браузера при открытом веб-интерфейсе, то он под неё не подстраивается. Смена стиля происходит только после перезагрузки страницы. Так и задумано?

Прикрепите пожалуйста, вывод команды: ipset list ascn_candidates -s

Быть может, вы имели ввиду подстройку темы веб-интерфейса под тему системы/браузера. Такое сейчас есть и работает.

Такая ситуация возможна. Дело в том, что система при определенных обстоятельствах, например, смене состояния подключений к интернету или VPN, делает многократную перезапись всех таблиц netfilter. В процессе каждой перезаписи вызывается hook-скрипт, приведенный в логе. В нем реализовано ожидание, пока система "освободит" таблицы netfilter (ключ -w для iptables). Однако, иногда iptables не успевает "дождаться", пока система завершит свою работу, и "выбрасывает" такую ошибку. В целом, это не критично, т.к. правила Antiscan в один из вызовов с высокой долей вероятности все равно восстановятся. На крайний случай, если правила все-таки не применились, можете вручную выполнить команду, которая запустит восстановление правил: antiscan update_rules

Неполадка с сертификатами у вас какая-то, wget не может проверить сертификат, отдаваемый github. Попробуйте в Entware переустановить ca-bundle: opkg install ca-bundle --force-reinstall

Какая-то проблема с вашей стороны Может быть, не обновляли Entware давно. Только что сейчас проверил, онлайн установка на свежем Entware работает корректно: По HTTP пробовать бессмысленно, там идет переадресация на HTTPS:

А если в консоли ввести: wget https://github.com/dimon27254/antiscan/releases/download/1.2/antiscan_1.2_all.ipk Какой будет результат?

Нет. Установили wget-ssl, затем сразу же вводите команду для установки Antiscan.

@eralde @Anna_ в 4.3.2 исправлено. Спасибо!

@eralde @Anna_ подтверждаю исправление в 4.3.2. Спасибо!