dimon27254

Вы не привели рабочего примера. Отредактировали свое собственное сообщение, где добавили название цепочки, которая вообще не имеет какого-либо отношения к Антискану: Рассмотрим данную цепочку на моем примере. Да, она стоит после правил Антискана. Однако, ссылается на следующие две цепочки: А эти две цепочки содержат правила для работы Keenetic/Netcraze Cloud (облачная платформа): И здесь обнаруживается, что цепочки предназначены только для протокола UDP. Если вы внимательно изучите матчасть Антискана, то увидите, что он не поддерживает работу с UDP. А значит, ни одна из блокировок или защит Антискана даже теоретически не способна как-либо сломать работу мобильного приложения. Эксперимента ради, я установил на своем тестовом роутере геоблокировку по белому списку на страну США. У меня отвалился только прямой доступ через CrazeDNS, что является абсолютно ожидаемым поведением. Ни мобильное приложение, ни доступ к серверу обновлений, ни RMM не отвалились и продолжили штатно работать даже после перезапуска роутера. Свои собственные правки в репозиторий вы не предложили. На этом ставлю точку в обсуждении. При дальнейших попытках "переливания из пустого в порожнее" я закрою обсуждения в данной теме.

С таким подходом, пожалуй, нужно закрыть все проекты, связанные с маршрутизацией трафика, так как они тоже не "считаются с местными", вставляя свои правила там, где считают нужными сами. Жду пример реального рабочего приложения/скрипта, которое сделает всё, что вы описали. Пока что не вижу смысла в дальнейшем обсуждении, так как мы пришли к тому, что это "переделка ради переделки", не несущая вообще какого-либо практического применения.

Правила идут по логическому порядку до всех цепочек _NDM. Допустим, в Антискане настроек белый список. Если я создам правило МСЭ в NDMS с блокировкой какого-то IP, то пакет до него не дойдет, так как будет отфильтрован Антисканом. Это было задумано специально, чтобы весь лишний трафик отсекался сразу же. Мы с вами начали обсуждение как раз с нагрузки на процессор: Соответственно, я и хочу увидеть конкретную разницу в цифрах для моей и вашей реализации, чтобы определить целесообразность данного изменения. Приведите реальные рабочие примеры, как это можно сделать в Антискане, особенно с сервисами Кинетика/Неткрейза.

Антискан никак не связан с логикой NDMS. Он работает полностью отдельно от всей системной фильтрации трафика. Поэтому и стоит в самом начале цепочек INPUT и FORWARD. Цель Антискана - отсечь всё ещё до попадания в цепочки NDMS. Я предлагаю вам привести конкретные сравнительные примеры в цифрах, на сколько отличается загрузка процессора в текущей и вашей реализации. Например, при условных 500, 1000, 5000, 10000, 20000 соединений. Я тестирую Антискан на роутерах с ARM, и каких-либо затруднений в прохождении трафика или падении производительности не замечал при количестве соединений около 5000.

Ошибка возникает при отсутствующем компоненте "Модуль xDSL". Если компонент установлен, то Тестер кабеля работает без ошибок.

@admin @sergeyk В 5.2 Beta 0 еще актуально.

Исходный код Антискана полностью открыт. Предлагаю вам сделать pull request со своими правками. Если все будет работать корректно, рассмотрю внедрение данных изменений в следующую мажорную версию.

Правила Антискана будут "реагировать" только на пакеты, которые соответствуют всем критериям: 1. Соответствие интерфейсу. 2. Соответствие протоколу. 3. Соответствие списку портов. Во всех остальных случаях пакеты проходят "мимо", даже не попадая в цепочки ANTISCAN/ANTISCAN_HONEYPOT на обработку ядром. Вмешиваться в системные цепочки _NDM_* я считаю неуместным. Это исключительно визуальный нюанс, который на функциональность как-либо не влияет. Переименовывать не буду.

Я думаю, это следствие проблемы, ранее описанной мной. Судя по всему, при перезапуске контроллера MWS как-то некорректно передаются настройки на ретрансляторы.

В 5.2 Beta 0 не исправлено.

В 5.2 Beta 0 все ещё не исправлено. @hlnw @Infy @KoneTaH @admin

В 5.2 Alpha 11 не исправлено.

Актуально в 5.2 Alpha 10.

В 5.2 Alpha 10 ещё актуально.

Без изменений в 5.2 Alpha 10.