dimon27254

У меня на 5.0.1 если удалить работающее в данный момент правило блокировки, то разблокировка происходит сразу же. Однако вот в Анализаторе трафика ещё несколько минут продолжает отображаться статус "заблокировано".

Пока сайт находится в разработке, при любом обращении он ведёт на Github проекта Antiscan. Возможно, из-за переадресации Adguard и считает его опасным.

На случай недоступности GitHub на территории РФ, запущен antiscan.ru - будущий сайт проекта Antiscan. Сейчас он находится в разработке, однако на нем уже работает зеркало для обновления списка подсетей стран, а также репозиторий для обновления Antiscan. Скрипт для установки Antiscan с российского репозитория: opkg update && opkg install curl && curl -fsSL https://bin.antiscan.ru/packages/install.sh | sh Обратите внимание: если у вас ранее был добавлен GitHub-репозиторий, то при использовании данного скрипта он будет заменен на bin.antiscan.ru, и дальнейшие обновления будут загружаться с российского сервера. Вручную перейти на российский репозиторий можно командами: opkg update && opkg install wget-ssl ca-bundle mkdir -p /opt/etc/opkg echo "src/gz antiscan https://bin.antiscan.ru/packages/all" >"/opt/etc/opkg/antiscan.conf" opkg update От GitHub-репозитория я отказываться не планирую, он будет обновляться совместно с российским.

Вышла версия 1.10. Новое: 1. Исключения по странам. Теперь вы можете указать список доверенных стран, доступ с которых не будет ограничиваться Antiscan. За этот функционал отвечает новый параметр GEO_EXCLUDE_COUNTRIES. Страны указываются также, как и в GEOBLOCK_COUNTRIES - в формате ISO 3166 и количеством не более 8. Для использования функционала в ascn.conf должен быть указан каталог для хранения списков адресов (IPSETS_DIRECTORY). Исключения по странам могут работать как самостоятельно, так и вместе с геоблокировкой. Возможно указание одной и той же страны одновременно как в списке геоблокировки, так и исключений. Пример использования такого сценария: Пусть в белом списке находится Россия и Казахстан (разрешены подключения только с IP России и Казахстана). Есть необходимость разрешить пользователям из России неконтролируемый Antiscan доступ к открытым портам, но при этом сохранить работу геоблокировки. В список исключений указывается Россия, и тогда все подключения, принадлежащие российским IP, будут Antiscan игнорироваться. Однако, подключения из Казахстана останутся разрешены, а из остальных стран, не входящих в белый список, запрещены. 2. Управление состоянием блокировки по накопленным IP/подсетям. Для управления этим видом блокировки добавлен параметр ENABLE_IPS_BAN. Значение по умолчанию - ENABLE_IPS_BAN=1 (блокировка включена). Если установить ENABLE_IPS_BAN=0 (выключить), то будет приостановлено: 1) Отслеживание множественных соединений с одного IP; 2) Накопление IP-адресов кандидатов на блокировку (отслеживание соединений с множества IP, принадлежащих одной подсети). 3) Свертывание накопленных IP адресов в подсети для блокировки; 4) Сама блокировка по накопленным спискам IP и подсетей. 3. Управление состоянием работы "ловушки". Теперь нет необходимости очищать список портов, чтобы отключить ловушку - достаточно изменить значение в новом параметре ENABLE_HONEYPOT. ENABLE_HONEYPOT=1 - ловушка включена, ENABLE_HONEYPOT=0 - выключена. Если в ascn.conf у вас ранее были указаны порты в HONEYPOT_PORTS, то при обновлении на 1.10 значение параметра ENABLE_HONEYPOT установится 1. В ином случае 0. Улучшения: 1. Повышена надежность загрузки списка подсетей стран. Если Antiscan не удастся скачать списки с оригинальной базы RIPEstat (stat.ripe.net), то будет выполнена попытка загрузки с зеркала. 2. Разделение исходного кода Antiscan на модули (предложил @eralde). Основной исполняемый файл S99ascn уже насчитывает более 1500 строк. С целью повышения читаемости исходного кода, функции из S99ascn вынесены в отдельные скрипты-модули, каждый из которых отвечает за определенную функциональность. Эти скрипты находятся в каталоге /opt/etc/antiscan/scripts. Удалять их строго запрещено, иначе работа Antiscan будет нарушена! Например, в config.sh приведены все функции, связанные с чтением и обработкой конфига ascn.conf. Исправления: 1. Если в GEOBLOCK_COUNTRIES указать страну, для которой в RIPEstat нет IP-адресов, то Antiscan при загрузке возвращал ложно-положительный статус. 2. Работа команды antiscan edit config блокировалась при наличии ошибок в ascn.conf. 3. После редактирования пользовательского списка исключений с помощью команды antiscan edit custom_exclude, в консоли могло появляться сообщение sh: bad number.

@eralde @Anna_ @Test Pilot Если какое-то из устройств в сети Кинетика откроет большое количество соединений (больше 1000), то на вкладке становится заметным появление некоторой задержки в работе. Можно попробовать открыть список соединений такого устройства, и веб-интерфейс на некоторое время зависнет, а браузер выдаст сообщение "страница не отвечает". Возможно ли это как-то подправить? Проверял на NC-1812 с 5.0.0.

@Anna_, у меня эта проблема тоже воспроизводится: Видны "подергивания" графика в момент, когда изменятся ширина правого блока с круговой диаграммой и легендой. ОС Windows 11 25H2, браузер Google Chrome 142.0.7444.135. Экран 1920x1080 с масштабом 125%.

@eralde @Anna_ @Test Pilot В мобильной версии журнал переходов становится нечитаемым, если раскрыть блок с фильтрами: Проверял на NC-1812 с 5.0.0.

Интересное наблюдение: Телефон подключается к Wi-Fi с одним MAC-адресом, но DHCP-запросы шлёт с другого ("основного", который виден в самом телефоне). При этом, NDMS "запоминает" только основной MAC, от которого шли DHCP. Первый же нигде в self-test не фигурирует, кроме лога. Если вручную зарегистрировать новое устройство с первым MAC, и привязать к 2.4, то привязка сработает. При включенном MLO уже оказывается 3 MAC. Один также основной, с которого идёт DHCP, и по одному для 2.4 и 5 ГГц.

@Padavan Имеется клиент Galaxy S25 Ultra с поддержкой 802.11be. Включил соответствующий режим на NC-1812 (NDMS 5.0.0) для обоих диапазонов, MLO выключен. Устройство ожидаемо подключилось в диапазоне 5 ГГц с нужным режимом и соответствующей скоростью передачи данных. Далее для теста я решил привязать S25 Ultra к диапазону 2.4 ГГц. Однако телефон продолжил спокойно себе "сидеть" в 5 ГГц и даже не заметил каких-либо ограничений. Это ожидаемое поведение? Если на NC-1812 отключить be (чтобы телефон подключился в n или ax) то привязка к бенду работает корректно, и телефон четко "следует" настройкам роутера.

@corniger @hellonow По моему мнению, в русскоязычной локализации текст выглядит немного некорректно: Такой вариант выглядел бы лучше: Если вы не видите здесь вашего клиента, проверьте Список клиентов (и добавить ссылку на страницу списка клиентов). Есть незарегистрированные клиенты (X), которых вы можете зарегистрировать (и тут снова ссылка на эту же страницу) На английском языке все выглядит поаккуратнее: Проверял на NC-1812 с 5.0.0.

@Anna_ Планируются ли какие-то правки по данной проблеме? Увидел исправление NWI-4472 в 5.0.0, однако каких-либо изменений в лучшую сторону не заметил.

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

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

Я изначально предполагал, что NTCE распознает домены не по DNS-запросам, а из SNI в TLS Client Hello.

@Le ecureuil Нахожусь в локальной сети своего NC-1812 (установлена NDMS 5.0.0), на котором включен NTCE. На одном из устройств обращаюсь по домену CrazeDNS к веб-интерфейсу удаленного Кинетика. Как и ожидается, в Анализаторе трафика приложений вижу CrazeDNS. Затем, не прерывая сессии управления через веб, подключаюсь к этому же удаленному Кинетику по чистому Wireguard (без единого намека на ASC, даже junk packets). Ожидаю увидеть в NTCE протокол Wireguard отдельной строкой, однако там меня встречает приложение CrazeDNS, у которого растет скорость пропорционально потреблению трафика через WG-туннель: Насколько такое поведение в работе NTCE корректно?